Please enable JavaScript to view this site.

CopiaFacts Reference Manual

The Fax Settings tab deals with settings required for the CopiaFacts FaxFacts server.

Standard Folders

The first three folder locations above are pre-defined when you have run COPIACONNECT to connect the machine running the Gateway to the Copia Application Data area.  These are displayed for reference only.

The server folder is the root folder where CopiaFacts is installed. This is typically a share named COPIA located on the C: drive of the fax server. The attachment folder is the folder where the attachments will be written from messages received by the gateway. The request folder is where the fax requests generated by the gateway and other utilities are stored. There are multiple priority queues with queue numbers normally ranging from 0 to 9 (highest priority to lowest priority) in the request folder. The queues are actually folders named TOSENDx where x may be a number from 1 to 15, but the default highest number is 9 (set on the $request_dir configuration command). The highest priority queue is TOSEND. You can specify different queues for different message priorities by setting the queue priority for each message priority – high, normal, and low.

User Profile

The user profile specifies which user profile should be used by the gateway to send faxes. The default user profile is either the GW.USR file of the EMailSMTP.usr profile installed to the FAXFACTS folder by the gateway installer. This user profile includes $script_locn commands that reference folders where the notification and remove scripts are stored. If you change the user profile, you must make sure to include $script_locn commands that reference the folders containing those scripts if you intend to use standard gateway notification and/or remove processing.

Cover Sheets

The default cover sheet should only be specified when you wish to include a cover sheet on faxes generated by the gateway. Clear this entry if you do not wish to use a cover sheet. You may also name a cover sheet in as $fax_cover in a sender template if you are using sender templates, or the e-mail sender may send a cover sheet as an attachment.

The first attachment found that has a cover sheet file extension (.GTT or .GCT) will be used instead of the cover sheet specified in the configuration or sender template. You can also use an ASCII Cover (.ASC, .CVR, or .TXT) which will be placed on the first $fax_filename command in the generated FS file, ahead of any other attachment files; this path name will then be placed on an ASCII_FILE variable for use in one of the supplied (or custom) ASCII_TEMPATE values. See also Faxing ASCII files.

You may disable cover sheets or prohibit attached cover sheets on an individual basis or for an entire sender domain in the sender templates even though you have a default cover sheet template specified.  Do this in the Sender Options dialog after right-clicking the Sender in the templates list.

Message Body Options

The message body options allow you to determine how you want the email message body handled. Most email client programs provide an email message body in both plain text and as formatted text, sometimes called rich content. Rich content is usually HTML. However, it can also be RTF. Depending upon your senders, you may wish to fax the rich content of the email message body directly, especially if the sender’s email message has been formatted using HTML to create a newsletter or advertising or promotional literature.

•The Fax rich message content option preserves the formatting of the sender’s email. If this content is used to provide an entire cover sheet, you may wish to delete the options to add cover sheets in email-to-fax operations.

•The Fax plain text message content option will cause only the plain text of the message, without any text formatting or graphics, to be faxed.

•the Use plain text in memo variables option will save the plain text message lines in memo variables. Memo variables are typically used to fill in a notes section on a graphical cover sheet template. You should use this option if you have a cover sheet template for the sender and the text of the email message is just a short note that will be placed on the cover sheet for the recipient. Your cover sheet template should specify enough memo variables to include all of the text of the email message. Each line of text in the email message, including blank lines, will be placed in a separate memo variable. Do not use this option if you expect to have long email messages.

•The Exclude message content option will drop the email message text from the fax. This option would be used for email in which only the attachment(s) should be faxed. The email message body is always saved to a file even if you decide to exclude it from the fax. It will just not be added to the list of fax file names if it is excluded. The plain text of the email message will be saved for excluded email messages.

Use either the Fax rich message content or Fax plain text message content options if you expect email messages that will be longer than the space allotted for on your cover sheet.

Saved plain text and HTML text bodies are normally written with System Default Encoding.  However if you expect to receive e-mails with UTF-8 encoding you should select either UTF8 or UNICODE as the encoding for text and HTML-text body files on the $unicode command, which will cause the files to be written with an appropriate encoding and byte-order-mark (BOM).

