First Steps - Certificates
 | If you have not previously used secure e-mail, we strongly recommend that you first read Appendix N, which introduces all the concepts and terms used. |
| If you are still confused, as we find many customers are, about the difference between certificates for domains (TLS) and certificates for personal e-mail signing and encryption (S/MIME) please go back and read the Certificate Files section in Appendix N, which may help you. |
The Gateway supports 'explicit TLS' for incoming e-mail as a standard feature, using the normal e-mail SMTP port 25. The TLS Option setting in the Gateway Manager (GWMANAGER) selects this, and causes the Gateway to advertise TLS capability in response to the sender's greeting (EHLO) command. The TLS Option setting will select:
| None | TLS is not offered to the sender |
| Optional | TLS is offered to the sender but the sender can decline to use it. An option setting in the Gateway Manager can be used to cause the received message to fail sender or recipient validation if TLS has been declined, and the use of TLS is always recorded in the SMTP_USED_TLS variable in generated FS files. |
| Required | TLS is offered to the sender, and if the sender attempts to continue without initiating TLS, the connection is closed. No message is received. This is a global option: if TLS is required for specific senders only, use Optional and check after the message has been received as described below. |
With the Optional option, if you need to configure TLS for specific senders or recipients only, you can set the sender/recipient option in GWMANAGER to treat the non-use of TLS as an error, which causes the rejection of saved messages for which the MIF does not record that TLS has been used. Alternatively you can use the SMTP_USED_TLS variable in your own infobox logic to reject the message. This variable is set to yes if TLS has been used for the session.
For TLS Server Operations, it is recommended that you obtain a certificate from a recognized certificate provider. It is possible to create a 'self-signed' certificate, but if you do this some senders may decline to send e-mail.
CopiaFacts E-Mail Security License Option
CopiaFacts also offers additional e-mail security features as a license option. The CopiaFacts SMTP Gateway supports S/MIME signature verification (included in the standard Gateway license), S/MIME message decryption, DKIM verification, and Implicit TLS.
When E-Mail Security has been enabled in your CopiaFacts license, the $email_security configuration command must be supplied to select which options you wish to use. Please also refer to the E-Mail Security topic describing outbound e-mail, which has useful links for DKIM and Certificates.
If you receive S/MIME encrypted e-mails without enabling the e-mail security options, DKIM signatures will be ignored and encrypted e-mails will of course fail to be processed. S/MIME signatures are also ignored inside an encrypted e-mail when decryption is not enabled.
Note that the CopiaFacts Gateway cannot currently process attachments encrypted using "Microsoft Information Protection". Such documents are intended only for personal viewing with a Microsoft desktop, mobile or Internet application. Senders should be advised not to send documents for faxing which are encrypted in this way.
For special applications only, you can enable an SMTP server using Implicit TLS. This will normally use a different port (typically 587) and can optionally be enabled in the same CFGATEWAY instance as normal SMTP operations (with or without explicit TLS) on port 25. To enable implicit TLS, you need the ImplicitTLS keyword on the $email_security configuration command.
With 'Implicit' TLS the port can implicitly only accept TLS connections, and security starts immediately on connection. This is in contrast to 'Explicit' TLS where a normal SMTP session starts on port 25 and TLS is then explicitly negotiated between the sender and receiver for the remainder of the connection.
Implicit TLS uses the same type of certificate as explicit TLS. Senders must connect directly to your gateway, not simply send e-mail using their usual account for outbound e-mail. This feature would be appropriate where you have a closed group or groups of senders who can set up a special server account in their mail client to send only secure e-mail to you. The Gateway does not currently support a login and password for this direct connection, because it would be normally be controlled by senders being on a local network, and if not, then by means of sender IP address or domain/sender templates.
Because remote e-mail clients will be logging in directly to the Gateway, you should install a SSL certificate from a recognized CA to avoid the warnings that senders may see with a self-signed certificate.
Signed incoming E-Mail - S/MIME Signature Verification
No special action is required. Currently the public key of the sender must be included in the signed message, but this is almost always the case.
The results of the verification will be available in the SMTP_DECODE_RESULT and SMTP_SMIME_RESULT variables in the FS file generated by the Gateway. By default e-mail is accepted with or without S/MIME signing, and your script processing the Gateway worker box, or a pre-process operation for sending email-to-fax can check these variables and take the appropriate action if the signature is missing or invalid. An option is available in the sender or recipient template to treat either an invalid or a missing S/MIME signature as an error: this can be configured to send an e-mail or generate a worker-box script in the usual way.
If you have specified and enabled a folder for saved certificates on the Fax Settings page in GWMANAGER, the public key of the sender of a signed e-mail will be saved in this folder in a .CER file. The name of the file is the From: address with the @ replaced by #. for example steve#copia.com.CER. This file can be specified on the $email_encrypt_keyfile command for an outbound e-mail to encrypt the transmission.
Decrypting incoming E-Mail - S/MIME Decryption
The decodeSMIME keyword must be specified for $email_security to enable receipt of incoming encrypted e-mail. Using encryption for inbound e-mail is more complicated because preparatory steps are needed to allow the sender to encrypt messages to you. A description of the requirements follows, with more detail in a separate Implementation Checklist for handling encrypted inbound e-mail.
In order to encrypt incoming e-mail, the sender needs a copy of the public key associated with the recipient e-mail address. This public key is required to encrypt the message.
| Encrypted E-Mail cannot be used in an email-to-fax operation where destinations are specified as faxnumber@domain. This is impractical because it would require a different public key for every destination number. To use encrypted e-mail for e-mail to fax operations, you must arrange for senders to specify the destination fax number in a different way: the fax number (with optional punctuation characters, which are removed) must be at the start of the e-mail subject. The number may be optionally preceded by the fax: keyword, or common prefixes indicating 'response', and will be removed from the subject line, up to the first following alphabetic character. The remainder (after removing a Gateway password, if used) will be placed in the SMTP_SUBJECT variable for use in e-mail notifications relating to the fax transmission. Examples of e-mail subject text are: |
6417416000
+1 (641) 741-6000 Steve Hersee
Fax:641-741-6000 Steve Hersee
Re:641-741-6000 Steve Hersee
AW: +49 12-345678-910
| The destination address for incoming e-mails must have an e-mail identity for secure e-mail with a public key for which you have obtained an e-mail certificate (Digital ID). We recommend an address of the form secure@fax.company.com where company.com is your company's main domain. All incoming encrypted e-mail must use this as a To: address. The use of multiple To: addresses or copy addresses on incoming e-mail is not supported. |
| A special action mailbox template must be provided: normally named secure.FST under the fax.company.com folder in GWTEMPLATES. This template must contain the $email_decrypt_keyfile command described below containing the private key for the mailbox secure@fax.company.com. The presence of the keyfile in this recipient template allows the Gateway to receive encrypted mail. It also forces the option "Valid sender required for this recipient". All senders must be when receiving encrypted e-mail, usually by means of a sender template. When a fax number is obtained from the subject line, and the private key certificate has been found from this template, processing defaults to email-to-fax, just as if e-mail to faxno@domain had arrived in the non-encrypted case. Any worker-box command in the recipient template is ignored in this case. |
| Note that if the passphrase supplied with the key file uses a `SECRETx variable, the FST must start with an $authenticate command and should be edited and saved from COPIAEDIT with a valid authentication digest, not in the GWMANAGER program. |
The success or failure of the verification will be available in the SMTP_DECODE_RESULT and SMTP_SMIME_RESULT variables in the FS file generated by the Gateway. Of course if the decryption fails the message will have no content.
The handling of non-encrypted e-mail when the decodeSMIME keyword needs to be considered carefully. It is very important to be aware that this mailbox may receive vital information from your certificate supplier about the issuing or the renewal of the certificate for the secure@fax.company.com address.
The following actions are possible for decrypted e-mails:
•The default is that all incoming e-mail is accepted: e-mail for which a fax number is extracted from the subject will be processed as email-to-fax, and other e-mail will be processed as specified in the recipient template, with the script specified in a $worker_box command.
•An option is available in the sender or recipient template to treat a non-encrypted email-to-fax item (fax number identified in the subject) as an error, which can be configured to send an e-mail or generate a worker-box script in the usual way.
•Incoming e-mail without a fax number is always processed as specified in the recipient template. We recommend that the script specified in the $worker_box command should default to forward the e-mail to an administrator, but if your application for incoming encrypted e-mail does not involve email-to-fax, you can identify the required action for incoming e-mail from the subject or the sender, and use the SMTP_DECODE_RESULT and SMTP_SMIME_RESULT variables described above to identify the encryption status.
A sample of a suitable recipient template and script is provided for the example mailbox secure@fax.copia.com.
No special action is required other than specifying the decodeSMIME and verifyDKIM keywords for $email_security. The public key of the DKIM signer is obtained from the DNS records of the sending domain.
The DKIM validation result is saved in the .MIF file and also made available in the SMTP_DKIM_RESULT variable in the FS file generated by the Gateway. By default e-mail is accepted with or without DKIM signing, and your application processing the Gateway worker box, or a pre-process operation for sending email-to-fax can check the variable and take the appropriate action if the signature is missing or invalid. An option is available in the sender or recipient template to treat either an invalid or a missing DKIM signature as an error, which can be configured to send an e-mail or generate a worker-box script in the usual way.
