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 and in this case the useTLS and reqTLS options are ignored].
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. The reqTLS keyword should only be used if all your CopiaFacts e-mail is sent to a restricted group all of whose mail servers are known to support TLS. This is rarely the case.
If you specify 'use when available' TLS (using the $email_options useTLS keyword), the transmission will only attempt to use TLS (in explicit mode, and on port 25) 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 (included in the 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.
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.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. An overview of different certificate types appears at: https://en.wikipedia.org/wiki/Public_key_certificate.
For TLS server operations, most standard SSL certificates can be used in a mail server such as the CopiaFacts SMTP Gateway. A commercial SSL certificate provides some evidence of the identity of your mail server, but in practice even a self-signed certificate will allow encrypted transmission and is accepted by most MTA servers. E-Mail clients on sender devices will not directly see your Gateway and so will not generate a warning about your certificate.
For S/MIME signing and encryption, many suppliers offer free certificates for non-business use and low-cost certificates for business use, especially when a large number of addresses at a domain are to be certified. Many larger organizations will have facilities to generate certificates and keys for their staff. One such is:
https://sectigo.com/signing-certificates/email-smime-certificate
Certificates are normally downloaded from the supplier site and installed automatically in a browser. For use by CopiaFacts in e-mail operations the certificate is normally exported into a file, although there are options to access them by address in the Windows certificate store. When saved as 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.
Before attempting to use secure e-mail in CopiaFacts, we recommend that you read and absorb the overview in Appendix N of this document.
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.
Note that if you do not need to sign encrypted e-mails sent from CopiaFacts, for example when only local sender send e-mail to the Gateway, a personal e-mail certificate is not needed for each sender; but this means that they will also not be able to receive and decrypt any incoming encrypted e-mails.
First, you need to set up the TXT record(s) in your domain DNS configuration, which will be used by the DKIM verifier at the recipient mail server to check that your e-mail comes from your own domain. This requires only a self-signed key, which can be generated using the DKDNS program which we provide, or by other key-generation utilities if you prefer.
See the DKDNS topic for guidance on what to do with the private and public key which it will generate.
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.
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 their matching private keyfile installed in their mail client to decrypt the incoming email. If you use file storage for recipient public keys, we recommend the convention that the filename of the .CER file should be the recipient e-mail address, with @ replaced by #. This can then be referenced using `EMAIL_TARGET.CER.
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.
Note that if you do not need to send encrypted e-mails from CopiaFacts for example if recipients are all in your own network, a personal e-mail certificate is not needed for each recipient; but this means that they will also not be able to sign their outbound e-mails. Only the CopiaFacts SMTP Gateway requires a personal e-mail certificate to receive and decrypt encrypted incoming e-mails.
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.
