Settings

System settings determine how the gateway functions. For instance, S/MIME settings specify if outgoing emails should be encrypted using S/MIME. There are many different settings available, and their relevance depends on the specific use case.

Settings can be configured at several levels: factory, global, domain, and user levels. Most settings inherit their default values from the level above them. Global settings inherit defaults from factory settings, domain settings inherit from global settings, and user settings inherit from domain settings.

Factory settings ← Global settings ← Domain settings ← User settings.

Note

The domains settings also support wild card domains (*.example.com). A specific domain inherits settings from its matching wildcard domain (*.example.com ← example.com).

Whether a setting is inherited depends on whether the Inherit checkbox for that setting is selected. Not all settings are available at every level; some settings are only accessible at the global level, while others are only available at the user level.

Users

The users page displays a list of email addresses that have associated user objects. The gateway automatically creates these user objects when it needs to store specific settings for an individual user. For instance, if an external recipient receives a webmail message, the system will generate a user object for that recipient.

Tip

Typically, you do not need to manually add users. Manual addition is only necessary if you need to change a specific setting for a particular user.

By clicking a user’s email address, you can open and edit the settings popup for that specific user.

Domains

The domains page shows a list of domain objects where you can change a setting from its default inherited value.

Tip

In a typical setup, all domains listed as MTA relay domains should be configured as Internal domains.

Sender and receiver settings

Most settings that affect mail flow are important for both senders and recipients. However, some settings apply only to senders, while others apply only to recipients.

If a setting applies to the sender, the icon will be displayed next to its name. If a setting applies to the recipient, the icon will be shown next to its name.

All available settings will be discussed briefly in the following section.

General

This section provides an overview of configuration options that are generally applicable to the gateway.

Created

The date the user object was created.

Comment

The comment field is a free-text field that can be used to provide remarks about the settings. For instance, it can include a brief explanation of why specific settings were modified for a domain.

Locality

The Locality setting is crucial as it defines whether an email follows the encryption path or the decryption path — in other words, whether the email will be encrypted or decrypted. Typically, email sent to your internal domains should be decrypted, while email sent to external domains should be encrypted. When an email is received, the gateway determines the appropriate action (encryption or decryption) based on the Locality setting of the (envelope) recipients.

Note

If an email is addressed to recipients with the Locality set to Internal and also to recipients with the Locality set to External, the email is divided into two. One email, designated for the internal recipients, is processed through the decryption path, while the other email, intended for the external recipients, is processed through the encryption path.

Attention

Since the Locality setting is crucial, it must be configured properly. In most configurations, the Locality value for all domains that the gateway handles email for (i.e., the relay domains) should be set to Internal.

Encrypt Mode

The encrypt mode specifies whether a message sent to an external user (i.e., a user with external locality) should be encrypted.

The possible encrypt modes are:

• NO_ENCRYPTION

• ALLOW

• MANDATORY

• FORCE

Note

The encrypt mode is applied to both the sender and recipient, except in the case of FORCE.

NO_ENCRYPTION

In NO_ENCRYPTION mode, emails are not encrypted by default unless a specific rule or trigger, such as a Subject trigger, requires the email to be encrypted.

ALLOW

In ALLOW mode, an email is encrypted whenever encryption is possible. This requires the availability of a valid recipient certificate, PGP keys, PDF encryption setup for the recipient, or the activation of Webmail Messenger. If encryption is not possible, the email will be sent without encryption. ALLOW mode is also referred to as opportunistic encryption.

MANDATORY

In MANDATORY mode, all outgoing emails are required to be encrypted. If encryption is not achievable, the email will not be sent, and the sender will receive a notification via email.

FORCE

With FORCE mode, email encryption is applied if encryption is possible. Encryption is triggered when:

• A valid recipient certificate or PGP keys are available.

• PDF encryption is configured for the recipient.

• Webmail Messenger is enabled.

The main distinction between Allow and FORCE modes lies in their behavior:

• In ALLOW mode, encryption is triggered only if encryption is enabled for both the sender and the recipient.

• In FORCE mode, encryption is triggered if Encrypt mode for either the sender or recipient is set to FORCE.

The primary difference between FORCE and MANDATORY modes lies in their behavior when email encryption is not possible:

• In FORCE mode, if the email cannot be encrypted, it will still be sent as-is (i.e., without encryption).

• In MANDATORY mode, if the email cannot be encrypted, the email will not be sent.

Send Encryption Notification

If this feature is enabled, the sender of the message will receive an email notification when a message is successfully encrypted. The notification email utilizes the Successful encryption template.

Skip Calendar

If selected, calendar emails, such as Outlook meeting requests, will not be protected. This means they will not be digitally signed, encrypted, or sent via Webmail Messenger.

Certain email clients, such as Outlook, may encounter issues in handling meeting requests if the requests are digitally signed or encrypted.

Note

Enabling Skip calendar messages does not result in skipping DLP.

Password Policy

The password policy ensures that user selected passwords are of sufficient strength. The general password policy is used for the following passwords: PDF subject password, OTP secret password.

In addition to the password policy, the chosen password must also comply with the following supplementary rules:

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

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

Password Policy Syntax

The password policy is defined by providing a JSON string that conforms to the structure described below:

{m: <INT>, r:[{p:<REGEX>}, {p:<REGEX>}, .... ]}

where <INT> is an integer > 0 and <REGEX> is a regular expression.

m is the minimal number of patterns that should match for the password to be valid and r is a list of password rules (regular expressions). If m is not specified, the default value 1 will be used.

The password validator operates according to the following process:

Each password is evaluated against all defined rules (regular expressions). If the total number of rules that the password matches is greater than or equal to the minimum required matches, as specified by the m parameter, the password will be accepted.

Example regular expressions

The following regular expression will match if the password contains at least 8 characters:

.{8,}

The following regular expression will match if the password contains at least one lowercase character:

[a-z]

The following regular expression will match if the password contains at least one uppercase character:

[A-Z]

The following regular expression will match if the password contains at least one digit:

[0-9]

The following regular expression will match if the password contains at least one special character from the list @#$%^&+=

