TLS Server Operations

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:

NoneTLS is not offered to the sender
OptionalTLS 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.
RequiredTLS 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 seventeenth option on SMTP_OPTIONS in the sender template file, which rejects 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.  If you do not provide a certificate, the Gateway will generate a 'self-signed' certificate, but some senders may decline to send e-mail when a self-signed certificate is used.

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, 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 signed or encrypted e-mails without enabling the e-mail security options, S/MIME signatures and DKIM signatures will be ignored and encrypted e-mails will of course fail to be processed.

Implicit TLS

For special applications, 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.

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 log in 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 account to send only secure e-mail to you.

Signed incoming E-Mail - S/MIME Signature Verification

No special action is required other than specifying the decodeSMIME keyword for $email_security.  Currently the public key of the sender must be included in the message.

The results of the verification will be available on the SMTP_DECODE_RESULT and SMTP_SMIME_RESULT variables in the FS file generated by the Gateway.  Your application processing the Gateway worker box, or a pre-process operation for sending email-to-fax must check these variables and taking the appropriate action if the signature is missing or invalid.

Decrypting incoming E-Mail - S/MIME Decryption

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 would require a different public key for every destination number. To use encrypted e-mail for e-mail to fax operations, you can arrange for senders to specify the destination fax number in a different way: either in a recipient list or as the e-mail alias, for example "6417416000" <emailtofax@domain.com>.

The decodeSMIME keyword must be specified for $email_security.  The following additions must also be made in a special recipient FST template file which must be used for the recipient of mail which is expected to be encrypted:

An $email_decrypt_keyfile command must be supplied specifying the filename which contains the recipient's private key. Such files will normally have extension .PFX, .P12 or .PEM. The e-mail will have been encrypted with the corresponding public key.

If the passphrase supplied with the key file uses a `SECRETx variable, the FST must start with an $authenticate command and should be saved from COPIAEDIT with a valid authentication digest.

The success or failure of the verification will be available on 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.

S/MIME DKIM Verification

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 results of the verification will be available on the SMTP_DECODE_RESULT and SMTP_SMIME_RESULT variables in the FS file generated by the Gateway.