CopiaFacts supports optional TLS e-mail (Transport Level Security) as a standard feature. When used for normal outbound e-mail sent to a server which also supports TLS, this will provide end-to-end security.  When used in the CopiaFacts SMTP Gateway for incoming e-mail, it can provide security either only for the final leg, because it is possible that the e-mail has been relayed over an insecure path.  TLS can also be used when needed for login to an ISP or corporate mail server instead of being sent to the recipient's mail server, for notifications or small volumes of normal outbound e-mail.

TLS Client Operations (outbound e-mail)

When sending normal e-mail through COPIAFACTS (not using login to an ISP or local server), you can use TLS e-mail provided that the destination domain's mailserver supports this.  [The use of TLS with an ISP login is configured instead in EMSETUP].

If you specify that TLS should be mandatory (using the $email_options reqTLS keyword), then the e-mail will not be sent if the remote mailserver cannot support TLS, and will be failed with outcome code 160.  You can assign 160 in an MX_CONTINUE variable if you wish to try all the MX records for a domain in this case, but they are usually all configured in the same way.

If you specify 'use when available' TLS (using the $email_options useTLS keyword), the transmission will only attempt to use TLS when the server returns a STARTTLS capability to the EHLO command.  If not, a normal unsecured connection will be used.

When the e-mail connection has used TLS, the variable USED_TLS will be added to the FS file with a value of yes.

TLS Server Operations (inbound e-mail)

The CopiaFacts SMTP Gateway (CFGATEWAY) can be configured to handle incoming TLS e-mail.  See Gateway Signed and Encrypted E-Mail for details.

CopiaFacts E-Mail Security License Option

CopiaFacts also offers additional e-mail security features as a license option.  Currently for outbound e-mail we support S/MIME signing and S/MIME encryption, and DKIM signing.  For incoming e-mail, see the Security topic for the CopiaFacts SMTP Gateway, which supports S/MIME signature verification, 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.

Preparation

For DKIM signing, you will need to generate a key and make a matching entry in the DNS records for the domain from which the e-mail is being sent.  DomainKeys Identified Mail (DKIM) is the successor to Yahoo DomainKeys,  For information on DomainKeys and DKIM, see the following links:

http://www.dkim.org

http://www.ietf.org/rfc/rfc4871.txt?number=4871

http://tools.ietf.org/html/draft-delany-domainkeys-base-01

http://antispam.yahoo.com/domainkeys

http://en.wikipedia.org/wiki/DomainKeys

The DKDNS utility can be used to generate keys and DNS records, but actually modifying the domain DNS records must be done independently. The key published in the DNS records is the 'public' key and the key used for signing is the 'private' key.

Currently, it appears that HTML e-mails containing cascading style sheets (CSS) are modified on receipt by Gmail, Yahoo and Hotmail, to prevent incoming CSS elements breaking their webmail interface. This modification then results in the DKIM signature being rejected as invalid. It is therefore recommended that the HTML component of e-mails to these destinations should not include CSS.

Examples are provided in the Examples section.

Certificates Used in E-Mail Security

There are number of sources for certificates which can be used with the CopiaFacts E-Mail Security Option and for TLS Server operations. Many larger organizations will have facilities to generate certificates and keys for their staff. A certificate can be obtained at a low annual cost in the form of a Digital ID from Verisign, Inc at:

http://www.verisign.com/products-services/security-services/pki/pki-application/email-digital-id/index.html

and from Comodo at:

http://www.comodo.com/products/certificate_services/email_certificate.html.

Certificates are normally downloaded from the sites listed above and installed automatically in a browser.  For use by CopiaFacts the certificate must then be exported into a file. For a public key file the extension .CER is recommended, and for one containing both the public and private keys, the extension .PFX is recommended. The .PFX file will require a password when exported from the browser, and the password must be specified to CopiaFacts to enable the use of the certificate.

A certificate used for S/MIME signing must be associated with a specific e-mail address, which must also be used in the From: header in the e-mail.  The certificate used for encryption will be associated with the e-mail address of the recipient.