[@#$%^&+=]

The above examples can be combined to form more complex rules

Example policy rules

The following password policy will check whether the password is at least 8 characters long:

{r:[{p:'^.{8,}$'}]}

The following password policy will check whether the password is at least 8 characters long, contains at least one lowercase character, at least one uppercase character and at least one digit:

{m:4, r:[{p:'.{8,}'}, {p:'[a-z]'}, {p:'[A-Z]'}, {p:'[0-9]'}]}

N out of M policy*

In the examples above, the minimum number of patterns to match (specified by the m parameter) was set to the total number of patterns. This configuration requires all patterns to match before the password is accepted. You can set the minimum number of patterns to a lower value if you want a policy that allows the password when at least N patterns are matched out of the possible M patterns.

Warning

If the minimum number of patterns required to match (the m parameter) is set lower than the total number of patterns, ensure that every pattern individually enforces its own minimum character length. Otherwise, a short password could be accepted because the “N out of M” rule could bypass the pattern responsible for setting a length requirement. For example, the following rule is unsafe: {m:1, r:[{p:’.{8,}’}, {p:’[a-z]’}]}. In this configuration, the password will be accepted if just one pattern matches, which means a single lowercase letter would be permissible. When m is less than the total number of patterns, be sure to include a minimum length requirement within each pattern.

Example N our of M policy rules

The following password policy will check whether the password is at least 8 characters long or is 6 characters long and contains at least a special character from the list:

{m:1, r:[{p:'.{8,}'}, {p:'(?=.*[@#$%^&+=]).{6,}'}]}

Enable Subject Filter

If enabled, the email subject will be modified by applying the Subject Filter Regular Expression.

Subject Filter Regular Expression

The subject of the email will be changed by processing it with the Subject Filter Regular Expression.

Specify the filter using the following format:

<REG-EXP>/ <VALUE>

where <REG-EXP> specifies the regular expression used to match a portion of the subject, and <VALUE> defines the replacement for the matched segment. If <VALUE> is omitted, the matched segment will be removed from the subject, effectively replacing it with an empty string.

Example:

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

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

Post Processing Header (Internal domain)

This header will be applied to all incoming emails addressed to internal recipients, that is, recipients whose locality is specified as Internal.

The header should be specified as:

<HEADER>[:<VALUE>]

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

Post Processing Header (External domain)

This header will be applied to all incoming emails addressed to external recipients, that is, recipients whose locality is specified as External.

The header should be specified as:

<HEADER>[:<VALUE>]

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

Organization Id

The organization ID is utilized in QR codes and other areas to identify the company that operates the gateway. It is used solely for informational purposes and does not affect the gateway’s operation or functionality in any way.

System Email Sender

The envelope sender address used for system-generated emails, such as password reset notifications.

System Email From

The from header field used for system-generated emails, such as password reset notifications.

Email Footer

The email footer will be automatically appended to all outgoing emails generated by the system (refer to the email templates for further details).

Email Footer Link

Specifies the URL used for the clickable link in the Email Footer.

Email Footer Link Title

Specifies the title used for the clickable link in the Email Footer.

S/MIME

This section provides an overview of configuration options dedicated to S/MIME encryption and digital signing.

S/MIME Enabled

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

Skip Sign Only

When this option is enabled, only emails that are S/MIME encrypted will be S/MIME signed. Emails that are not encrypted with S/MIME will not be digitally signed. To ensure that all outgoing emails are S/MIME signed, regardless of whether they are encrypted, disable this option.

Strict Mode

By default, the gateway attempts to decrypt every incoming S/MIME encrypted email. It does not verify whether the email address in the encryption certificate matches the recipient’s email address (decrypt if possible).

This behavior is generally useful for several reasons:

• It simplifies domain-to-domain encryption management.

• Forwarded emails can be decrypted seamlessly.

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

However, while non-strict mode is simpler to manage, it is less secure than strict mode. In non-strict mode, an external attacker who intercepts an encrypted email could resend it to an internal accomplice—e.g., a collaborator inside the company with access to an internal mailbox. Since the gateway decrypts messages with any available key, the message would be delivered decrypted to the insider, even if they were not the original intended recipient.

Strict Mode for Enhanced Security

In strict mode, the gateway performs additional checks to ensure that an email is only decrypted if the recipient has a valid encryption certificate that matches their email address. These checks also validate that the certificate is trusted, valid, and not revoked.

An email will only be decrypted in strict mode if any of the following conditions are met:

• The recipient has a certificate and private key with an email address matching the email’s recipient, and the private key successfully decrypts the message.

• The recipient has a certificate and private key explicitly associated with their user account, and the private key successfully decrypts the message.

• The recipient belongs to a domain that has an explicitly associated certificate and private key, and the private key successfully decrypts the message.

If none of the above conditions are met for a recipient, the gateway will deliver the email in its encrypted form.

Choosing Between Non-Strict and Strict Modes

Selecting whether to use strict or non-strict mode depends primarily on the level of trust in your internal users:

• Non-Strict Mode: Easier to set up and manage, suitable if all internal users are fully trusted.

• Strict Mode: Provides enhanced security and is recommended if you do not trust all internal users.

Tip

While it is generally recommended to only modify the global strict settings, there may be scenarios where enabling or disabling strict mode for specific recipients is helpful.

For example, consider a situation where global strict mode is enabled. If the front-end SMTP server sends a copy (BCC) of every incoming email to an email archiving system for archiving purposes, the gateway, operating in strict mode, will not decrypt encrypted messages when delivering them to the email archiver.

To address this, strict mode can be disabled for the email archiver recipient. As a result, incoming emails delivered to the email archiver will be decrypted.

Skip Calendar

If this option is selected, calendar emails (e.g., Outlook meeting requests) will not be S/MIME digitally signed or encrypted. Certain email clients, such as Outlook, may be unable to process meeting requests if they are digitally signed or encrypted.

Skip Signing Calendar

If Skip signing calendar messages is enabled, calendar-related emails (such as Outlook meeting requests) are not S/MIME digitally signed. This is because some email clients, like Outlook, may encounter issues when processing meeting requests that are digitally signed or encrypted.

Difference Between Skip signing calendar and Skip calendar:

Skip signing calendar allows calendar emails to avoid digital signing while still permitting encryption. For example, enabling this option ensures meeting requests are not signed, but they can still be encrypted if required.

Skip calendar, on the other hand, skips both signing and encrypting calendar-related emails entirely.

This distinction can be useful for scenarios where all emails, including calendar messages, sent to a specific domain need to be encrypted using a domain certificate. If the recipient’s system uses a gateway to decrypt emails, enabling Skip signing calendar without enabling Skip calendar ensures proper handling of encrypted messages.

Encryption Algorithm

The encryption algorithm used for S/MIME email encryption can be selected from the following options:

• AES256_GCM

• AES192_GCM

• AES128_GCM

• AES256_CBC

• AES192_CBC

• AES128_CBC

• DES_EDE3_CBC

Note that some S/MIME clients may only support a subset of these available algorithms.

Encryption Padding Mode

The encryption padding mode determines the padding algorithm to be used. The following padding modes are supported:

• RSAES_PKCS1_V1_5

• RSAES-OAEP-SHA1

• RSAES-OAEP-SHA256

• RSAES-OAEP-SHA384

• RSAES-OAEP-SHA512

Note that some S/MIME clients may only support a subset of these available modes.

Tip

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

Signing Algorithm

The hashing algorithm used for S/MIME email signing can be configured. The following hashing algorithms are available for selection:

• SHA1_WITH_RSA_ENCRYPTION

• SHA224_WITH_RSA_ENCRYPTION

• SHA256_WITH_RSA_ENCRYPTION

• SHA384_WITH_RSA_ENCRYPTION

• SHA512_WITH_RSA_ENCRYPTION

• SHA1_WITH_RSA_AND_MGF1

• SHA256_WITH_RSA_AND_MGF1

• SHA384_WITH_RSA_AND_MGF1

• SHA512_WITH_RSA_AND_MGF1

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)

