Users

If an inherited setting should be explicitly set or modified for a user, a user object should be created. In most cases there is no need to manually add a user object. The gateway will add a new user object when required. All the configured user objects can be viewed from the Users page.

Internal users, i.e., users for which the Locality setting is set to “Internal”, will have a green home icon next to their email address.

Domains

If an inherited setting should be explicitly set or modified for a domain, a domain object should be created. In a typical setup, all domains which are listed under the MTA relay domains, should be configured as an “Internal” domain.

Internal users, i.e., users for which the Locality setting is set to “Internal”, will have a green home icon next to their email address.

Sender and receiver settings

Most settings which have an impact on the mail flow are relevant for both the sender and receiver. However some settings are only relevant for the sender of a message and some settings are only relevant for the receiver of a message.

If a setting is relevant for a sender, the following icon will be shown next to the name

If a setting is relevant for a recipient, the following icon will be shown next to the name

The following section will briefly discuss all available settings.

General

Created

The date the user object was created.

Comment

The comment field is a free form field which can be used to add comments for the settings. For example some brief explanation why certain settings have been changed for a domain.

Locality

The “Locality” setting is a very important setting because it determines whether email should follow the encryption path or the decryption path, i.e., whether email should be encrypted or whether email should be decrypted. In most setups email sent to your internal domains should be decrypted whereas email sent to external domains should be encrypted. When an email arrives, the gateway checks whether the email should be encrypted or decrypted based on the “Locality” setting of the (envelope) recipients.

Note

If an email is sent to recipients for which the “Locality” is set to “Internal” but there are also recipients for which the “Locality” is set to “External”, the email is split into two. One email, for the internal recipients, follows the decryption path and the other email, for the external recipients, follow the encryption path.

Attention

Because the “Locality” setting is such an important setting, it should be configured correctly. In most setups the “Locality” value for all domains for which the gateway receives email (i.e., the relay domains) should be set to “Internal”.

Encrypt mode

Encrypt mode determines whether a message sent to an external user (i.e., a user with external locality) should be encrypted or not.

The possible encrypt modes are:

• No Encryption

• Allow

• Mandatory

• Allow (sender or recipient)

Encrypt mode is used for the sender and recipient, with the exception of “Allow (sender or recipient)”.

No Encryption

With “No encryption” mode, email will not be encrypted by default unless some additional rule or trigger, like for example a “Subject trigger”, says the email must be encrypted.

Allow

With “Allow” mode, email is encrypted if it is possible to encrypt, i.e., a valid recipient certificate or PGP keys is available, PDF encryption is setup for the recipient or Webmail Messenger is enabled. If the email cannot be encrypted it will be sent unencrypted. “Allow” mode is also known as “opportunistic encryption”.

Mandatory

With “Mandatory” mode, outgoing email must be encrypted. If it is not possible to encrypt, the message will not be sent and the sender will be notified by email.

Allow (sender or recipient)

With “Allow (sender or recipient)” mode, email is encrypted if it is possible to encrypt, i.e., a valid recipient certificate or PGP keys is available, PDF encryption is setup for the recipient or Webmail Messenger is enabled. The main difference between “Allow” and “Allow (sender or recipient)” is that “Allow” will only trigger encryption of it is set for sender and recipient, whereas with “Allow (sender or recipient)” mode, encryption will be triggered if “Encrypt mode” for the sender or recipient is set to “Allow (sender or recipient)”.

Note

Encrypt mode, except for “Allow (sender or recipient)”, is a sender and recipient setting. This means that the “Encrypt mode” settings for both sender and recipient are used to determine the final “Encrypt mode”. If for example the sender has “Encrypt mode” set to “Mandatory” and the recipient has encrypt mode set to “No Encryption”, the message will be encrypted and if it cannot be encrypted the email will not be sent and the sender will be notified. If the sender (or recipient) has encrypt mode “Allow (sender or recipient)”, the other encrypt mode is ignored and encryption is allowed.

Encryption notification

If enabled, the sender of the message will be notified by email when a message is encrypted. The notification email is based on the “Successful encryption” template.

Skip calendar messages

If checked, calendar emails, for example Outlook meeting requests, will not be protected, i.e., digitally signed or encrypted or sent via Webmail Messenger . Some email clients, for example Outlook, cannot handle meeting requests if the meeting requests are digitally signed or encrypted.

Note

Enabling “Skip calendar messages” does not result in skipping DLP.

S/MIME

Enabled

If enabled, S/MIME digital signing and encryption for outgoing email is supported.

Strict mode

By default, the gateway tries to decrypt every incoming S/MIME encrypted email and does not check whether the email address of the encryption certificate matches the email address of the recipient (“decrypt if possible”).

There are a number if reasons why this is good in the general case:

• It makes it easier to manage domain to domain encryption.

• Forwarded email can be decrypted.

• Email handling with multiple recipients is faster because only one key is required for decryption.

Even though non-strict mode is easier from a management perspective, it is not as secure as strict mode. In non-strict mode, if an external attacker gets hold of an encrypted message, the attacker can resend the message to an internal accomplice, i.e., someone from inside the company who has access to an internal mail box and who works closely with the attacker. Because the message will decrypted with any available key, the message will be delivered decrypted to the insider even though the insider was not the original recipient of the email.

In strict mode, additional checks will be done to make sure that the email will only be decrypted if there is a matching certificate for the recipient. Additionally it will be checked whether the certificate is valid, trusted, not revoked. The email will only be decrypted if one of the following checks are valid:

• The recipient has a certificate and private key with a matching email address and the message can be decrypted with this private key.

• The recipient has a certificate and private key and the certificate is explicitly associated with the user and the message can be decrypted with the private key.

• The recipient is from a domain and the domain has an explicitly associated certificate and private key and the message can be decrypted with this private key.

In strict mode, every recipient for which none of the above rules apply, will receive the message in encrypted form.