A certificate used for TLS server operations in the Copia SMTP Gateway is normally an SSL certificate similar to those used to support HTTPS on a web server.  One can be obtained from many certificate authorities.

Before attempting to use secure e-mail in CopiaFacts, we recommend that you read and absorb the overview in Appendix N of this document.

S/MIME Signing

The following additions must be made in the FS file:

Each FS file which sets up a signed transmission must include an $email_sign_keyfile command specifying the name of a file containing the key. Such files will normally have extension .PFX, .P12 or .PEM. A private key is required to sign e-mail, and the key file must contain a reference to the e-mail From: address in the mail item.

Each FS file which sets up a signed transmission must include an $email_options command with a SmimeSign keyword.

Each FS file which sets up a signed transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable SMSIGN_ALGORITHM. This should be set to MD5 or SHA1 or SHA256 as appropriate.  SHA1 is the default.

DKIM Signing

The following additions must be made in the FS file:

Each FS file which sets up a signed transmission must include an $email_dkim_keyfile command specifying the name of a file containing the key. Such files will normally have extension .PEM.

Each FS file which sets up a signed transmission must include an $email_options command with a DKIM keyword.

Each FS file which sets up a signed transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable DK_SELECTOR. The value is placed in the "s=" parameter of the DomainKey-Signature: header. It specifies which public key is to be used by the receiving mailserver to verify the signature.

Each FS file which sets up a signed transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable DK_HEADERFIELDS. The value is placed in the "h=" parameter of the DomainKey-Signature: header. The value is a colon-separated list of header names which specify which headers are to be encrypted (and should match their sequence in the message).  You can add unused header names to the list to prevent the message from being accepted if the header has been added en-route.

Each FS file which sets up a signed transmission (or its referenced USR or UJP file) may optionally include a $var_def command defining the variable DK_SHA256.  A non-empty value in this field selects the sha-256 signing algorithm (sha-1 is the default).

Each FS file which sets up a signed transmission (or its referenced USR or UJP file) may optionally include a $var_def command defining the variable DK_CANONICALIZATION. This specifies whether the DKIM verifier is to verify that the signed content is exactly the same (DKSIMPLE) or to tolerate common modifications such as whitespace replacement and header field line rewrapping (DKRELAXED). The latter is the default. The canonicalization can be specified separately for the headers and the body by separating two keywords with a vertical bar: for example "DKRELAXED|DKSIMPLE" specifies relaxed checking for the headers and simple checking for the body. Note that the keyword DKNOFWS (for 'no folding white spaces') is a synonym for DKRELAXED.

S/MIME Encryption

The following additions must be made in the FS file:

Each FS file which sets up a signed transmission must include an $email_encrypt_keyfile command specifying the name of a file containing the public key of the recipient. Such files will normally have extension .CER or .DER.  The recipient will need the matching private keyfile installed in their mail client to decrypt the incoming email.

Each FS file which sets up a signed transmission must include an $email_options command with a SmimeEncrypt keyword.

Each FS file which sets up an encrypted transmission (or its referenced USR or UJP file) must include a $var_def command defining the variable SMENCRYPT_ALGORITHM. This should be set to one of the values listed for this variable in Appendix D.

PDF Signing and Encryption

PDFs for e-mail attachment can be signed and encrypted on their own.  There is no corresponding keyword in the $email_security command.  However the use of FS commands $pdf_secure and $pdf_sign_keyfile for processing e-mail attachments and KEEP_FAX PDF files is controlled by the CopiaFacts E-Mail Security license option.

PDF signing using $pdf_sign_keyfile requires a signing certificate file which contains a signing certificate and private key as described for S/MIME signing above.  In this case the file format and extension must be .PFX and currently a separate file is required rather than loading the certificate from the Windows store.  Secured (passworded) PDF files cannot be signed unless the password is applied using $pdf_secure in the same operation as signing.

PDF securing and encryption using $pdf_secure does not use the same type of public key certificate as described above.  Instead it simply requires a master password, which is used to apply first, a set of permissions controlling what operations can be performed on the document (for example printing or copying); and second, an optional 'open password' which will be required to open the document for viewing.  You should be aware that tools are widely available which claim to remove both types of PDF passwords.