Tip

To ensure robust protection against the EFAIL attack, it is recommended to use one of the GCM (Galois/Counter Mode) encryption algorithms.

If enabled, the decrypted message will be analyzed to ensure that all characters fall within the acceptable character range for S/MIME. The valid character range includes tab, LF, CR, and characters from 32 to 126.

If a character is detected that falls outside the acceptable range, the header X-CipherMail-Info-SMIME-Illegal-Chars-Found: True will be added to the email. Additionally, a warning message will be logged with details about the issue:

WARN  Illegal characters detected in decrypted message

Cancel Decryption On Invalid 7-bit Chars

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

If the Abort decrypt on invalid 7bit chars option is enabled and invalid 7-bit characters are detected, the decryption process will be aborted. In such cases, the email will be delivered in its encrypted form.

Additionally, the following warning message will be logged:

WARN  Decryption aborted. Illegal characters detected in decrypted message

Auto Select Encryption Certificates

When enabled, encryption certificates are automatically selected for the recipient.

Always Use Freshest Signing Certificate

When a message is S/MIME signed for the first time, the gateway automatically selects a valid signing certificate for the sender. Once selected, the same signing certificate is used for all subsequent signing operations until the certificate becomes invalid.

If the Always use freshest signing certificate option is enabled, the gateway selects the latest available signing certificate each time a message is signed.

Max Message Size

If the email size exceeds the specified maximum message size (in bytes), the email will not be signed or encrypted using S/MIME. Large S/MIME messages may not be compatible with some S/MIME email clients. Additionally, encrypting and signing large email messages can be resource-intensive, making size limitations necessary to ensure optimal performance.

Remove Signature

When enabled, the S/MIME signature of a signed email will be removed from the email. This functionality is necessary in cases where certain email clients or email handling software are unable to process digitally signed messages.

Auto Request Certificate

If this feature is enabled and the sender does not already possess a valid S/MIME signing certificate, a new certificate and private key will be automatically requested for the sender. This request will utilize the default Certificate Authority (CA).

Note

A certificate will be requested only if a suitable certificate request handler is configured.

Import Certificates From Email

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

Skip Import Certificates From Email If Not Trusted

If this feature is enabled, extracted certificates will only be imported if they are trusted.

PGP

This section provides an overview of configuration options dedicated to PGP encryption and digital signing.

PGP Enabled

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

PGP/Inline For Incoming Email Enabled

PGP supports two types of encoding: PGP/MIME and PGP/INLINE. PGP/MIME encrypts and signs the entire MIME message, providing full support for HTML email. A PGP/MIME-protected message can be easily identified by its specific PGP/MIME header, so it is not necessary to scan the entire message.

With PGP/INLINE, each part of the message (including attachments and the message body) is signed and encrypted individually. Unlike PGP/MIME, a PGP/INLINE message does not include a distinctive header to indicate its protection status. Therefore, the entire message must be scanned to determine if it is signed or encrypted using PGP/INLINE. Scanning all incoming emails for PGP parts can be resource intensive, especially for messages with large attachments.

Tip

Leave PGP/Inline For Incoming Email Enabled unchecked unless PGP/INLINE support for incoming email is required.

Scan HTML

When this option is enabled, and an incoming email uses PGP/INLINE encryption, the gateway will examine the HTML content for embedded PGP/INLINE sections. PGP/INLINE provides only limited support for HTML emails. Additionally, some email clients may encode the PGP/INLINE section as HTML. If Scan HTML is enabled, the gateway will inspect the HTML sections for PGP content.

Tip

Enable Scan HTML only if you require support for PGP/INLINE within HTML content. Note that activating Scan HTML increases email processing time because the gateway must examine each HTML section for PGP/INLINE elements.

Skip non PGP extensions

When enabled, binary attachments—specifically those that are not of type text/plain or text/html and do not have PGP-related file extensions (such as .pgp, .asc, etc.), will be excluded from PGP part scanning. This feature is an optimization and should remain enabled unless there is a specific requirement to disable it.

Auto Select Signing Algorithm

When enabled, a suitable signing algorithm will be automatically chosen to correspond with the selected encryption algorithm.

Signing Algorithm

The signing algorithm used for PGP email signing. You can select from the following algorithms:

• SHA1

• SHA224

• SHA256

• SHA384

• SHA512

• RIPEMD160.

Encryption Algorithm

The encryption algorithm used for PGP email encryption. You can choose from the following encryption algorithms:

• PLAN_TEXT

• IDEA

• TRIPLE_DES

• CAST5

• BLOWFISH

• AES128

• AES192

• AES256

• TWOFISH

Note

PLAIN_TEXT is a valid OpenPGP Symmetric-Key Algorithm; however, it should not be selected.

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.

Max Message Size