Whether or not to use strict mode depends mostly on whether you trust your internal users. If you do not trust all internal users, it’s better to enable strict mode. If all internal users can be trusted, running in non-strict mode will be easier to setup and manage.

Note

Strict mode can be enabled and/or disabled per domain and per recipient. Although it’s advised to only change the global strict settings, there are situations where it can be helpful to enable or disable strict mode per recipient. For example, suppose the global strict mode is enabled and, because of email archiving purposes, the front-end SMTP server sends a copy (bcc) of every incoming email to the email archiving system. Since the gateway is in strict mode, encrypted message will not be decrypted by the gateway when delivered to the email archiver. By disabling strict mode for the email archiver recipient, incoming email delivered to the email archiver will be decrypted.

Max. message size

If the email size is larger than the specified maximum message size (in bytes) the message will not be S/MIME signed or encrypted. Large S/MIME messages can sometimes not be handled by S/MIME email clients. Another reason for limiting the size of S/MIME messages is that encrypting and signing of large email messages can be resource intensive.

Encryption algorithm

The encryption algorithm used when S/MIME encrypting email. The following encryption algorithms can be selected: AES256, AES192, AES128, 3DES, RC2, CAST5, CAMELLIA256, CAMELLIA192, CAMELLIA128 and SEED.

Note

Some S/MIME clients only support a subset of the available algorithms. For example Outlook only supports AES256, AES192, AES128, 3DES and RC2.

Encryption scheme

Encryption scheme configures which padding algorithm is used. The following encryption schemes are supported: RSAES-PKCS1-v1_5, RSAES-OAEP-SHA1, RSAES-OAEP-SHA256, RSAES-OAEP-SHA384 and RSAES-OAEP-SHA512.

Warning

Although RSAES-OAEP is more secure than RSAES-PKCS1-v1_5, not all S/MIME clients support RSAES-OAEP.

Note

RSAES-OAEP is required by the German edi@energy standard.

Signing algorithm

The hashing algorithm used when S/MIME signing email. The following hashing algorithms can be selected: SHA1, SHA256, SHA512 and RIPEMD160.

Auto select certificates

If enabled, encryption certificates will be automatically selected for the recipient.

Always use freshest signing certificate

The first time a message is S/MIME signed, the gateway automatically selects a valid signing certificate for the sender. Once a signing certificate has been selected, the signing certificate will be used for all signing operations until the certificate is no longer valid. If “Always use freshest signing certificate” is selected, every time a message is signed, the latest signing certificate will be selected.

Auto request certificate

If enabled and the sender does not yet have a valid S/MIME signing certificate, a new certificate and private key will be automatically requested for the sender using the default Certificate Authority (CA).

Add user

If enabled and an S/MIME certificate is available for the recipient, a user object will be created if an email is S/MIME encrypted.

Encrypt headers

If enabled, certain headers (Subject, To, Cc, Reply-To and From) are added to the S/MIME encrypted email. This option should normally only be used when encrypting email to a CipherMail for Android user (available from the Google Play Store). Adding the headers to the encrypted content gives the Android application the ability to access these headers from the smime.p7m attachment.

Note

These headers are added to the encrypted binary blob but are not removed from the email. Do not select this option if the recipient uses Outlook because Outlook does not support encrypted headers.

Remove signature

If enabled, the S/MIME signature of a signed email will be removed from the email. This is for example needed if some email client or some email handling software cannot handle digitally signed messages.

Skip calendar messages

If checked, calendar emails, for example Outlook meeting requests, are not S/MIME digitally signed or encrypted. Some email clients, for example Outlook, cannot handle meeting requests if the meeting requests are digitally signed or encrypted.

Skip signing calendar messages

If checked, calendar emails, for example Outlook meeting requests, are not S/MIME digitally signed. Some email clients, for example Outlook, cannot handle meeting requests if the meeting requests are digitally encrypted.

The difference between “Skip signing calendar messages” and “Skip calendar messages” is that if “Skip signing calendar messages” is enabled but “Skip calendar messages” is not, messages can still be encrypted. This can be helpful if all email, including calendar messages, sent to a specific domain should be encrypted with a domain certificate and the recipient also uses a gateway to decrypt email.

Add additional certificates

If enabled, an S/MIME encrypted email will be encrypted with the certificates for the recipients and with the additional certificates. This can for example be used as an “escrow” mechanism to make sure that all outgoing email is encrypted with a company certificate.

Auto import certificates from email

If enabled, certificates from received S/MIME digitally signed emails will be automatically extracted and stored in the certificate store.

Skip import of untrusted certificates

If enabled, extracted certificates (see “Auto import certificates from email”) will only be imported if the certificates are trusted.

Check for invalid 7bit chars