You can specify CopiaFacts variables in your email message body using the email macro character (default `) followed by the variable macro name. These variables will be expanded when an HTML email message body is converted to fax format, provided the expand HTML variables option is checked on the FXCVRT conversion pre-process in FFEXTERN.

Save Certificates

The option to save incoming S/MIME certificates (the e-mail sender's public key) should be checked if you wish to collect public keys from incoming signed e-mails.  These keys can then be used to encrypt notifications and responses which are later sent back to the sender.  The default folder for saving these keys is the FAXFACTS\Certificates folder.

The certificate file name is always set to be the sender e-mail address with @ replaced by #, and has a file extension .CER.  For example, the public key in an e-mail from steve@copia.com would be saved as steve#copia.com.CER

In a script which later sends an encrypted e-mail you can use a command such as:

$email_encrypt_keyfile `FFCERTS\`FFTARGET.CER

The `FFTARGET variable expands to the effective e-mail address (for example steve@copia.com) and the $email_encrypt_keyfile command automatically handles the conversion to use # in the filename.

Variables created from Incoming E-Mails

The gateway adds the following special variables to the FS files that it generates. These variables may be referenced on the cover sheet:

        SMTP_SUBJECTmessage subject (with password removed)
        SMTP_FROMmessage from
        SMTP_REPLYTOmessage reply to

See Variables set by the Gateway for the full list of these variables.

The notify on success and notify on fail options allow you to have CopiaFacts send the sender a response via the email reply in the message whenever a fax fails or is sent successfully, depending upon what options are set. The notification option requires at least one email channel in the fax server and the presence of the notification script notify_smtp.iif in the appropriate catalog folder as named in one of the $script_locn commands in the user profile specified for the sender. If you wish to attach the FS file to the notification message, you will need to add the following $var_def command to the FS file by specifying it in the sender template:

$var_def    FC_ATTACH_FS Yes

You may also attach the faxed image as a PDF file by including the following variable definition in the sender template:

$var_def    FC_ATTACH_FAX Yes

The fax image is only included on successful fax transmissions.

When sending email notifications you must specify a value for the $email_esender command that is required (see $email_from also) in the notification FS files created by the notification script. You should enter the from email address in the area provided below the prompt "Send notifications from this email address". The information you enter here will be stored in the variable definition NOTIFY_SENDER and written to the FS file created by the gateway. You may override this information for individual senders by including a variable definition in the sender template. For example,

$var_def   NOTIFY_SENDER """My Full Name"" <myaddress@mydomain.com>"

will override the information you enter in the configuration and cause the notification script to generate the following commands:

$email_from  "My Full Name" <myaddress@mydomain.com>

in the FS file created by the notification script to send the email notification. You may modify the notification script to include additional commands if necessary. The notification script will also extract the $email_esender setting from your CopiaFacts configuration file (FAXFACTS.CFG) and place it in the FS file created by the notification script. If you do not have an $email_esender command in your configuration file, the notification script will use the contents of the NOTIFY_SENDER variable for the parameters for the $email_esender command that it generates. Note that only the first two parameters are used from the $email_esender command in the configuration file. If you need additional parameters, you will need to modify the notification script.

Inline Image and Logo Files

The Gateway accepts e-mails where the HTML body text contains references to image files. If the image file arrives in the same e-mail as an attachment file, it must:

• have a supported image Content-Type header: image/gif, image/png, image/jpg, image/jepg, image/svg.

•have a Content-ID header which is referenced in the HTML body in a src= parameter for the image. The value is replaced in the saved HTML body by the path of the place where the Gateway has saved the image (FAXFACTS\CALLBACK\TEMP).

•have a Content-Disposition header of inline.

•be in a multipart/related group with the HTML body.

Image file attachments which do not have the above attributes will be treated as separate documents: saved in CALLBACK\TEMP with their path name placed on a $fax_filename command in the generated FS file for conversion if appropriate.

If the HTML body references the inline image with a web URL, it would normally be resolved if and when the HTML document is converted to TIF for faxing.