If the email size exceeds the specified maximum message size (in bytes), the message will not be PGP signed or encrypted. Large PGP messages may not be supported by some PGP email clients. Additionally, encrypting and signing large email messages can be resource intensive, which is another reason for limiting the size of PGP messages.

Convert HTML To Text

If enabled, and an email is encrypted or signed with PGP/INLINE, any HTML parts will be converted to plain 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 included in the PGP-encoded email. This provides an additional layer of security by allowing verification of the message’s integrity.

PGP Encoding

PGP encoding is used for emails sent to external domains. Two encoding methods are supported: PGP/MIME and PGP/INLINE. PGP/MIME encrypts and signs the entire MIME message and offers full support for HTML email. In contrast, PGP/INLINE signs and encrypts each MIME part separately. Support for HTML email with PGP/INLINE is limited, and not all email clients support it. Since PGP/INLINE processes the entire MIME message, it is generally more resource intensive.

Note

You are strongly encouraged to use PGP/MIME whenever possible. PGP/MIME fully supports HTML email and is less resource intensive.

Key Algorithm

The default key and size for PGP secret keys generated by the gateway. The following keys can be selected:

• RSA_1024

• RSA_2048

• RSA_3072

• RSA_4096

• ECC_NIST_P_256

• ECC_NIST_P_384

• ECC_NIST_P_521

• ECC_BRAINPOOL_P_256

• ECC_BRAINPOOL_P_384

• ECC_BRAINPOOL_P_512

Auto Publish Keys

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

Auto Request Key

If this option is enabled, and a message is PGP signed or encrypted, a new PGP secret key will be automatically generated for the sender if they do not already have a valid PGP secret key.

Import Import Keys From Mail

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

Note

Keys are imported from attachments only when the attachment’s content type is set to application/pgp-keys.

Auto Remove Keys From Mail

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

Note

Keys are removed from attachments only when the attachment’s content-type is set to application/pgp-keys.

Remove Signature

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

Auto Update Email Addresses

When enabled, any email address found in a valid User ID on a PGP key will be automatically linked to that key. If Auto update email addresses is not enabled, email addresses must be associated with the key manually.

Note

A key owner may associate any email address with a key, provided the User ID includes a valid self-signature. To ensure that only verified email addresses are linked to the key, disable the Auto update email addresses option and manually assign email addresses to the key.

Skip Sign Only

If this option is enabled, emails that are not PGP encrypted will not be PGP signed.

PDF

This section provides an overview of configuration options dedicated to PDF encryption.

PDF Encryption Enabled

When enabled, PDF encryption will be applied to all outgoing email messages.

Max Message Size

If the email size exceeds the defined maximum message size (in bytes), the message will not be PDF encrypted. Large PDF-encrypted messages may not be supported by some PDF clients.

Only Encrypt If Mandatory

When enabled, PDF encryption will be applied only when encryption is required—such as when Encrypt mode is set to mandatory, or when encryption is initiated through a subject trigger or a DLP rule.

Tip

The Only Encrypt If Mandatory option is useful when you want to apply opportunistic encryption, meaning encrypting with S/MIME or PGP when possible, but not using PDF Messenger unless encryption is required. When encryption mode is set to ALLOW, emails that cannot be encrypted with S/MIME or PGP will be sent using PDF Messenger by default. This may not be the desired outcome, as it results in most emails being routed through PDF Messenger. To ensure that PDF Messenger is used only when encryption is mandatory, enable the Only Encrypt If Mandatory setting.

Send Generated Password Back To Sender

When enabled, a password is automatically generated for the PDF, and a notification email containing the generated password will be sent to the sender of the original email. The sender is then responsible for securely transmitting the generated password to the recipient(s) of the password-protected PDF email.

OTP Enabled

If enabled, the One Time Password (OTP) mode for PDF encryption will be activated. In OTP mode, passwords for encrypting PDFs are generated using a combination of a Client secret and a Password ID. For further details on OTP mode, refer to the PDF encryption section.

Portal Auto Signup

If this setting is enabled and a PDF-encrypted email is sent to the recipient using OTP mode, the recipient will receive an email notification containing a link to register for the portal if they do not already have a portal account.

PDF Password

If provided, the PDF will be encrypted with the designated password for the recipient.

PDF Password Length

Specifies the length, in bytes, of randomly generated passwords used for PDF encryption.

Reply Enabled

If enabled, the encrypted PDF will contain a reply link. This link enables the recipient to securely send a response to the original message.

Note

Verify that the portal functionality is correctly configured and that the Reply sender is properly set up before using the reply feature.

Reply Cc

When enabled, a duplicate of the reply is transmitted to the user who originally submitted the response.

Tip

To guarantee that the Cc field is encrypted, configure the Encrypt mode of the Reply Sender to MANDATORY.

Reply validity interval

By default, the reply link embedded in an encrypted PDF does not have an expiration. To define an expiration period for the embedded reply link, set the Reply validity interval in seconds. If a user attempts to access a reply link after its expiration, a warning message appears to indicate that the link is no longer valid.

Sign PDF Email

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

Deep scan

When enabled, the entire email is scanned to detect attachments. This provides a workaround for non-standard MIME encoding used in emails generated by Apple Mail.

Add PDF Cover Page

When enabled, a PDF cover page will be inserted at the beginning of the encrypted PDF. This feature can be utilized, for example, to add a cover page displaying a company logo.

PDF Cover Page

Specify the PDF file to use as the cover page. The file must be a valid PDF and must not exceed 1 MB in size.

Attach original message

When enabled, the original email will be included as an EML file (RFC822) attachment within the PDF. The recipient can extract this EML file from the PDF and open it using a local mail application, such as Outlook. Since the original email is preserved as an attachment, all content—including HTML formatting—remains unchanged. The recipient may import the unencrypted original email into their email client for long-term storage.

Auto rename attachments

Email attachments are included in the encrypted PDF. Some PDF readers may block access to attachments with certain file extensions. For example, Adobe Acrobat may prevent access to attached ZIP files. The PDF encryption module can automatically rename the extensions of attachments to prevent the PDF reader from blocking access.

To access the original file, the attachment should be renamed back to its correct filename after extraction.

If Auto rename attachments is enabled, attachments with filenames matching any rule from the Attachments to rename list will be renamed by appending the specified keyword from 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.