This is a detection mechanism for EFAIL (For more information see https://www.ciphermail.com/blog/efail-detection-and-prevention.html)

If enabled, the decrypted message will be analyzed to check whether all characters are within the acceptable character range for S/MIME (tab, LF, CR, 32-126). If a character is found which is not within the acceptable range, the header X-Djigzo-Info-SMIME-Illegal-Chars-Found: True will be added to the email and the following warning message will be printed to the logs:

WARN  Illegal characters detected in decrypted message

Abort decrypt on invalid 7bit chars

This is a detection mechanism for EFAIL (For more information see https://www.ciphermail.com/blog/efail-detection-and-prevention.html)

If “Abort decrypt on invalid 7bit chars” is enabled and invalid 7bit chars are detected (see “Check for invalid 7bit chars”), decryption will be aborted and the email will be delivered in encrypted form. The following warning message will be printed to the logs:

WARN  Decryption aborted. Illegal characters detected in decrypted message

PGP

Enabled

If enabled, PGP digital signing and encryption for outgoing email is enabled.

PGP encoding to external

PGP encoding for email sent to external domains. Two encodings are supported: PGP/MIME and PGP/INLINE. PGP/MIME encrypts and signs the complete MIME message and has full support for HTML email. With PGP/INLINE, every MIME part is individually PGP signed and encrypted. PGP/INLINE support for HTML email is limited and is not supported by all email clients. Because PGP/INLINE has to scan the complete MIME message, PGP/INLINE is more resource intensive.

Note

You are strongly advised to use PGP/MIME whenever possible. PGP/MIME has full support for HTML email and is less resource intensive.

Enable PGP/INLINE to internal

PGP supports two types of encoding: PGP/MIME and PGP/INLINE. PGP/MIME encrypts and signs the complete MIME message and has full support for HTML email. A PGP/MIME protected message can be easily recognized without having to scan the complete message because it contains a PGP/MIME specific header. With PGP/INLINE, every individual part of the message (attachments and message body) is individually signed and encrypted. To determine whether or not an incoming message is PGP/INLINE protected, the complete message has to be scanned because a PGP/INLINE message does not contain a specific header which can be used to determine whether the message is PGP/INLINE signed or encrypted. Scanning every incoming email for PGP parts is resource intensive, especially for email with big attachments.

Note

Leave “Incoming PGP/INLINE enabled” unchecked unless PGP/INLINE support for incoming email is a requirement.

Max. message size

If the email size is larger than the specified maximum message size (in bytes) the message will not be PGP signed or encrypted. Large PGP messages can sometimes not be handled by PGP email clients. Another reason for limiting the size of PGP messages is that encrypting and signing of large email messages can be resource intensive.

Signing algorithm

The signing algorithm for PGP signing the email. The following signing algorithms can be selected: SHA1, SHA256, SHA512 and RIPE-MD/160.

Encryption algorithm

The encryption algorithm for PGP encrypting the email. The following encryption algorithms can be selected: AES256, AES192, AES128, 3DES, CAST5, Blowfish and Twofish.

Compression algorithm

The compression algorithm used for PGP encryption. The following compression algorithms can be selected: UNCOMPRESSED, ZIP, ZLIB, BZip2. If UNCOMPRESSED is selected, the message is not compressed.

Convert HTML to text

If enabled and an email is encrypted or signed with PGP/INLINE, HTML parts will be converted to text only. If the email is encrypted or signed with PGP/MIME, this setting has no effect.

Add integrity packet

If enabled, an integrity packet will be added to the PGP encoded email.

Key size

The default key size (in bits) for PGP secret keys generated by the gateway. The following key size can be selected: 1024, 2048, 4096.

Auto publish

If enabled, PGP secret keys which are automatically generated by the gateway will be automatically published to the configured PGP key servers.

Auto request

If enabled and a message is PGP signed or encrypted and the sender does not have a valid PGP secret key yet, a new PGP secret key will be automatically generated for the sender.

Remove signature

If enabled and an email is PGP signed, the PGP signature will be removed from the email.

Import keys from email

If enabled and a PGP key is attached, the key will be imported into the PGP keyring.

Note

Keys will only be imported from attachments if the content-type of the attachment is set to “application/pgp-keys”.

Remove keys from email

If enabled and a PGP key is attached, the key will be removed from the email.

Note

Keys will only be removed from attachments if the content-type of the attachment is set to “application/pgp-keys”.

Scan HTML for PGP

If enabled and an incoming email is PGP/INLINE encrypted, the gateway will scan inside HTML content for PGP/INLINE parts. PGP/INLINE only has limited support for HTML email. Some email clients will HTML encode the PGP/INLINE part. With “Scan HTML for PGP” enabled, the gateway will look inside HTML parts for PGP content.

Note

Only enable “Scan HTML for PGP” if HTML should be support for PGP/INLINE. Enabling “Scan HTML for PGP” will increase the handling time of email because the gateway has to scan every HTML part for PGP/INLINE content.

Skip non PGP extensions

If enabled, binary attachments, i.e., attachments other than text/plain or text/html, that do not have a PGP type of extension, i.e., .pgp, .asc etc., will not be scanned for PGP parts. This is an optimization feature and should be left enabled unless you have a good reason to enable it.

PGP partitioned fix-up

“Symantec encryption desktop” (formerly PGP desktop) and “Symantec PGP universal” support a non-standard form of PGP encryption called “PGP partitioned format”. If “PGP partitioned fix-up” is enabled, the gateway will detect that a message was encoded with “PGP partitioned format” and will then rewrite the message to a standard form.

Note

You should only enable “PGP partitioned fix-up” if you need to support PGP email encrypted by “Symantec encryption desktop” or “Symantec PGP universal”.

Skip signing only

If enabled, an email will not be signed-only. The main reason for this option is to only allow S/MIME signing.

Example

Suppose a company uses a company wide PGP key and uses for some senders a valid S/MIME certificate. If “Only sign when encrypt” is not enabled, all outgoing email will be digitally signed even for email which cannot be encrypted. If a sender does not have a valid S/MIME certificate, the email cannot be signed with S/MIME and therefore PGP signing is used (since the PGP key is domain wide). The problem with PGP signing is that most email clients do not support it. In this case it might be better to not enable PGP signing.

Auto update email addresses

This is a global only option.

If enabled, all email addresses found in a valid User ID of a PGP key will be automatically associated with the key. If “Auto update email addresses” is not selected, email addresses should be manually associated with the key.

Note

The owner of a key can add any email address to a key (it is only checked whether the User ID contains a valid self signature). If you want to make sure that only email addresses are added which you know are valid for the user, disable ‘Auto update email addresses” and manually associate the email addresses with the key.

PDF

PDF enabled

Enabled, PDF encryption for outgoing email is enabled.

OTP enabled

If enabled, “One Time Password” mode for PDF encryption will be enabled. With OTP mode, passwords for PDF encryption will be generated based on a “Client secret” and on a “Password ID”. For more information on the OTP mode, see the “PDF encryption guide”.

Generate password to originator

If enabled, a password will be generated for the PDF and a notification email containing the generated passwords will be sent back to the sender of the email. The sender of the email is then responsible for delivering the generated passwords securely to the recipient(s) of the PDF encrypted email.

Note

By default a new password will be generated for every PDF encrypted email if “PDF Validity interval” is set to 0 (the default).

Max. message size

If the email size is larger than the specified maximum message size (in bytes) the message will not be PDF encrypted. Large PDF encrypted messages can sometimes not be handled by PDF clients. Another reason for limiting the size of PDF messages is that encrypting of large email messages can be resource intensive.

Only if mandatory

If enabled, PDF encryption will only be enabled if encryption is mandatory (for example, if “Encrypt mode” is mandatory, or if encryption is triggered using a subject trigger or via a DLP rule).

Note

“Only if mandatory” can be useful if you want to enable opportunistic encryption, i.e., encrypt if possible, for S/MIME or PGP but not to use PDF Messenger unless encryption is mandatory. With opportunistic encryption, i.e., when encrypt mode set to “Allow”, if an email cannot be S/MIME or PGP encrypted, PDF Messenger will always be used. This might not be the intended behavior because now most email will be sent via PDF Messenger. To only use PDF Messenger if encryption is mandatory, enabled “Only if mandatory”.

Sign email

If enabled and the sender has a valid signing certificate, the email containing the encrypted PDF will be S/MIME digitally signed.

Deep scan

If enabled, the complete email is scanned for attachments. This is a way to work around a non-standard MIME encoding for email generated by Apple Mail.

Reply allowed

If enabled, the encrypted PDF will contain a reply link which can be used by the recipient of the encrypted PDF to securely reply to the message.

Note

The reply functionality requires that the portal functionality is configured correctly and that “Reply sender” is configured.

Send CC to replier

If enabled, a Cc of the PDF reply will be sent to the replying user.

Note

To make sure that the Cc is encrypted, set “Encrypt mode” of the “Reply sender” “Mandatory”.

Reply validity interval

By default a reply link embedded in the encrypted PDF will never expire. By setting the “Reply validity interval”, the expiration time (in minutes) of the embedded reply link can be configured. If a user tries to reply using an expired reply link, the user gets a warning that the reply link has expired.

Reply URL

A recipient can securely reply to the PDF by clicking the embedded reply link from the encrypted PDF. The reply link opens the reply page of the built-in portal. The reply URL should be setup to link to the external URL of the PDF reply page.

The default reply URL is based on the portal “Base URL”. It is therefore advised to change the “Base URL” of the portal and not change the “Reply URL” unless there is a good reason to change it.

Reply sender

If “Reply sender” is set and “Use reply sender” is set, the envelope sender of the PDF reply message will be set to “Reply sender”. The local name part of the From header of the reply message will then be set to the email address of the replying user prefixed with in name of.

Example

Suppose “Reply sender” is set to reply@example.com and the user support@ciphermail.com replies to the encrypted PDF. The reply email will be sent by the sender reply@example.com and the “From” header will be set to in name of martijn@ciphermail.com" <reply@example.com>

If “Reply sender” is not set (the default), the reply message will be sent using the sender address of the replier.

Warning

Using the real email address of the replier can be problematic if the reply emails are sent to a server which checks SPF or DMARC. If this is the case it’s better to set “Reply sender” to a known internal email address.

Use reply sender

If enabled and “Reply sender” is set, the “Reply sender” email address is used as the sender of the PDF reply email.

Add cover page

If enabled, a PDF cover page will be added to the start of the encrypted PDF. This can for example be used to add a cover page with a company logo.

Cover page

The PDF cover page to add. The cover page should be a valid PDF with a maximum size of 64K.

Auto rename attachments

Email attachments are added to the encrypted PDF. Some file extensions are however blocked by some PDF readers (for example Adobe Acrobat blocks access to attached zip files). The PDF encryption module can automatically rename attachment extensions so the PDF reader will not block access to the attachment. The renamed attachment should then renamed back to the correct filename.

If “Auto rename attachments”, files that match a rule from from the “Attachments to rename” list will be renamed by appending the keyword “Keyword to add to renamed attachments”.

Example

If a message is PDF encrypted and a zip file with name document.zip was attached to the message, the zip file will be renamed to document.zip.RENAMED.

Attachments to rename

The list of filenames to rename. Multiple entries should be separated by a white space. Wildcard filename are supported.

Example

*.zip some-file.txt *.exe

Keyword to add to renamed attachments

The keyword to add to the extension of a filename if the attachment is renamed.

Reply Max. attachment size

The maximum allowed size (in bytes) of an uploaded attachment on the PDF reply.

Reply Max. number of attachments

The maximum allowed number of attachments which can be added to the PDF reply.

Attach original message as RFC822 (.eml)

If enabled, the original email will be attached to the PDF as an eml file (RFC822). The recipient can extract the eml file from the PDF and open it in the local mail application (for example Outlook). Because the original email is attached, all original message content, like any HTML content will be intact. The recipient can import the original email in unencrypted form in their email client for long term storage.

Background color

This defines the background color of the PDF. This can be used to match the background color of the PDF with the color of the cover page.

Password

Password

The password for the recipient. Currently this is only used for PDF encryption. The password can be set by the administrator or can be generated. If the current password has expired (see “Validity interval”) a new password will be generated if the password is required for PDF encryption. To set a static password, password expiration should be disabled by setting “Validity interval” to -1.

Password ID

The “Password ID” identifies the password used for PDF encryption. The “Password ID” is used when “One Time Password” (OTP) mode is used or when the password is delivered by SMS Text.

With OTP mode, passwords for PDF encryption will be generated based on a “Client secret” and on a “Password ID”. The “Password ID” is a unique value but is not a secret. For more information on the OTP mode, see the “PDF encryption guide”.

With the SMS Text mode, a randomly generated password will be sent to the recipient by an SMS Text message. Because the recipient can receive multiple passwords via SMS Text, the recipient needs to know which password belongs to which email. The encrypted PDF messages therefore contains the unique “Password ID” which the recipient can use to find the matching password.

Validity interval

The time (in minutes) a generated password will be valid. If the password is no longer valid (expired) a new password will be generated when a password is required for PDF encryption. If the “Validity interval” is 0, a new password will be generated every time a message is PDF encrypted.

Note

Set “Validity interval” to -1 to make sure a password never expires.

Generated length

The number of random bytes used for the generation of passwords for PDF encryption.

Note

A password for an encrypted PDF should contain enough randomness to make it secure against brute force attacks. The “Generated length” defines the number of random bytes used for generating the password. A new password will be generated by creating random bytes. the random bytes are then base32 encoded to make it a readable password.

Date last generated

The date a user password was generated. This is used in combination with the “Validity interval” to determine whether a PDF password for a user is still valid. If “Date last generated” is empty, the password will never expire.

Encryption subject trigger

Trigger

A subject trigger can be used to force encryption if the subject contains a certain keyword. This is useful if the default setting for a sender or recipient is “No encryption” but the sender wants this email to be encrypted (“on demand encryption”). Whether or not the email is really encrypted depends on whether it is possible to encrypt for the recipient. For example if there is no valid S/MIME certificate or PGP key for the recipient and PDF and Webmail messenger is not enabled, the email cannot be encrypted. If encryption is triggered but the email cannot be encrypted, the email will not be sent and the sender will be notified.

Enabled

The subject trigger will only be active if enabled.

Regular expr.

If checked, “Encryption subject trigger” is interpreted as a regular expression and the subject is matched against this regular expression.

Example

With the following subject trigger, encryption will be forced if the subject contains [secure] or [encrypt]. (?i) makes the check case insensitive:

(?i)(\[secure\]|\[encrypt\])

Remove match

If enabled, the matching part will be removed from the subject.

Example

Suppose the trigger is set to [encrypt] and the subject of the email is your bank statement [encrypt] the subject after encryption is your bank statement.

Signing

Only sign when encrypt

If enabled, an email will only be digitally signed if the email is also S/MIME or PGP encrypted. If all emails should be signed even if they are not encrypted, “Only sign when encrypt” should be disabled.

Note

An email will only be signed if the sender of an email has a valid signing certificate or PGP key.

Encryption header trigger

Force encrypt allowed

If enabled, a sender is allowed to trigger encryption of messages with a specific header (see “Force encrypt trigger”).

Force encrypt trigger

If “Force encrypt trigger” is set and a message header matches the trigger the email will be set to “Must encrypt”. If the message cannot be encrypted, the message will not be sent and the sender will be notified. “Force encrypt trigger” will only be active if “Force encrypt allowed” is enabled.

The “Force encrypt trigger” should be set as follows:

HEADER[:REG_EXPR]

Where HEADER is the name of the header and REG_EXPR is the optional header value specified as a regular expression. If REG_EXPR is not set, the header value will not be taken into account, i.e., if the header name matches, the trigger is executed.

If REG_EXPR is set, the trigger only matches if the header name and the header value matches.

Example

The following triggers will match if the email contains the header X-Encrypt (the header values will be ignored):

X-Encrypt
X-Encrypt:
X-Encrypt:*.

Example

The following trigger will match if the email contains the header X-Encrypt: true (white-space is ignored and the check is case insensitive because of (?i)):

X-Encrypt:(?i)^\s*true\s*

Signing header trigger

Force signing allowed

If enabled, a sender is allowed to trigger signing of messages with a specific header (see “Force signing trigger”).

Force signing trigger

If “Force signing trigger” is set and a message header matches the trigger the email will be set to “Should be signed”. If the message cannot be signed, the message will be sent unsigned.

The “Force signing trigger” should be set as follows:

HEADER[:REG_EXPR]

Where HEADER is the name of the header and REG_EXPR is the optional header value specified as a regular expression. If REG_EXPR is not set, the header value will not be taken into account, i.e., if the header name matches, the trigger is executed.

If REG_EXPR is set, the trigger only matches if the header name and the header value matches.

Example

The following triggers will match if the email contains the header X-Sign (the header values will be ignored):

X-Sign
X-Sign:
X-Sign:*.

Example

The following trigger will match if the email contains the header X-Sign: true (white-space is ignored and the check is case insensitive because of (?i)):

X-Sign:(?i)^\s*true\s*

Signing subject trigger

Trigger

A subject trigger can be used to force signing if the subject contains a certain keyword. Whether or not the email is really signed depends on whether there is a signing certificate or PGP key for the sender. If signing is triggered but the email cannot be signed, the email will be sent unsigned.

Enabled

The subject trigger will only be active if enabled.

Regular expr.

If checked, “Signing subject trigger” is interpreted as a regular expression and the subject is matched against this regular expression.

Example

With the following subject trigger, signing will be forced if the subject contains [sign] or [SIGN]. (?i) makes the check case insensitive:

(?i)(\[sign\])

Remove match

If enabled, the matching part will be removed from the subject.

Example

Suppose the trigger is set to [sign] and the subject of the email is The invoice [sign] the subject after signing is The invoice.

One time password (OTP)

OTP URL

The email containing the encrypted PDF contains a link which should be used to retrieve the PDF password. The “OTP URL” setting is the base URL for this link and should be set to the external domain name of the portal.

Note

The default OTP URL is based on the portal “Base URL”. It is therefore advised to change the “Base URL” of the portal and not change the “OTP URL” unless there is a good reason to change it.

Security info

Add security info

If enabled and an incoming email is S/MIME or PGP encrypted or signed, information about the security properties, like whether it was encrypted, will be added to the subject.

Decrypted tag

If an incoming message was encrypted, the “Decrypted tag” will be added to the subject.

Signed tag

If an incoming message was signed and the signature is valid, the “Signed tag” will be added to the subject.

Signed by tag

If an incoming message was signed and the signature was valid but the email address of the sender, i.e., the from header, is not the same as the email address of the signing certificate, the “Signed by tag ” will be added to the subject with %s replaced by the email address of the signing certificate.

Example

If an email with subject Here is the document was sent by test@example.com but was signed with a certificate with email address support@example.com, the subject will be rewritten to Here is the document [Signed by support@example.com].

Invalid signature tag

If an incoming email was signed but the signature is not valid (for example the signing certificate is not trusted), the “Invalid signature tag” will be added to the subject.

Warning

Since an external sender can add these tags to an existing message (i.e., “spoof” that the message was protected), the existence of any of these security info tags should not be used as a proof that the message was encrypted and/or signed. Whether or not the message was really signed and/or encrypted can only be checked with certainty by looking at the “X-Djigzo-Info” headers. The “Subject filter” can be used to remove all of the security info tags of any incoming email before handling to make sure that an external sender cannot easily “spoof” these headers.

Mixed content tag

If only a part of a message is signed, the “Mixed content tag” will be added to the subject. This can only happen with PGP/INLINE signed emails because PGP/INLINE allows only parts to be signed.

Subject filter

Enabled

If enabled, the subject of incoming email will be filtered using the subject “Filter”.

Filter

The regular expression for filtering the subject of an incoming email.

The filter should be specified as follows:

REG-EXP/ VALUE

where REG-EXP is the regular expression that will match part of the subject and VALUE is the value that will replace the matched part. If VALUE is not set, the matched part will be removed from the subject (i.e., it will be replaced with an empty value)

Example

the following subject filter can be used to remove the default security info tags from incoming email:

/\[(decrypted|signed|signed by:.*|invalid signature!)\]/

CA

Last used pfx password

The last generated password for a private key file sent to a user.

Post processing

Header internal

This header will be added to any incoming email sent to an internal recipient, i.e., to a recipient who has locality “Internal”.

The header should be specified as:

HEADER[:VALUE]

Where HEADER is the name of the header and VALUE is the optional value.

Header external

This header will be added to any incoming email sent to an external recipient, i.e., to a recipient who has locality “External”.

The header should be specified as:

HEADER[:VALUE]

Where HEADER is the name of the header and VALUE is the optional value.

Other

Server secret

The “Server secret” is used for protecting external resources against tampering (using the HMAC algorithm). For example the reply link in an encrypted PDF email is protected to make sure that a recipient can only reply to an email that was generated by the server. A global “Server secret” will be automatically generated the first time the server starts. Unless there is a good reason to change the “Server Secret”, it’s best to keep the generated value.

Client secret

The “Client secret” is used for generating one time passwords for a recipient. Every recipient over a PDF encrypted email using OTP mode should have a “Client secret”. If “Auto create client secret” is enabled, a “Client secret” for a recipient will be automatically generated if needed.

Auto create client secret

If enabled and a client secret for a recipient is not set yet and a client secret is required (for example when using PDF OTP mode), a client secret is automatically created.

System mail secret

The “System mail secret” is used for adding unique headers to emails generated by the gateway. This can then be used to prevent mail loops when complex mail routing rules are used.

Example

Assume that a gateway has been configured to always encrypt email and to send a notification email when an email is encrypted. If the sender has a forwarding rule which forwards email to an external email address, it might result in a mail loop. The notification email that an email was encrypted will be forwarded to the external address. This might trigger again a notification email because it was encrypted etc. etc. Using the “System mail secret” The gateway can detect that the notification email was generated by this gateway and will therefore not handle the email again.

A global “System mail secret” will be automatically generated the first time the server starts. Unless there is a good reason to change the “System mail Secret”, it’s best to keep the generated value.

Custom

The custom fields 1,2 and 3 can be used by extensions of the gateway.

Subject triggers

TODO

Header triggers

TODO

Portal

Settings for the portal functionality can be configured. The portal is used for PDF OTP mode.

Password

The portal login password for the user. If an external recipient receives a PDF encrypted email which was encrypted with OTP mode, the user needs to login to the portal to retrieve the password for the PDF. The recipient is allowed to set the password the first time a PDF encrypted email with OTP mode is received. A password can also be set by the administrator.

Min. password strength

The minimal password strength (in bits) a user selected password should have. The password strength is estimated using the algorithm from “NIST Special Publication 800-63”. Before the new password is accepted, additional checks on the password strength are done. A new portal password is only accepted if the password:

• Is not based on your email address.

• Does not contain a QWERTY keyboard sequence of more than 5 characters.

• Does not contain more than 5 duplicate characters in a row.

• Is of sufficient strength in bits (as defined by “NIST Special Publication 800-63”)

Note

An administrator is free to set any portal password for a user, i.e., there is no check on the strength of the password if set from the WEB GUI.

Enabled

If enabled, the user is allowed to login to the portal.

Note

The “Enabled” setting is only used to specify whether the user can login to the portal. If not enabled, users can still reply to a PDF since replying to a PDF does not require the user to login.

Auto invite

If enabled and an OTP encrypted PDF is sent to the user for the first time, the user receives an email containing a link with which a password for the portal can be set.

Base URL

The “Base URL” defines the base URL on which the portal functionality is accessible for external users. It should be a fully qualified URL which can be resolved externally. Portal URLs, like for example the reply link URL and portal login URL, are based on the “Base URL”. The “Base URL” should be configured as follows:

https://www.example.com/web/portal

Where www.example.com should be replaced by the real domain name.

Note

Because the “Base URL” is used as the base for other system URLs, it’s important that it is setup correctly.

DLP

Enable pattern scanning

If enabled, DLP checking is enabled for email sent to external domains.

Note

Enabling DLP checking only enables the DLP engine. By default no DLP rules are enabled. DLP rules should be added to make DLP scanning check the DLP rules.

Quarantine URL

The URL for the quarantine service. If a DLP quarantine rule is activated, the email is placed in the DLP quarantine. The recipient, if “Quarantine to originator” is enabled and/or the DLP manager, if “Quarantine to DLP managers” is enabled, will receive a notification email containing a link to a page on which the quarantined email can be managed. The URL contained in the notification email will be set to the “Quarantine URL”.

Note

The default “Quarantine URL” is based on the portal “Base URL”. It is therefore advised to change the “Base URL” of the portal and not change the “Quarantine URL” unless there is a good reason to change it.

DLP managers

A comma separated list of email addresses for the DLP managers. Depending on certain settings, for example “Warning to DLP managers” and “Quarantine to DLP managers”, the DLP managers will receive notifications if DLP rules are violated.

Quarantine on failed encryption

If enabled and an email cannot be encrypted, the email will be quarantined.

Quarantine on error

If the DLP scanning resulted in an error, for example because the email is not valid, the email will be be quarantined.

Warning to originator

If enabled and a DLP warning rule was activated, a warning notification email will be sent back to the sender.

Warning to DLP managers

If enabled and a DLP warning rule was activated, a warning notification email will be sent to the DLP managers.

Quarantine to originator

If enabled and a DLP quarantine rule was activated, a quarantine notification email will be sent back to the sender.

Quarantine to DLP managers

If enabled and a DLP quarantine rule was activated, a quarantine notification email will be sent to the DLP managers.

Block to originator

If enabled and a DLP block rule was activated, a block notification email will be sent back to the sender.

Block to DLP managers

If enabled and a DLP block rule was activated, a block notification email will be sent to the DLP managers.

Error to originator

If enabled and a DLP error occurred, an error notification email will be sent back to the sender.

Error to DLP managers

If enabled and a DLP error occurred, an error notification email will be sent to the DLP managers.

Release to originator

If enabled and a quarantined email was released from quarantine, a release from quarantine notification email will be sent back to the sender.

Release to DLP managers

If enabled and a quarantined email was released from quarantine, a release from quarantine notification email will be sent to the DLP managers.

Delete to originator

If enabled and a quarantined email was deleted from quarantine, a delete from quarantine notification email will be sent back to the sender.

Delete to DLP managers

If enabled and a quarantined email was deleted from quarantine, a delete from quarantine notification email will be sent to the DLP managers.

Expire to originator

If enabled and a quarantined email was expired, an expire notification email will be sent back to the sender.

Expire to DLP managers

If enabled and a quarantined email was expired, an expire notification email will be sent to the DLP managers.

Allow download

If enabled, a user is allowed to download the email from the quarantine self-service page.

Allow release

If enabled, a user is allowed to release the email from the quarantine self-service page. If the email is released from quarantine, the email is handled in a normal way, i.e., it follows the default gateway rules for outgoing email.

Allow release encrypt

If enabled, a user is allowed to release the email, with encryption set to mandatory, from the quarantine self-service page. The difference between “release” and “release encrypted” is that with “release encrypted” the email flagged for mandatory encryption.

Allow release as-is

If enabled, a user is allowed to release the email without further processing from the quarantine self-service page. With “release as-is”, the email is sent without further processing, i.e, if the quarantined email was not encrypted, it will not be encrypted when “released as-is”.

Allow delete

If enabled, a user is allowed to delete the email from the quarantine self-service page.

SMS

Phone number

The phone number of the recipient for sending SMS Text messages. Generated passwords for the encrypted PDF or passwords for encrypted certificates can be sent via SMS Text messages. The phone number should be in international format (i.e., including the country code).

Send SMS (S)

If enabled, the sender of the message is allowed to send SMS Text messages.

Receive SMS

If enabled, the recipient of the message is allowed to receive SMS Text messages.

Phone number allowed

If enabled, senders can add a telephone phone number to the subject of an outgoing message. This telephone number is then used by the PDF encryption functionality to send passwords via SMS Text messages. The telephone number is only used if the subject trigger is specified (see “Subject trigger”) and only if the telephone number is at the end of the subject line. The telephone number can start with a + and can contain spaces and the following characters (excluding the quotes) “-()”.

Examples

Suppose that the subject trigger is [encrypt]. The following subjects contains a valid telephone number:

This is a subject with a phone number [encrypt] +31123456
Encrypt this [encrypt] +31-(123)456

The following subjects do not contain a valid telephone number:

This is a subject with an invalid phone number [encrypt] 31=456
Another example with an invalid phone number +31123456 [encrypt]

Note

Only one recipient, i.e., only one To, Cc or Bcc, is supported if the telephone number is added to the subject. With multiple recipients it would be impossible to match the recipient with the correct telephone number. If the message has more than one recipient, the message will not be sent and the sender will be notified.

Default country code

If a telephone number starts with a zero (0), which is not a country code, the server will add the default country code to the telephone number. The “Default country code” is only used if the telephone number is specified on the subject.

DKIM

DomainKeys Identified Mail (DKIM) digitally signs email at the gateway level. The gateway signs the complete email (including some user defined headers) with a private key. The associated public key should be stored in DNS under a DKIM specific name. The main difference between S/MIME signing and DKIM signing is that with S/MIME the signature is in most cases validated by the end user whereas with DKIM the signature is validated by the mail server. Another difference between S/MIME and DKIM is that S/MIME uses a hierarchical trust model (using X.509 certificates) and DKIM uses keys stored in DNS for the trust model. DKIM is an additional signing option to S/MIME and should be used whenever possible because it can be used to prevent spoofing. For more details and background information about DKIM see https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail.

The gateway can be configured to DKIM sign all outgoing email. DKIM keys can be set at the global, domain or sender level.

Note

It is advised to only set DKIM keys for the sending domains. DMARC for example requires that the d= parameter matches the domain of the sender.

Generate new key

Generates a new DKIM key pair. A 1024 bits or 2048 bits key can be generated.

Note

If possible select a 2048 bits key. Note however that not all DNS servers might support DNS TXT entries large enough to store a public 2048 key.

Upload key

Upload an existing DKIM key pair.

Download private key

Download the DKIM keypair key (in PEM format).

Note

If HSM support is enabled, importing and downloading a DKIM key pair might not be allowed by the HSM.

DKIM signing enabled

A DKIM signature will only be applied if “DKIM signing enabled” is set and a DKIM key is available.

Signature template

The template for the DKIM header. The default template is set to:

v=1; c=relaxed/relaxed; s=ciphermail; d=${domain}; h=From:Subject:To:Date; a=rsa-sha256; t=; bh=; b=;

The template supports the following template parameters: ${email} and ${domain}. If the email is DKIM signed, ${email} will be replaced by the senders email address and ${domain} will be replaced by the domain of the senders email address.

Note

${email} can be used to set the identity of the user or sending agent by adding the following parameter to the template i=${email}.

System key

The DKIM system key is used for DKIM signing of locally generated email. With the DKIM header, the gateway can detect that forwarded email was generated by the gateway and therefore requires no further processing. This key is automatically generated.

Webmail

CipherMail Webmail Messenger is a webmail add-on to the CipherMail encryption gateway. If the rules on the CipherMail encryption gateway determine that a message must be encrypted, and S/MIME, PGP or PDF encryption is not available (for example because there is no certificate for a recipient), the email will be sent to the CipherMail Webmail Messenger box via an S/MIME secured tunnel. The recipient gets a notification that a new message is available. The first time the user receives a message, the user needs to select a secure password. The user can read and reply to the message using any web browser.

This part only briefly explains the Webmail Messenger settings. For more details on how to install and configure Webmail Messenger, see the “CipherMail Webmail Administration Guide” and “CipherMail Webmail Quick Start Guide”.

Enabled

If set, Webmail Messenger will be enabled for the recipient.

Note

Webmail Messenger must be correctly configured before enabling Webmail Messenger.

Read receipt

If enabled, a read receipt header will be added to the message and a read receipt email will be sent when the recipient opened the email. Alternatively, the sender can add a read receipt from the email client when sending the email.

Example read receipt:

This is a Return Receipt for your message

        To: test <test@example.com>
        Subject: demo webmail
        Date: 2015-06-26 16:34

Note: This receipt only acknowledges that the message was displayed on the
recipient's computer. There is no guarantee that the recipient has read or
understood the message contents.

Only if mandatory

If enabled, Webmail Messenger will only be enabled if encryption is mandatory (for example, if “Encrypt mode” is mandatory, or if encryption is triggered using a subject trigger or via a DLP rule).

Note

“Only if mandatory” can be useful if you want to enable opportunistic encryption, i.e., encrypt if possible, for S/MIME or PGP but not to use Webmail Messenger unless encryption is mandatory. With opportunistic encryption, i.e., when encrypt mode set to “Allow”, if an email cannot be S/MIME or PGP encrypted, Webmail Messenger will always be used. This might not be the intended behavior because now most email will be sent via Webmail Messenger. To only use Webmail Messenger if encryption is mandatory, enabled “Only if mandatory”.

OTP enabled

For PDF encryption with OTP mode, a portal is required for retrieving the PDF password. If the Webmail Messenger add-on is used, it already provides a portal functionality. If “OTP enabled” is set, all messages that should be PDF encrypted with OTP mode will be sent to Webmail Messenger for PDF encryption. Webmail Messenger takes care of the portal functionality and PDF reply options.

Note

If Webmail Messenger add-on is used, it’s advised to set “OTP enabled” and have Webmail Messenger take care of the OTP encrypted PDF email. The Webmail Messenger portal has more portal features than the gateway, like for example 2-factor authentication. Using Webmail messenger for OTP mode PDF encryption is also more secure. By using Webmail Messenger for all portal functionality, the gateway can be placed in a security zone not accessible to external recipients.

Webmail recipient

Email for Webmail Messenger is routed to Webmail Messenger via an S/MIME encrypted and signed email. The “Webmail recipient” is a special email address on which Webmail Messenger listens for email sent by the gateway. “Webmail recipient” is a required setting otherwise the gateway is unable to route email to Webmail Messenger.

Note

In order to S/MIME encrypt the email set by “Webmail sender” to “Webmail recipient”, a valid certificate for “Webmail recipient” should be available.

Webmail sender

Email for Webmail Messenger must be S/MIME signed. The sender of the email sent to Webmail Messenger, will be set to “Webmail sender” address.

Note

In order to S/MIME sign the email set by “Webmail sender” to “Webmail recipient”, a valid certificate and private key for “Webmail sender” should be available.

Certificate request by mail

A problem with S/MIME is that on order to encrypt email, the certificate of the recipient must be available. One option to get someone’s certificate is by asking the recipient to send a digitally signed email. The gateway will extract the certificate from the digitally signed message and import it into the gateway. With the “Certificate request by mail” option, the gateway can be configured to automatically reply with a digitally signed email to an incoming email. This can be used by external senders to automatically retrieve a certificate from the gateway which can then be used for sending S/MIME encrypted email. Because the reply is digitally signed, the email client (for example Outlook) can extract the certificate from the digitally signed email. The email client can then use the certificate.

If there is no signing certificate available, the sender will receive the following notification email:

This message is a reply to your request for the certificate of
test@internal.example.com.

If you did not sent the certificate request, please contact us.

Unfortunately a certificate was not available for test@internal.example.com.

Note

The certificate request service will only be activated if there is only one recipient.

Enabled

if set, the “Certificate request by mail” service is active.

Subject trigger

Regular expression which will be matched against the subject of an incoming email. If matched, the message will be handled by the “Certificate request by mail” service.

Example

If set to (?i)\[certificate request\], the following subjects will match:

Hi [certificate request]
[certificate request] for your cert

To only match if the complete subject equals the trigger, use the regular expression (?i)^\[certificate request\]$. Now only the following subject will match:

[certificate request]

Must be signed

If enabled, the certificate request email will only be accepted if the incoming message was S/MIME signed with a trusted certificate.

Licensing

Auto assign license

If enabled, a license will will automatically be assigned to the sender. Only licensed senders are allowed to use encryption.

Note

“Auto assign license” is only relevant if the license is for limited users. An unlimited user license will not count senders.