Rename Filename List

Specify the filenames to be renamed, separated by spaces. Wildcard characters in filenames are supported.

Example:

*.zip some-file.txt *.exe

Rename Filename Keyword

Specifies the keyword that should be appended to a filename extension when the attachment is renamed.

PDF template

This is an HTML template written in Freemarker format that is used for generating the encrypted PDF.

Templates

Some actions require the gateway to send emails or SMS text messages. These messages are generated from message templates, which can be modified by the administrator.

Email templates are MIME-encoded messages, while SMS text templates are plain text templates. SMS text templates should be limited to 160 characters. If the final SMS text message exceeds 160 characters, it will automatically be sent as multiple text messages.

Templates are rendered with the Freemarker template engine. For further information, refer to https://freemarker.apache.org/.

Tip

When modifying a template, ensure that the resulting email templates produce valid emails that comply with the MIME standard.

Portal Signup Mail Template

This is the email template used for notifying users about their portal signup.

Portal Password Reset Mail Template

This is the template used for sending password reset emails from the portal.

Encrypted PDF Mail Template Static Password Mode

The email template contains an encrypted PDF that is protected with a static password.

Encrypted PDF Mail Template SMS Password Mode

The email template contains the encrypted PDF attachment, which is protected with a password. The password is generated automatically and delivered to the recipient separately via SMS.

Encrypted PDF Mail Template OTP Password Mode

The email template contains an encrypted PDF that is protected with a password generated by a one-time password (OTP) mechanism.

Failed Encryption Notification Template

This email template is utilized to send notifications when an encryption process does not complete successfully.

Encryption Notification Template

This template is used to generate the notification email that is sent when an email has been encrypted. It defines the content and formatting of the message provided to the recipient, informing them about the encryption event.

Passwords Notification Template

The email template utilized for dispatching notifications that include system-generated passwords.

SMS Password Template

Template used for generating the SMS message that includes the password required to open the PDF document.

DLP Warning Template

This template is used to create and deliver a notification email whenever a Data Loss Prevention (DLP) warning rule is triggered.

DLP Quarantine Template

This template is used to create and deliver a notification email when outgoing email is placed in quarantine due to DLP rule enforcement.

DLP Block Template

This template is used to create and deliver a notification email when Data Loss Prevention (DLP) rules prevent an outgoing email from being sent.

DLP Error Template

This template is used to generate and send a notification email when an error occurs during DLP checking.

DLP Release Template

This template is used to generate and deliver an email notification when a quarantined message has been released.

DLP Delete Template

This template is used to generate and deliver an email notification when a quarantined message was deleted.

DLP Expire Template

This template generates and sends an email notification when a quarantined message has expired and has been deleted as a result.

OTP Secret Password SMS

This email template is used for SMS text messages that deliver the OTP secret password to recipients.

OTP Secret

This is the email template that is utilized to deliver the encrypted OTP secret via email to the recipient.

Portal New Mail

Template used for notification emails that are sent to recipients upon the arrival of a new Webmail Messenger message.

Triggers

A trigger is a condition or rule within a system that, when met, automatically initiates a specific action or process. In the context of email security or gateway systems, a trigger might refer to a predefined criterion, such as a certain phrase in the subject line, a particular header, or some other message property—that causes the system to apply an action like encrypting an email.

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.

Sign Header

The Sign Header trigger initiates the process of signing an email using a specific header if the email has not yet been encrypted. This feature is useful for enforcing email signing in cases where the Skip Sign Only option is enabled.

Configure the Sign Header trigger with the following settings:

<HEADER>[:<REG_EXPR>]

Where <HEADER> refers to the header name and <REG_EXPR> is an optional regular expression pattern for the header value. If <REG_EXPR> is omitted, the header value is ignored and the trigger will be executed if the header name matches alone.

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*

Sign Header Enabled

If set to true, the Sign Header trigger will be enabled.

Sign Subject Regex

The Sign Subject Regex trigger starts the email signing process if the email subject contains a designated keyword. This functionality is helpful for enforcing email signing when the Skip Sign Only option is enabled. The subject line is evaluated against a configured regular expression.

Example:

With the following subject trigger, signing will be forced if the subject contains [sign] or [SIGN]:

(?i)(\[sign\])

Sign Subject Regex Enabled

If set to true, the Sign Subject Regex trigger will be enabled.

Sign Subject Regex Remove Pattern

If this option is enabled, the keyword in the subject that initiates the signing process will be automatically removed from the subject line before the message is sent.

Example:

Assume the trigger is set to [sign] and the subject of the email is The invoice [sign]. After the signing process, the subject will be updated to The invoice.

Encrypt Header

The Encrypt Header trigger initiates the process of encrypting an email using a specific header. This feature is useful for enforcing email encryption in cases where the Encrypt Mode is set no NO_ENCRYPTION.

Configure the Encrypt Header trigger with the following settings:

<HEADER>[:<REG_EXPR>]

Where <HEADER> refers to the header name and <REG_EXPR> is an optional regular expression pattern for the header value. If <REG_EXPR> is omitted, the header value is ignored and the trigger will be executed if the header name matches alone.

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*

Encrypt Header Enabled

If set to true, the Encrypt Header trigger will be enabled.

Encrypt Subject Regex

The Encrypt Subject Regex trigger starts the email encryption process if the email subject contains a designated keyword. This feature is useful for enforcing email encryption in cases where the Encrypt Mode is set no NO_ENCRYPTION. The subject line is evaluated against a configured regular expression.

Example:

With the following subject trigger, encryption will be forced if the subject contains [encrypt] or [ENCRYPT]:

(?i)(\[encrypt\])

Encrypt Subject Regex Enabled

If set to true, the Encrypt Subject Regex trigger will be enabled.

Encrypt Subject Regex Remove Pattern

If this option is enabled, the keyword in the subject that initiates the encryption process will be automatically removed from the subject line before the message is sent.

Example:

Assume the trigger is set to [encrypt] and the subject of the email is The invoice [encrypt]. After the encryption process, the subject will be updated to The invoice.

Skip Encryption Header

The header name, along with an optional regular expression, allows you to bypass encryption when an email header matches the specified trigger. This feature is useful if Encrypt Mode is set to MANDATORY but encryption cannot be applied for a specific recipient.

Configure the Skip Encryption Header trigger with the following settings:

<HEADER>[:<REG_EXPR>]

Where <HEADER> refers to the header name and <REG_EXPR> is an optional regular expression pattern for the header value. If <REG_EXPR> is omitted, the header value is ignored and the trigger will be executed if the header name matches alone.

Skip Encryption Header Enabled

If set to true, the Skip Encryption Header trigger will be enabled.

Skip Encryption Subject Regex

The Skip Encryption Subject Regex trigger skips the encryption process if the email subject contains a designated keyword. This feature is useful for enforcing email encryption in cases where the Encrypt Mode is set no MANDATORY but encryption cannot be applied for a specific recipient. The subject line is evaluated against a configured regular expression.

Example:

With the following subject trigger, encryption will be skipped if the subject contains [skip] or [SKIP]:

(?i)(\[skip\])

Skip Encryption Subject Regex Enabled

If set to true, the Skip Encryption Subject Regex trigger will be enabled.

Skip Encryption Subject Regex Remove Pattern

If this option is enabled, the keyword in the subject that initiates the skip encryption process will be automatically removed from the subject line before the message is sent.

Example:

Assume the trigger is set to [skip] and the subject of the email is The invoice [skip]. The subject of the email sent to the recipient will be updated to The invoice.

Subject Password Trigger

With the Subject Password Trigger, the sender can provide a password within the email’s subject line. This password is extracted from the subject and utilized to encrypt the PDF generated from the email. Before the email is sent, the entire trigger, including the password, is removed from the subject line.

Keep in mind that the Subject Password Trigger is applied only when the Subject Password Trigger Enabled setting is set.

To ensure security, the password is validated against the configured password policy. If the password does not meet the strength requirements, the email will not be sent and the sender will receive a notification.

The Subject Password Trigger should be specified as a Regular Expression. The Regular Expression group name <pw> is used for the extracted password.

Example:

With this subject, the PDF will be encrypted with the password not-so-random-password:

Subject: Hi! pw=not-so-random-password

Subject Password Trigger Enabled

When enabled, the Subject Password Trigger is activated.

OTP Encrypt Header

The Encrypt Header trigger starts encrypting an email as a PDF using a one-time password (OTP) whenever a specified email header is present or matches the configured value.

Note

Before you turn on the OTP Encrypt Header option, confirm that OTP mode is set up correctly.

Configure the OTP Encrypt Header trigger with the following settings:

<HEADER>[:<REG_EXPR>]

Where <HEADER> refers to the header name and <REG_EXPR> is an optional regular expression pattern for the header value. If <REG_EXPR> is omitted, the header value is ignored and the trigger will be executed if the header name matches alone.

Example:

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

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

Example:

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

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

OTP Encrypt Header Enabled

If set to true, the OTP Encrypt Header trigger will be enabled.

OTP Encrypt Subject Regex

The OTP Encrypt Subject Regex trigger starts encrypting an email as a PDF using a one-time password (OTP) whenever the email subject contains a designated keyword.

Example:

With the following subject trigger, OTP PDF encryption will be forced if the subject contains [otp] or [OTP]:

(?i)(\[otp\])

OTP Encrypt Subject Regex Enabled

If set to true, the OTP Encrypt Subject Regex trigger will be enabled.

OTP Encrypt Subject Regex Remove Pattern

If this option is enabled, the keyword in the subject that initiates the encryption process will be automatically removed from the subject line before the message is sent.

Example:

Assume the trigger is set to [otp] and the subject of the email is The invoice [otp]. After the encryption process, the subject will be updated to The invoice.

Webmail Messenger Header

The header name and an optional regular expression used to route emails through Webmail Messenger when the email header matches the specified trigger.

Configure the Webmail Messenger Header trigger with the following settings:

<HEADER>[:<REG_EXPR>]

Where <HEADER> refers to the header name and <REG_EXPR> is an optional regular expression pattern for the header value. If <REG_EXPR> is omitted, the header value is ignored and the trigger will be executed if the header name matches alone.

Example:

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

X-Webmail
X-Webmail:
X-Webmail:*.

Example:

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

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

Webmail Messenger Header Enabled

If set to true, the Webmail Messenger Header trigger will be enabled.

Webmail Messenger Subject Regex

The message is delivered via Webmail Messenger if the email subject contains a designated keyword. The subject line is evaluated against a configured regular expression.

Example:

With the following subject trigger, the message will be delivered via Webmail Messenger if the subject contains [webmail] or [WEBMAIL]:

(?i)(\[webmail\])

Webmail Messenger Subject Regex Enabled

If set to true, the Webmail Messenger Subject Regex trigger will be enabled.

Webmail Messenger Subject Regex Remove Pattern

When this option is enabled, any keyword in the subject line that triggers sending the email through Webmail Messenger will be automatically removed from the subject line before the message is sent.

Security info

Once the gateway decrypts the email, there is no explicit evidence that the message was originally encrypted. To address this, the gateway can be configured to append security-related details, such as the encryption or signature status, to the email’s subject line.

Tip

This section focuses only on the security information included in the subject line of the email. However, the S/MIME and PGP handlers will also add CipherMail-specific email headers (X-CipherMail-Info) that can be used to verify the security details of received emails. For more information, refer to the S/MIME and PGP sections.

Add security info

When this option is enabled, if an incoming email is encrypted or signed using S/MIME or PGP, details about its security properties, such as whether encryption was used, will be appended to the subject line.

Decrypted Tag

If an incoming message is encrypted, the Decrypted Tag will be appended to the subject line.

Signed Valid Tag

If an incoming email message is digitally signed and the signature is verified as valid, the gateway will add the Signed Tag to the subject line of the message.

Signed By Valid Tag

If an incoming message is signed and the signature is valid, but the sender’s email address (the From header) differs from the email address specified in the signing certificate, the SSigned By Valid Tag will be added to the subject line. In this case, %s will be replaced by the email address from 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].

Signed Invalid Tag

If an incoming email is signed but the signature cannot be validated (for example, if the signing certificate is not trusted), the subject line will include the Signed Invalid Tag.

Warning

An external sender can add security information tags to a message, making it appear as though the message has been protected. As such, the mere presence of these security tags should not be relied upon as evidence that the message was actually encrypted or signed. Verification that a message was truly signed or encrypted can only be performed by examining the X-CipherMail-Info headers. To prevent external senders from falsely indicating that a message is signed or encrypted by adding these tags, use the Subject filter” to remove all security information tags from incoming email before processing. This ensures that spoofed security headers are not accepted.

Mixed Content Tag

If only a portion of the message is signed, the subject will include the Mixed Content Tag. This situation can occur exclusively with PGP/INLINE signed emails, as PGP/INLINE permits the signing of only specific parts of a message.

CA

The Certificate Authority (CA) section includes settings for certificate generation, which are required for use with S/MIME.

Note

The use of default Certificate Authority (CA) settings depends on the CA configuration. The Certificate Authority may use the provided default settings or override them with its own configuration.

Default Common Name

Specifies the default Common Name that will be applied to requested certificates.

Default Validity

Specifies the default number of days a requested certificated will be valid.

Default Key Length

Indicates the default length, in bits, for the private and public keys generated when creating a certificate request.

Default Signature Algorithm

Defines the default signature algorithm that will be applied when generating a certificate request.

Default CRL Distribution Point

Defines the default CRL Distribution Point added to a locally generated certificate. This option is only used with the built-in CA.

Default Request Handler

A certificate request is processed by a certificate request handler. The gateway supports multiple request handlers, such as GlobalSign, CSR, CMP, and CEMA request handlers. The Default Request Handler setting determines which request handler will be used as the default.

DLP

This section contains settings related to the Data Leak Prevention (DLP) module.

DLP Enabled

When enabled, DLP checking is applied to emails sent to external domains.

Tip

Enabling DLP checking activates the DLP engine, but no DLP rules are enabled by default. To ensure DLP scanning inspects content according to your policies, you must add and configure specific DLP rules.

DLP managers

A comma-separated list of email addresses for DLP managers. Depending on specific configuration options, such as Send Warning To DLP Managers and Send Quarantine To DLP Managers, notifications will be sent to these email addresses if DLP rules are violated.

Send Warning To Originator

If this option is enabled and a DLP warning rule is triggered, the system will send a warning notification email to the sender.

Send Warning To DLP Managers

If this option is enabled and a DLP warning rule is triggered, the system will send a warning notification email to the registered DLP managers.

Send Quarantine To Originator

If this option is enabled and a DLP quarantine rule is triggered, the system will send a quarantine notification email to the sender.

Send Quarantine To DLP Managers

If this option is enabled and a DLP quarantine rule is triggered, the system will send a quarantine notification email to the registered DLP managers.

Send Block To Originator

If this option is enabled and a DLP block rule is triggered, the system will send a block notification email to the sender.

Send Block To DLP Managers

If this option is enabled and a DLP block rule is triggered, the system will send a block notification email to the registered DLP managers.

Send Error To Originator

If this option is enabled and an error occurs during DLP scanning, the system will send a notification email to the sender.

Send Error To DLP Managers

If this option is enabled and an error occurs during DLP scanning, the system will send a notification email to the registered DLP managers.

Quarantine On Error

If this option is enabled and an error occurs during DLP scanning, the email will be quarantined.

Quarantine On Failed Encryption

If email encryption is enabled and set to mandatory, and the email cannot be encrypted, the email will be quarantined.

Send Release Notification To Originator

When an email is released from quarantine, the sender receives a notification indicating that their email has been successfully released.

Send Release Notification To DLP Managers

When an email is released from quarantine, a notification message confirming the release is sent to the DLP managers.

Send Delete Notification To Originator

When an email is deleted from quarantine, the sender receives a notification indicating that their email has been deleted.

Send Delete Notification To DLP Manager

When an email is removed from quarantine, DLP managers are notified that the email has been deleted.

Send Expire Notification To Originator

When an email is removed from quarantine due to expiration, the sender is notified that their email has expired and has been deleted as a result.

Send Expire Notification To DLP Managers

When an email is removed from quarantine due to expiration, the DLP managers are notified that the email has expired and has been deleted as a result.

Portal

The CipherMail Portal can be configured to enable external recipients to retrieve a PDF password in OTP mode, reply to a PDF, or view and respond to messages received through Webmail Messenger. External recipients must have an account on the portal to log in. The portal can be set up to automatically send an email with a signup link when necessary. For further details about using PDF encryption and the portal, refer to the PDF section. For additional information about the Webmail Messenger portal features, consult the Webmail Messenger section.

Portal Password

The portal login password for external users. Users must set their own password when they receive a portal invitation for the first time. The chosen password is validated according to the Portal Password Policy. Alternatively, the administrator can set the portal password on behalf of the user.

Portal Enabled

When enabled, this option permits the external user to log in to the portal.

Note

The Enabled setting determines whether a user is allowed to log in to the portal. If this setting is not enabled, the user will be unable to access the portal; however, they can still reply to a PDF, as replying does not require user login.

Portal Two-Factor Authentication Enabled

Indicates whether the user has activated a TOTP token.

Portal Base URL

The Base URL specifies the root URL through which external users can access portal features. It must be a fully qualified URL that is externally resolvable. Several portal links, such as the reply link and portal login URLs, are derived from the Base URL. Configure the Base URL using the following guidelines:

https://www.example.com

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

Tip

Since the Base URL serves as the foundation for other system URLs, it is essential to ensure that it is configured correctly.

Portal Password Policy

The password policy ensures that user selected passwords for the portal are of sufficient strength.

See Password Policy Syntax on how to configure a password policy.

In addition to the password policy, the chosen password must also comply with the following supplementary rules:

• Should not based on the users email address.

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

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

Note

An administrator may assign any portal password to a user. There are no enforced password strength requirements when a password is set by an administrator.

Reply Attachments Max Size

The maximum allowed combined size, in bytes, of all attachments included in a PDF or Webmail Messenger reply.

Reply Body Max Size

The maximum allowed combined size, in bytes, of the message body in a PDF or Webmail Messenger reply.

Reply sender

If both Reply Sender and Use reply sender are enabled, the envelope sender of the PDF reply message will be set to the value specified in Reply sender. Additionally, the local part of the From header in the reply message will be set to the replying user’s email address, prefixed with in name of.

Example:

If Reply sender is configured as reply@example.com and the user test@example.com responds to the encrypted PDF, the reply will be sent by reply@example.com. The email’s From header will be set as "in name of test@example.com" <reply@example.com>.

If a Reply sender is not specified (which is the default setting), the reply message will be sent using the sender address of the user who responds.

Tip

Using the actual email address of the responder may cause issues if reply emails are delivered to a server that enforces SPF or DMARC verification. In such cases, it is advisable to configure the Reply sender to use a recognized internal email address.

Reply sender Enabled

If enabled, and a Reply sender is specified, the Reply sender email address will be used as the sender address for the PDF reply email.

Webmail

This section covers only the settings that are specific to Webmail Messenger. For instructions on using and configuring Webmail Messenger, refer to the dedicated Webmail Messenger section.

Enabled

When enabled, Webmail Messenger will be activated for the recipient.

Portal Auto Signup

If enabled, a sign-up link for the portal will be sent to the user if they have not yet configured a portal password.

Allowed Recipients

This setting controls which domains or email addresses you’re allowed to send messages to from webmail. In most setups, you should enable this for your organization’s internal domains.

You can configure:

• Allowed list: recipients (domains or specific addresses) you can send to.

• Blocked list: recipients (domains or specific addresses) you cannot send to.

Example:

To allow messages to anyone at example.com but block messages to no-reply@example.com:

• Add example.com to the Allowed list.

• Add no-reply@example.com to the Blocked list.

Warning

When you add an asterisk (*) to the allow list, any webmail user can send email to any recipient. If you apply this in Global Settings, all webmail users will be able to send email to any external address.

Is Reply Allowed

If enabled, the Webmail Messenger user has permission to reply to a received email message.

Is Create New Email Allowed

When enabled, the Webmail Messenger user is granted permission to compose a new email message.

Max Recipients

Specifies the maximum number of recipients that can be included when composing a new email or replying to an existing email.

Only If Mandatory

When enabled, Webmail Messenger will be used only when encryption is required—such as when Encrypt mode is set to mandatory, or when encryption is initiated through a subject trigger or a DLP rule.

Quota

Disk Quota (in bytes) for email stored in the Webmail Messenger Inbox.

Auto Expunge Enabled

When this option is enabled, emails that are older than the specified Auto Expunge interval will be deleted automatically.

Warning

If possible, enabling Auto Expunge is recommended to help avoid running out of disk space.

Auto Expunge Interval

Emails that are older than the Auto Expunge Interval (in days) will be automatically deleted if the Auto Expunge feature is enabled.

Read receipt

When enabled, a read receipt header is included in the email message. A notification email will be sent to the sender when the recipient opens the message. Alternatively, the sender can request a read receipt directly from their email client when composing and sending the email.

Note

This receipt confirms only that the message was displayed on the recipient’s device. It does not guarantee that the recipient has read or understood the contents of the message.

SMS

The CipherMail gateway is capable of sending SMS text messages through a remote SMS gateway. The SMS feature is utilized for sending passwords, such as those required to open a PDF file.

This section outlines the configuration settings specific to SMS functionality.

SMS Phone number

Specifies the recipient’s phone number for sending SMS text messages. The phone number must be provided in international format, including the country code.

SMS Send Enabled

When enabled, the message sender is permitted to transmit SMS text messages.

SMS Receive Enabled

When enabled, the recipient is permitted to receive SMS text messages.

SMS Phone Number Set Enabled

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) “-()”.

When this feature is enabled, senders can include a telephone number at the end of the subject line in an outgoing message. This telephone number is utilized by the PDF encryption functionality to send passwords using SMS text messages. The telephone number will only be used if the subject trigger is present (refer to Subject trigger) and if the telephone number is located at the end of the subject line. Telephone numbers may begin with a + and can include spaces, as well as the following characters: - ( )

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]

Warning

Only one recipient is supported if a telephone number is included in the subject line. This means you can specify just one address in either the To, Cc, or Bcc field. If there are multiple recipients, it would not be possible to associate the correct telephone number with each recipient. As a result, messages with more than one recipient will not be sent, and the sender will receive a notification.

SMS Phone Number Default Country Code

If a telephone number begins with a zero (0), indicating it is not a country code, the server will prepend the default country code to the telephone number. The default country code is applied only when the telephone number is specified in the subject.

SMS Active Transport

The gateway supports multiple SMS transport types; however, only one transport can be active at a time. The SMS Active Transport setting specifies which SMS transport is currently enabled.

Notifications

The gateway is capable of sending system notifications by email to registered email addresses when specific events occur. For instance, a notification is sent whenever a certificate is imported

Notification Email Enabled

When enabled, the system will send notification emails automatically.

Notification Email From

The sender of the notification emails.

Notification Recipients

A comma separated list of email recipients of the notification messages.

Notification Template

Specifies the email template that is utilized to generate the notification email.

Licensing

This section is related to assigning licensed users.

Auto assign license

When enabled, a license will be automatically assigned to the sender. Only senders with a valid license are permitted to use encryption.

Tip

The Auto assign license feature is applicable only when the license has a limited number of users. For licenses that allow an unlimited number of users, senders will not be counted.

DKIM

DomainKeys Identified Mail (DKIM) provides digital signing of email at the gateway level. The gateway signs the entire email—including certain user-specified headers—using a private key. A corresponding public key must be published in DNS using a DKIM-specific name.

One key difference between S/MIME and DKIM signing is in who validates the signature. With S/MIME, the signature is usually verified by the end user, while DKIM signatures are validated by the receiving mail server. Another important distinction is their approach to trust: S/MIME employs a hierarchical trust model based on X.509 certificates, whereas DKIM relies on keys published in DNS.

DKIM can be used in addition to S/MIME and should be enabled whenever possible, as it helps to prevent email spoofing. Further background information about DKIM is available at https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail.

The gateway may be configured to DKIM-sign all outgoing messages. DKIM keys can be specified globally, by domain, or by sender.

Tip

It is recommended to configure DKIM keys only for domains that are used as sending domains. For instance, DMARC requires that the d= parameter in the DKIM signature matches the domain of the sender.

DKIM Key Pair

The DKIM key pair is used for DKIM signing. A DKIM key pair is automatically generated. A newly generated key can be uploaded.

DKIM Enabled

If enabled, outgoing email will be DKIM signed.

DKIM Key Identifier

The DKIM key identifier specifies the DKIM key that is stored in the DNS records.

DKIM 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.

Tip

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