Mail Processing

The menu item Mail Processing is used to configure the ruleset of the SEPPmail Secure E-Mail Gateway.

This set of rules is comparable to a workflow system and represents the central element of the SEPPmail Secure E-Mail Gateway.

To set up specific encryption methods for individual targets, Edit policy table... provides access to the submenu ENCRYPTION POLICY. This submenu can be used to define corresponding rules, also separated by clients.

(new in 13.0.0)

Via Edit extended fields..., the submenu Extended Fields is available. Here, additional configuration fields can be defined, with which indicators (general or specific for the Managed Domain or the Customer) can be created that later can be used to trigger specific behaviours via the SMTP Ruleset.

Sections on this page:

•SMTP Ruleset

•Miscellaneous options

•Ruleset generator

Section SMTP Ruleset

Displays the creation data of the active ruleset.

Parameters		Description
Version		Displays the firmware version with which the current ruleset was created and/or uploaded.
Creator		Displays the user who has activated the current ruleset.
Date		Displays the activation date of the current ruleset.
Type		Displays how the ruleset was created.
	Generator	Via Generate ruleset with the settings displayed and/or made under Ruleset generator.
	Upload	Via Upload Ruleset
Details		Accessing Show ruleset displays the Ruleset code.

Generate Ruleset generates a ruleset with the settings displayed and/or made under Ruleset generator.

empty

Note:

If a ruleset of the Type "Upload" is active, Generate Ruleset is greyed out.

To be able to change the Type to "Generator", in the Ruleset generator, the button Save must be clicked twice!

Upload ruleset... imports a code that may have been written manually with the help of the Reference Of The Ruleset Instructions from the selected file.

Generally, this is not recommended, since this ruleset may have to be adapted during version updates. It usually makes more sense to adapt the code individually using Custom commands of the Ruleset generator.

empty

Note:

The ruleset must be generated at least once after the initial installation.

Section Miscellaneous options

Other settings.

Parameters

Description

Enable LDAP server on port 388, 387 and 635 to distribute collected S/MIME certificates to internal users: DropDown

Enables access to the encryption certificates of external communication partners available on the SEPPmail Secure E-Mail Gateway, which are listed under X.509 Certificates.

empty

Note:

This, for instance, enables senders who must carry out a direct encryption at the client by means of additional hardware to access the collected key material of the SEPPmail Secure E-Mail Gateway via an LDAP address book.

Off

Default setting.

Server

Activates the LDAP key server function of the SEPPmail Secure E-Mail Gateway for the certificates listed under X.509 Certificates.

CheckBoxInactive Send new OpenPGP public keys to users when a key is created with template DropDown

This option is inactive by default and pre-set to "sendpgpkeys".

If an OpenPGP key pair is created for a user on the SEPPmail Secure E-Mail Gateway, irrespective of whether this is done manually or automatically (see section Ruleset generator of this menu under Key generation, the option Issue local OpenPGP keys for users), by activating this option, the public key of the automatically generated key pair is sent to the newly created user using the selected email template (please also refer to LIST TEMPLATE).

This enables this user to pass on their public key to communication partners themselves. These are, in turn, enabled to communicate with this user in an OpenPGP-encrypted manner.

The email template used for sending can be individually overridden for each Managed domain (see Send OpenPGP keys). The sender of this email is the global postmaster, if no individual postmaster has been stored.

empty

Note:

Distributing the public OpenPGP key to communication partners always implies that the checksum (hash) of this key is subsequently checked before it is used by the communication partner on a second channel - for example by telephone. This is necessary to ensure the integrity of the key.

For this reason, it is recommended to provide the OpenPGP keys via the GINA technology (see CHANGE GINA SETTINGS FOR Extended settings Enable S/MIME certificate / OpenPGP key search and management in GINA).

The changes made are saved via the Save button.

Section Ruleset generator

With the Ruleset generator, a "workflow system" is defined for incoming and outgoing emails.

empty

Note:

When using frontend servers (see Cluster Add this device as frontend server), every change in the Ruleset generator is to be made public by saving at the frontend server again (Generate Ruleset).

The input fields available in this section for subject line keywords (text in subject) are to be filled with "regular expressions". This means special characters must be marked as such with a backslash "\". It is possible to string several keywords together by separating them with the pipe character "|".

Example:

If as subject line keywords <abc> are to be used, this must be entered as follows: \<abc\>

If as subject line keywords |<abc> and also [def] are to be used, this must be entered as follows: \<abc\>|[def]
(see also Regular Expressions)

Upper/lower case is ignored when entering the keyword in the subject line.

When using the COM Add-In for MS Exchange/Outlook on premises in the subject line mode (see Registry value "subject-mod=1”), care should be taken to ensure that when the keywords are changed in the SEPPmail Secure E-Mail Gateway, these are either added as additional values, or the values in the add-in (see Registry values "s-sm...") are adapted to the values of the appliance.

If the MS Outlook Cross-Platform-Add-In and/or COM Add-In for MS Exchange/Outlook on premises are run in X-Header mode (see Registry value "subject-mod=0"), it should be noted that the function triggered by the respective X-header is also active in the Ruleset generator.

empty

Note:

Generally, all keywords defined here are removed from incoming emails, i.e. emails which do not originate from a Managed domain.

This means that no external control commands can be transferred to the appliance, nor can cryptographic actions performed by the appliance (decryption, verification of signatures) be simulated.

empty

Note:

To prevent a creation of undefined conditions on the appliance, the simultaneous use of different and, in particular, contradicting control characteristics (key words, (X) headers) in outgoing emails must be avoided!

Additionally, a keyword cannot be used to control two actions at the same time.

Parameters

Description

General settings

CheckBoxActive Do not touch mails with the following text in subject:

By default, this option is active and set to \[plain\].

If this option is active and the specified keyword is found in the subject of an outgoing email, it will be forwarded in a cryptographically untreated manner. The ruleset will not continue to run through.

This may make sense if all of the following conditions are met:

•Setting Always use S/MIME or OpenPGP if user keys are available active

•The sender knows that the recipient can temporarily only receive emails on a mobile terminal device

•The content of the email is not confidential

Add disclaimer to all outgoing and internal emails

(in 12.0 moved to Edit managed domain "X” Settings Disclaimer Initial disclaimer)

Also add disclaimer to replies (in-reply-to header set)

(in 12.0 moved to Edit managed domain "X” Settings Disclaimer Reply disclaimer)

CheckBoxActive Reprocess mails sent to

reprocess@

decrypt.reprocess

By default, this option is active.

Enables a recipient to send an encrypted email from their inbox to the SEPPmail Secure E-Mail Gateway again for decryption. For this purpose, the encrypted email is to be attached to a new (carrier) email and sent to the address reprocess@decrypt.reprocess. "reprocess@decrypt.reprocess". The SEPPmail Secure E-Mail Gateway discards the carrier email, and the original, encrypted message in it is processed again and delivered. Naturally, one precondition is that the required private key for decryption on the SEPPmail Secure E-Mail Gateway is known.

Application examples include:

•Direct forwarding of encrypted emails to the internal email server if the appliance fails

•Migration of local key material on the clients to the SEPPmail Secure E-Mail Gateway in the case of the simultaneous retention of encrypted emails in the inboxes of the recipient

Likewise, this command allows OpenPGP to decrypt encrypted files from the file system by sending them as an email attachment to this address.

CheckBoxInactive Place new tags at the beginning of the subject

By default, this option is inactive.

By activating this item, marks set by the appliance (e.g. see Add this text to message subject after decryption or Add this text to message subject if S/MIME signature check succeeds:) are placed at the beginning instead of the end.

CheckBoxActive Log message metadata

By default, this option is active.

Activates the display of the subject line in Logs. This often simplifies the error analysis. However, for revision-related reasons, it might be prohibited in some cases.

User creation

empty

Note:

The behaviours described here for the automatic creation of users (please also refer to Users) shall only apply 100% if they have not been overridden by Custom commands.

For generating new users, the SMTP address of the FROM header is used.

RadioButtonInactive Do not create accounts (also disables custom commands for user creation)

Users must be created manually on the appliance - if necessary also by bulk imports (see Administration Bulk Import Import users (CSV), Import X.509 keys and certificates and/or Import OpenPGP key pairs).

empty

Note:

If this setting is selected, it is to be ensured that no sender who has not already been created as a user in the SEPPmail Secure E-Mail Gateway uses characteristics (keyword, add-in, header) for the cryptographic treatment of emails.

In this constellation, the request would be ignored and thus the email would be sent without the desired cryptographic action.

If necessary, this behaviour can be modified by Custom commands to reject emails in this constellation (see Bounce Emails From Unauthenticated Users).

RadioButtonActive Create accounts for new users if user tries to sign/encrypt

Default setting.

Senders who mark an email as to be encrypted or to be signed using an appropriate feature and who are not yet present as users (see Users) on the SEPPmail Secure E-Mail Gateway are automatically created.

When using this option, it is to be ensured that sufficient free user licences are available (see Home Licenses Encryption/Signature licenses).

If the number of available licences is exceeded, emails are rejected (bounced) with the information message "license violation" and a watchdog notification is created.

empty

Note:

If Custom commands are used, they are processed in the order Custom Commands For Outgoing Emails BEFORE Encryption, Custom commands for user creation.

RadioButtonInactive Create accounts for all users

Each sender who sends an email via the SEPPmail Secure E-Mail Gateway is created as a user unless already present. It does not matter whether encryption/signing was requested or not.

This setting is suitable, for example, for signing all emails from a company in general. Of course, it must then also be ensured that the users created here are provided with the corresponding key material (see also Key generation).

This option can also be used if the SEPPmail Secure E-Mail Gateway is not directly located in the email flow but it is already decided via an upstream component which emails are to be treated cryptographically and only those are transferred to the SEPPmail Secure E-Mail Gateway.

empty

Note:

If Custom commands are used, they are processed in the order Custom commands for user creation, Custom Commands For Outgoing Emails BEFORE Encryption.

Processing of outgoing mails that are not from a managed domain (based on FROM-Header)

empty

Note:

These are usually calendar entries that are received by external communication partners and forwarded by the internal mailbox to another external communication partner.

Since Outlook/Exchange cannot handle encrypted calendar entries, calendar entries should generally not be encrypted. However, this also implies that no confidential data should be transmitted in calendar entries.

RadioButtonActive Process normally

Default setting.

This option does not distinguish between outgoing emails from third-party or Managed Domains (see Mail System Managed domain). That is that, if an email contains an address in the FROM header which does not originate from a Managed domain, users are also created for senders of external addresses, provided that an option for automatic user creation (see above) is selected.

empty

Note:

This setting may be useful to strictly enforce a company guideline. Thus, emails which are sent by an automatic forwarding rule and therefore contain the original (third party) sender in the FROM header, for example, are mandatorily encrypted, if applicable.

empty

Note:

The following points are to be observed in regard to this setting:

1.Under certain circumstances, this setting tries to create a certificate of the local CA and/or an OpenPGP key for the (third-party) user.
Obtaining certificates for third-party users via MPKI is prevented.

2.If GINA is still used as the encryption technology due to the lack of key material of the recipient, the initial password is sent out to the (third-party) user, in some cases even without encryption.
This also means that, depending on the setting, the external (third-party) user would also be addressed during the password reset process.

3.In client-capable systems, the generated user cannot be automatically assigned to a client because the (third-party) email domains cannot be assigned.
This also means that log entries of such emails can only be seen by members of the (Groups) admin group, but not by the client admin (see Customers Customer Management Customer administrators).

RadioButtonInactive Immediately deliver unchanged

This option always sends emails by external senders unchanged, i.e. "plain" (see also General settings Do not touch mails with the following text in subject:).

empty

Note:

With this setting, under certain circumstances, originally encrypted emails are subsequently sent to the Internet as plain text!

In client-capable systems, the log entries of such (third-party) emails cannot be automatically assigned to a client because the (third-party) email domain cannot be assigned.
This means that log entries of such emails can only be seen by members of the (Groups) admin group, but not by the client admin (see Customers Customer Management Customer administrators).

RadioButtonInactive Reject

This option rejects any emails from third-party senders.

Key generation

empty

Note:

With the automatic generation of a new User, the set key material is generated. This is then kept up-to-date by the process described in the following note.

empty

Note:

An automatic, nightly supply of key material for all Users (irrespective of the User creation settings), and/or the early renewal of key material which is about to expire soon, can be realised for local S/MIME and OpenPGP keys in the CAsettings (Settings), and/or for external certificates in the respective MPKIsettings (Settings) (see option Automatically create certificates for active users without certificates and/or Automatically renew expiring certificates if validity days left less than). This automatic prolongation works independently of the options set here.

empty

Note:

If no valid key material is available for a user during the validity period, the corresponding key material is created on the fly when sending an email, if the settings are active.

Since, for this process, the function User creation is used, possibly available Custom commands for user creation are processed.

Here, the email is initially temporarily rejected (420 An encryption key for your account '$senderemail' will be available shortly, so for example 420 An encryption key for your account 'john.doe@mycompany.tld' will be available shortly). With the next delivery attempt of the issuing system, the required key material should be available so that the email can be processed as expected.

For example because the User was created manually or was not supplied via the nightly process due to a longer period of absence.

If the last existing certificate was revoked, no new certificate is obtained. In this case, it can be assumed that there was a special reason for manually revoking the certificate without generating a new one.

CheckBoxInactive Issue local OpenPGP keys for users

By default, this option is inactive.

Automatically creates an OpenPGP key pair.

CheckBoxInactive Issue local

S/MIME certificates for users

By default, this option is inactive.

Automatically generates an S/MIME key pair. The public key is signed by the local CA (self-signed certificate).

CheckBoxInactive Issue <MPKI> S/MIME certificates for users

By default, this option is inactive.

Automatically generates an S/MIME key pair. The public key is signed by the CA set under MPKI.

empty

Note:

This option only appears if a CA has been selected under MPKI.

Encryption

empty

Note:

With S/MIME-encrypted emails, two expressions are possible as "Content-Type" of the header, namely

a."application/x-pkcs7-mime"
This expression was widely used before the standard was established and is therefore still common (see also RFC 2311).

b."application/pkcs7-mime"
This expression corresponds to RFC5751 and is also common.

The SEPPmail Secure E-Mail Gateway processes both expressions equally in incoming emails. For outgoing emails, version a. is used.

In the event of receiving third-party systems, it is to be ensured that these also process both versions equally, to also prevent incompatibilities from the other side.

empty

Note:

Only the recipients from the envelope are used for encryption and decryption, as the headers can be manipulated.

Incoming e-mails

CheckBoxActive Add this text to message subject after decryption

By default, this option is active and has the keyword \[secure\] stored.

Incoming emails which are decrypted by the SEPPmail Secure E-Mail Gateway are marked with the keyword in the subject line.

CheckBoxInactive Set confidential flag after decryption:

By default, this option is inactive.

For incoming emails which are decrypted by the SEPPmail Secure E-Mail Gateway, the header "Sensitivity" with the value "Company-Confidential" is set.

CheckBoxActive Reject mails if

S/MIME decryption fails

By default, this option is active.

Incoming, encrypted emails are rejected (bounced) if they could not be decrypted by the SEPPmail Secure E-Mail Gateway.

empty

Note:

Since the SEPPmail Secure E-Mail Gateway only reports an email as accepted to a possibly upstream system when the email can be delivered, this function is also easily available downstream to an external SPAM filter, for example.

empty

Note:

By activating this action, a possible partial end-to-end encryption (e.g. by means of smart card) is prevented as well.

Outgoing e-mails

empty

Note:

If outgoing emails which are already S/MIME-encrypted are sent to the SEPPmail Secure E-Mail Gateway, these are forwarded in an untreated manner, since no double encryption is possible with S/MIME.

CheckBoxActive Always encrypt mails with the following text in subject:

By default, this option is active and has the keyword \[confidential\] stored.

If the specified keyword is found in the subject line of an outgoing email, it will be encrypted.

empty

Note:

If the keyword from Incoming e-mails Add this text to message subject after decryption is used here and/or additionally added, i.e. \[confidential\]|\[secure\], all replies to emails originally received in an encrypted form would be mandatorily encrypted.

Since the encryption of replies to originally domain-encrypted emails is thus also required, care must be taken here in connection with the automatic creation of users (see User creation Create accounts for new users if user tries to sign/encrypt)!

empty

Note:

The keyword(s) used here must differ from those used for the signature (see Signing Outgoing e-mails "S/MIME sign outgoing mails with the following text in subject:").

CheckBoxActive Always encrypt mails with Outlook "confidential" flag set

By default, this option is active.

If an outgoing email includes the header "Sensitivity" with the value "Company-Confidential", the email will be encrypted.

CheckBoxActive Always use GINA technology for mails with the following text in subject:

This option is active by default and has the keyword \[priv\] stored.

If the specified keyword is found in the subject line of an outgoing email, encryption is enforced using the GINA technology.

empty

Note:

If, in addition to enforcing the GINA technology, a read confirmation (disposition-notification to header) is requested in the email client, a reliable read confirmation is requested via this technology. This means that the recipient cannot suppress the triggering of this read confirmation – in contrast to MS Outlook, for example.

CheckBoxInactive Always use GINA technology for mails with Outlook "private" flag set

By default, this option is inactive.

If an outgoing email includes the header "Sensitivity" with the value "Private", encryption is enforced using the GINA technology.

empty

Note:

This option can cause problems if calendar entries marked as private are sent, because they would be automatically encrypted by GINA.

CheckBoxInactive Create GINA users with empty password if the following text is in the subject:

By default, this option is inactive and has the keyword \[emptypw\] stored.

If the indicated keyword is found in the subject line of an outgoing email,

no initial password will be required for the initial use of the GINA technology.

This means that, in some cases, GINA version 2a (see Different Registration Types) is activated.

CheckBoxActive Always use

S/MIME or OpenPGP if user keys are available

By default, this option is active.

Outgoing emails are always encrypted if a public key – S/MIME (see X.509 Certificates) or OpenPGP (see OpenPGP Public Keys) – is available for the communication partner (recipient).

empty

Note:

If this option is active, the sender of the email has to be registered as a user at the SEPPmail Secure E-Mail Gateway if they send an email to a corresponding communication partner. Otherwise the email will be rejected.

The resulting interaction with the configured automatic creation of users (see User creation Create accounts for new users if user tries to sign/encrypt) is to be observed!

CheckBoxInactive Exclude calendar entries and RTF mails (winmail.dat)

By default, this option is inactive.

Calendar entries as well as RTF-formatted emails are excluded from the automatic encryption of the higher-level option.

empty

Note:

Outlook/Exchange with local encryption cannot handle encrypted calendar entries. This is thus a compatibility setting for exactly these systems.

If the email to be processed is in RTF format, the corresponding log entry (see Logs) will show the notification "Calendar entry could not be found, but detected RTF-formatted MIME parts".

CheckBoxInactive Always use GINA encryption if account exists and no S/MIME or OpenPGP key is known

By default, this option is inactive.

Outgoing emails are always encrypted by means of the GINA technology, provided that the SEPPmail Secure E-Mail Gateway does not have a public key – neither S/MIME nor OpenPGP – but a GINA account is available for the communication partner (recipient).

CheckBoxInactive Do not encrypt outgoing mails with the following text in subject:

By default, this option is inactive and has the keyword \[noenc\] stored.

If the specified keyword is found in the subject line of an outgoing email, any encryption is suppressed in any case. Other cryptographic actions (signing) are not affected.

CheckBoxInactive Consider internally routed mails as encrypted

By default, this option is inactive.

Emails sent from one Managed Domains to another are marked as "secure" (please also refer to Incoming e-mails Add this text to message subject after decryption).

empty

Note:

This is of particular interest on client-capable systems since the standard behaviour of communication between clients - and thus Managed Domains - is different from that of communication from and to external communication partners due to the very nature of the system. For instance, if an email from the sender of one client to another client on the same SEPPmail Secure E-Mail Gateway is marked as to be encrypted by the sender, it would not make sense to encrypt it only to immediately decrypt it again. Since each client is connected to the appliance via a secure channel (TLS), there is usually no reason why emails between clients should not be marked as secure, since the procedure is similar to Domain encryption.

empty

Note:

Before activating this option, it is absolutely necessary to ensure - possibly by additional upstream protective measures - that neither emails from the Internet nor from Managed Domains of other clients managed on the SEPPmail Secure E-Mail Gateway which have a falsified sender reach the SEPPmail Secure E-Mail Gateway (if applicable, please also refer to Mail System Managed Domains ADD/EDIT MANAGED DOMAIN Settings Allowed outgoing sending servers).

CheckBoxInactive Consider "forced TLS" as encrypted

By default, this option is inactive.

TLS encryption is recognised as a valid email encryption option for target domains which have been entered under Mail System TLS Settings with more stringent security settings than "may".

Thus, the Encryption Hierarchy of these target domains changes as follows (please refer to point 5.):

1.Verified S/MIME certificate of the recipient

2.Verified public OpenPGP key of the recipient

3.Verified S/MIME domains certificate of the recipient domain

4.Verified public OpenPGP domains key of recipient domain

5.TLS encryption higher than "may" - whereby this is also used if one of the higher-priority methods has already been applied.

If none of the previous (standard) methods are available

6.GINA with stored recipient password

7.GINA with initial password

empty

Note:

Activating this option requires that the SEPPmail Secure E-Mail Gateway becomes a point of contact to the Internet, i.e. directly addresses the target email domains.

It should also be noted that TLS is a line encryption and not content encryption.

CheckBoxInactive Prefer RSA-OAEP for

S/MIME encryption

By default, this option is inactive.

Global use of OAEP as a padding method for signing via S/MIME (see also https://en.wikipedia.org/wiki/Padding) and https://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding). OAEP is downward-compatible.

CheckBoxInactive Use default cipher for

S/MIME encryption: DropDown

By default, this option is inactive.

When enabled, the algorithm of the session key used for S/MIME encryption can be selected via this selection menu.

If this setting remains deactivated, Triple-DES is used.

empty

Note:

For OpenPGP, the maximum possible key length from the communication partner's public key is automatically determined and used.

Triple DES

Lowest security standard but highest compatibility (e.g. with Outlook 2003 and earlier, secure-email-gateway manufacturers which only support this cipher for Domain encryption or hardware used by the recipient (e.g. card reader)).

AES-128

Partially still required (for example EDIFACT)

AES-192

Partially still required (for example EDIFACT)

AES-256

Default setting.

Current security standard. Should be supported by all common email clients in their current version.

OpenPGP method for recipient encryption DropDown

Specifies the method for OpenPGP encryption based on domain keys (see also OpenPGP Public Keys Local OpenPGP Keys.

empty

Note:

For the decryption, i.e. for incoming emails, the SEPPmail Secure E-Mail Gateway generally supports both OpenPGP encryption versions (inline and MIME).

Inline PGP

With inline PGP, each attachment of an email - whereby the email body is also an attachment - is encrypted separately.

Advantage:

Inline PGP is supported by most open source products and thus increases the compatibility among the communication partners.

Disadvantage:

Formatting problems, e.g. the content of inline tables are displayed, but not the table itself.

empty

Note:

Due to possible security problems (keyword: EFAIL), the inline procedure should no longer be used.

PGP/MIME

Default setting.

PGP/MIME encrypts the entire email (as with S/MIME).

Advantage:

No formatting problems.

Disadvantage:

Possible compatibility problems and thus illegibility of the email at the communication partner.

OpenPGP method for domain encryption DropDown

Specifies the method for OpenPGP encryption based on domain keys (see also OpenPGP Domain Keys Manual OpenPGP Domain Keys.

empty

Note:

For the decryption, i.e. for incoming emails, the SEPPmail Secure E-Mail Gateway generally supports both OpenPGP encryption versions (inline and MIME).

Inline PGP

see OpenPGP method for recipient encryption, Inline PGP

PGP/MIME

see OpenPGP method for recipient encryption, PGP/MIME

Signing

empty

Note:

With S/MIME-signed emails, two expressions are possible as "Content-Type" of the header, namely

a."application/x-pkcs7-signature"
This expression was widely used before the standard was established and is therefore still common (see also RFC 2311).

b."application/pkcs7-signature"
This expression corresponds to RFC5751 and is also common.

The SEPPmail Secure E-Mail Gateway processes both expressions equally in incoming emails. For outgoing emails, version a. is used.

In the event of receiving third-party systems, it is to be ensured that these also process both versions equally, to also prevent incompatibilities from the other side.

empty

Note:

With the S/MIME signature, a checksum is formed via the email body as well as the MIME header. This means that if changes are made to these parts of the email, the target system will consider the signature invalid.

On the other hand, the email headers, such as from, sender, reply-to, to, cc, subject, as well any X headers are excluded from the checksum.

Incoming e-mails

empty

Note:

The certificates contained in the S/MIME signatures are collected and provided under X.509 Certificates for encrypting outgoing emails, provided that these have been

a)classified as valid.
This means they

▪originate from a CA that has been classified as trustworthy (see X.509 Root Certificates)

▪have not yet passed the expiration date

▪have not been declared invalid (see System OCSP / CRL check settings)

▪do not use an invalid signature algorithm (see X.509 Certificates Advanced Settings Policies Refuse import of certificates with a signature algorithm using sha1 or lower)

b)have the X.509 certificate management "Key Usage" with the value "Key encipherment:" .

empty

Note:

The S/MIME signature of an incoming email is checked on the basis of the header. This corresponds to the behaviour of "normal" email clients, as the envelope of an email is no longer available with these.

CheckBoxActive Add this text to message subject if

S/MIME signature check succeeds:

By default, this option is inactive and has the keyword \[signed\sOK\] stored.

Incoming S/MIME signed emails whose signatures have been checked by the SEPPmail Secure E-Mail Gateway and found to be OK, will be marked with the indicated keyword in the subject line.

empty

Note:

To ensure that an S/MIME email signature is found to be "valid",

a)this email must not have been altered on the way from the sender to the recipient and the check by the SEPPmail Secure E-Mail Gateway.

b)the signature certificate of the sender must be valid,

c)the email address of the FROM or SENDER header must match the applicant (E=) or the Alternative Applicant (RFC822-Name=) of the certificate for the verification of the sender.

empty

Note:

The SEPPmail Secure E-Mail Gateway recognises both plain text and opaque signatures and is able to verify these.

However, since email clients frequently have issues recognising opaque signatures, it is recommended removing the signatures after a successful test if emails signed according to this procedure are received frequently (see "Remove signature if S/MIME signature check succeeds").

CheckBoxInactive Remove signature if

S/MIME signature check succeeds

By default, this option is inactive.

Removes the S/MIME email signature after a successful check.

empty

Note:

If the communication partner uses RSA-PSS for signatures (please also refer to the option Prefer RSA-PSS for S/MIME signatures for Outgoing e-mails), a downstream email client will display a destroyed signature if it cannot handle it.
To avoid this, we recommend that truncating the signature after successful verification.

empty

Note:

The removal of the email signature can be an advantage when using mobile devices (e.g. via Microsoft ActiveSync) as email clients, since these often cannot handle these signatures.

Furthermore, the removal of the test results will prevent any possible differences between the SEPPmail Secure E-Mail Gateway and the email client which could be caused by different trust statuses of the issuing CAs (compare for example Windows "Master Certification Authorities" versus X.509 Root Certificates).

CheckBoxActive Add this text to message subject if S/MIME signature fails:

By default, this option is active and has the keyword \[signed\sINVALID\] stored.

Incoming S/MIME signed emails whose signatures have been checked by the SEPPmail Secure E-Mail Gateway and found to be invalid will be marked with the indicated keyword in the subject line.

In addition, under Logs Mail log a corresponding OpenSSL error is issued.

CheckBoxInactive Remove signature if S/MIME signature check fails

By default, this option is inactive.

Removes the S/MIME email signature after a failed verification.

empty

Note:

If this option is active, no further verification of the signature on the email client, i.e. also by the user, is possible. This means that the user cannot independently determine why a signature has been classified as invalid.

CheckBoxInactive Add this text to message subject if OpenPGP signature check succeeds:

By default, this option is inactive and has the keyword \[signed\sok\] stored.

Incoming OpenPGP MIME-signed emails whose signatures have been checked by the SEPPmail Secure E-Mail Gateway and found to be valid will be marked with the indicated keyword in the subject line.

empty

Note:

Due to the lack of a hierarchical structure in OpenPGP, the authenticity of the sender cannot be reliably verified. Thus, the OpenPGP signature is suitable exclusively for ensuring the integrity of an email and does not have any legal significance.

Additionally, for successfully verifying an OpenPGP signature, the public key of the sender must be known on the SEPPmail Secure E-Mail Gateway (see OpenPGP Public Keys).

CheckBoxInactive Add this text to message subject if OpenPGP signature fails:

By default, this option is inactive and has the keyword \[signed\sINVALID\ stored.

Incoming OpenPGP-signed emails whose signatures have been checked by the SEPPmail Secure E-Mail Gateway and found to be invalid will be marked with the indicated keyword in the subject line.

CheckBoxInactive Support triple wrapping

(new in 12.1)

By default, this option is inactive.

Activates the "Triple Wrapping" support (see RFC2634).

empty

Note:

This technology is used, for example, by default for S/MIME handled emails from the Google platforms. In order to read S/MIME-handled emails from senders with Google email addresses, this option must be active.

empty

Note:

For "triple wrapped" emails (optionally S/MIME-signed - S/MIME-encrypted - S/MIME-signed), the outer signature is always removed after verification.

If the verification result of the outer signature was negative, the email is generally marked as having an "invalid signature" in the subject line.

If the encrypted email contains a signature again, the email is considered to be "validly signed" only if both the outer and the inner signature are valid.

Outgoing e-mails

empty

Note:

If the certificate chain does not already exist in the certificates used for signing, these are supplemented during the signing by the appliance. This requires that the appliance knows the entire proprietary certificate chain - including the intermediate certificates - and that it is therefore classified as trustworthy under X.509 Root Certificates.

empty

Note:

Usually, to obtain the private signature key, the sender from the FROM header of the email is used (please also refer to authenticated()).

This also ensures that the substitute rules "Send on behalf of" in Microsoft Outlook also work with other email clients at the recipient without the need for an intervention via Custom commands (please also refer to Signature: Key Used With The Microsoft Delegation Rule).

If the sender of the FROM header is not internal - i.e. cannot be assigned to a Managed domain - the system checks for the presence of the SENDER header. If the SENDER header is present and the sender contained in it is internal, it is used to obtain the signature key.

This avoids problems when forwarding calendar invitations.

empty

Note:

The key/certificate of the sender with the longest validity period is used for signing.

In general, however, certificates issued via MPKI are preferred for signing ("Bonus" of 10 years). This prevents "transfer users", who initially used certificates from a self-signed certification authority (which issues certificates with a term of ten years by default) from continuing to sign with these certificates instead of trusted certificates obtained via MPKI (which are usually issued with a term of only one year).

empty

Note:

The SEPPmail Secure E-Mail Gateway signs emails with plain text signatures exclusively. By doing so, in contrast to the opaque signature, it is guaranteed that signed emails can also be read using email clients which are not compatible with S/MIME (often mobile devices).

CheckBoxActive S/MIME sign outgoing mails with the following text in subject:

By default, this option is active and has the keyword \[sign\] stored.

If the specified keyword is found in the subject line of an outgoing email, the email is signed using S/MIME.

empty

Note:

The keyword(s) used here must differ from those used for encryption (see Encryption/Decryption Outgoing e-mails Always encrypt mails with the following text in subject:).

CheckBoxInactive Sign all outgoing mails if

S/MIME certificate available

By default, this option is active.

Signs all outgoing emails (excluding calendar entries and/or RTF-formatted messages!) of SEPPmail Secure E-Mail Gateway users (Users) with a valid S/MIME certificate.

empty

Note:

Since the sender's certificate is sent with the S/MIME signature, it is made available to as many communication partners as possible by activating this option. This in turn enables them to communicate with the sender in an S/MIME-encrypted manner.

Additionally, by doing so, the integrity and authenticity of each email is automatically confirmed.

CheckBoxInactive OpenPGP sign messages when encrypting with OpenPGP and sender has a secret key

By default, this option is inactive.

Emails that use OpenPGP due to the Encryption Hierarchy are automatically signed with OpenPGP if the sender has a valid OpenPGP key pair on the appliance.

empty

Note:

Furthermore, for a successful verification of an OpenPGP signature, the recipient must know the sender's public key (see Users).

CheckBoxActive Do not S/MIME sign outgoing mails with the following text in subject:

By default, this option is active and has the keyword \[nosign\] stored.

If the specified keyword is found in the subject line of an outgoing email, automatic S/MIME signing (see "Sign all outgoing mails if S/MIME certificate available") is suppressed in any case. Other cryptographic actions (encryption) are not affected.

empty

Note:

Suppressing the email signature can be advantageous for the recipient when using mobile devices, since mobile devices often cannot handle these signatures.

CheckBoxInactive Use opaque signature

By default, this option is inactive.

Generally, email signatures are attached in plain text. Thus, a signed email can be read without checking the signature and thus with any desired email client.

With the opaque signature, the email content and the signature are stored together in a MIME part. Thus, emails with an opaque signature can be read with S/MIME-enabled email clients exclusively.

CheckBoxInactive Use triple wrapping

(new in 12.1)

By default, this option is inactive.

Activates "Triple Wrapping" (see RFC2634) when sending emails.

empty

Note:

For S/MIME-handled emails, this technology is required on Google platforms, for example. If "Triple Wrapping" was not used, S/MIME-handled emails may be rejected with, for example, the following error

"554 5.7.5 To prevent known S/MIME vulnerabilities, Gmail does not accept S/MIME encrypted messages without an accompanying valid S/MIME signature."

or may not be readable in the recipient's web mailer.

If the system of the communication partner does not support "Triple Wrapping", this setting can lead to problems under certain circumstances.

In individual cases, setting up an Encryption Policy may be helpful.

CheckBoxInactive Use default digest for S/MIME signing: DropDown

By default, this option is inactive.

When enabled, the hash algorithm to be used for signing can be selected via this selection menu.

If this setting remains deactivated, SHA-256 will be used.

SHA-1

Lowest level of security but highest level of compatibility. Should no longer be used as this procedure is not considered to be secure.

SHA-256

Default setting (recommended).

Current security standard. Usually supported by the current email client products in the context of signature verification.

SHA-512

Highest level of security However, this can lead to compatibility problems on the receiver side.

CheckBoxInactive Prefer RSA-PSS for

S/MIME signatures

By default, this option is inactive.

Global use of PSS as a padding method for Sign via S/MIME (see also https://en.wikipedia.org/wiki/Padding and https://en.wikipedia.org/wiki/Probabilistic_signature_scheme).

empty

Note:

PSS for the signature of a certificate requires a corresponding certificate from the issuer. However, this is not relevant for signing an email using PSS.

If PSS is not supported by the recipient - this is currently the case with all email clients (!) - the signature is declared invalid.

We therefore do not recommend using PSS broadly for signing.

Large files

(only functioning with the corresponding Large File Transfer (LFT) licence (see Home Licenses Large File Transfer (LFT) licenses), as well as via the GINA Domains activated Large File Transfer.

CheckBoxActive Always use large file processing for mails with the following text in subject:

By default, this option is active and has the keyword \[lfm\] stored.

If the specified keyword is found in the subject line of an outgoing email, it is sent – regardless of its size – by means of the Large File Transfer (LFT) technology.

This implies a valid Large File Transfer (LFT) licence

CheckBoxInactive Do not use large file processing for mails with the following text in subject:

By default, this option is inactive and has the keyword \[nolfm\] stored.

If the specified keyword is found in the subject line of an outgoing email, the use of the LFT technology is suppressed even if the set size threshold (see CHANGE GINA SETTINGS FOR Large File Transfer Outgoing policy Size (in KB) above which messages are treated as large files (set to 0 to treat all messages as large files)) is exceeded.

Global Quota

(new in 14.0.0)

In this section, the global LFT quota is defined.

These global settings can be overwritten by local settings per customer, managed domain, mail processing group and user.

Global LFT quota in MB

Defines the global quota. LFT will not exceed this value.

Global LFT quota warn levels

The default is "80,90,95". If the global quota exceeds one of these values, a notification email is sent.

CheckBoxActive Enforce global LFT quota

If activated, the global quota is strictly adhered to. If not, then only a warning is issued if the global quota is overwritten.

User LFT quota in MB (must not be bigger than global quota of 2000)

Defines the quota per user.

CheckBoxActive Users are allowed to use LFT

If activated, users are allowed to use LFT.

Protection Pack

(only functioning with the corresponding Protection Pack (PP) licence (see Home Licenses Protection Pack (AntiSpam / AntiVirus)), as well as under Mail System Antispam according to the activated functions.

CheckBoxInactive Check mails for viruses and send infected mails to (leave empty to reject infected mails):

By default, this option is inactive.

Activates the virus scan function. Infected emails are redirected to the optional email address to be entered (quarantine). If the input field for the email address remains empty, infected emails are rejected (bounced).

empty

Note:

If a mailbox is specified at this point, it should be noted that infected emails are sent to this address unencrypted.

Accordingly, when an address is specified from a Managed domain

Note: Infected emails are sent unencrypted to the quarantine.

or if an external email address is specified

Note: In case of an infection, you are sending an unencrypted email to an unmanaged domain!

empty

Note:

Generally, infected emails should be rejected and not be diverted to an email address.

If the email is rejected, it is still the responsibility of the sender.

However, if it is diverted, it enters the area of responsibility of the recipient. This can be a problem with time-critical emails remaining in quarantine.

empty

Note:

If the option Use ClamAV antivirus Engine (Note: remember to activate in ruleset) in Mail System Antispam is deactivated, the emails will be forwarded as "virus-free".

Files exceeding 1 GB are not scanned to avoid time-outs. A corresponding log entry is generated.

Exclude the following signatures from test (regular expression, e.g. "(Eicar-Test-Signature)|(Heuristics\.Encrypted\.PDF)"):

By default, this option is inactive.

If ClamAV generates "false positive" messages after a signature update, exceptions to the virus scan can be defined here. This can be

•heuristic partial check (see www.clamav.net, if applicable)

•individual virus names as can be seen in the log (as regular expression, i.e. special characters are to be marked as such (see Regular Expressions).

By default, the scan engine uses the ClamAV signatures as well as other signatures from Sanesecurity (http://sanesecurity.com(see Mail System AntiSpam Enable unofficial signatures for ClamAV).

Send notification to this e-mail address if a virus was found:

By default, this option is inactive.

Sends notifications about any viruses found to the specified email address.

CheckBoxInactive Block windows executable files in mails

By default, this option is inactive.

Emails containing Windows executable file formats will be rejected.

empty

Note:

In a narrower sense, "executables" are binary files that can be executive natively. Script file formats that require an appropriate interpreter (such as Java Script) to run on the operating system are not affected by this option (see next option!).

CheckBoxActive Search inside unencrypted zip archives

By default, this option is active.

If this option is activated, ZIP archives are also searched for executable Windows file formats.

empty

Note:

By searching within ZIP archives, the check can take a very long time and thus lead to time outs under certain circumstances.

CheckBoxInactive Block (most) script files in mails (e.g. .js files)

By default, this option is inactive.

Emails that contain common executable script file formats will be rejected.

CheckBoxActive Search inside unencrypted zip archives

By default, this option is active.

If this option is activated, ZIP archives are also searched for executable script file formats.

empty

Note:

By searching within ZIP archives, the check can take a very long time and thus lead to time outs under certain circumstances.

empty

Note:

The following SPAM checks are generally omitted if the sending IP address is listed under Mail System Manual blocklisting / welcomelisting.

CheckBoxInactive Check incoming mails for spam and add the following text to the subject to identify spam:

By default, this option is inactive and has the keyword [SPAM] stored.

Emails classified as SPAM are provided with the specified text in the subject line and forwarded to the recipient. The basis of the classification is the specified Tag level: (see next option).

empty

Note:

if the option Use AntiSpam Engine (Note: remember to activate in ruleset) in Mail System Antispam is deactivated, no spam detection takes place.

Emails exceeding 5 MB will not be checked to avoid time-outs. A corresponding log entry is generated.

Tag level: DropDown

Selection of the SPAM detection threshold. The lower this value (0.5 to 19.5) is set, the stricter the SPAM detection criteria.

By default, the value "2" is set.

Low values increase the risk of false positives, so that legitimate emails may also be detected and marked as SPAM.

CheckBoxInactive Check incoming mails for spam and redirect spam to (leave empty to reject spam):

By default, this option is inactive.

Emails classified as SPAM are forwarded to the optional email address to be entered (quarantine). If the input field for the email address remains empty, the classified emails are rejected (bounced). The basis of the SPAM detection is the specified Spam level (see next option).

Infected emails are sent to the optional email address to be entered (quarantine). If the input field for the email address remains empty, infected emails are rejected (bounced).

empty

Note:

Generally, infected emails should be rejected and not be diverted to an email address.

If the email is rejected, it is still the responsibility of the sender.

However, if it is diverted, it enters the area of responsibility of the recipient. This can be a problem with time-critical emails remaining in quarantine.

empty

Note:

if the option Use AntiSpam Engine (Note: remember to activate in ruleset) in Mail System Antispam is deactivated, no spam detection takes place.

Emails exceeding 5 MB will not be checked to avoid time-outs. A corresponding log entry is generated.

Spam level: DropDown

Selection of the SPAM detection threshold. The lower this value (0.5 to 19.5) is set, the stricter the SPAM detection criteria.

By default, the value "4" is set.

Low values increase the risk of false positives, so that legitimate emails may also be classified as SPAM and redirected or bounced.

CheckBoxInactive Reject incoming mails with spoofed sender domain preventing processing of internal mails

By default, this option is inactive.

If the sender in the envelope or FROM header (or SENDER header, if applicable) of an incoming email is from a Managed domain, the email will be rejected.

empty

Note:

With this option, all internal email traffic, i.e. from Managed Domains to Managed Domains, is stopped. This is usually not a problem since internal emails are directly sent by the email server and do not even reach the SEPPmail Secure E-Mail Gateway.

However, in MSP environments in particular, emails are sent from the Managed Domains of one customer to the Managed Domains of other customers so that this option should not be activated here (see also Clients: Securing the SEPPmail Secure E-Mail Gateway.

CheckBoxInactive Reject mails if from header does not contain a valid email address

By default, this option is inactive.

If the FROM header (and SENDER header, if applicable) of an email contains no valid email address, the email will be rejected.

empty

Note:

This can have the effect that system emails are also rejected since these are frequently sent without a sender.

Header tagging

By means of "Header Tagging", the setting of an extended, so-called x-header and an associated value for different situations (see following options) is made possible by the SEPPmail Secure E-Mail Gateway. This extended information can be evaluated by downstream components.

An example for such additional downstream email processing component could be a data loss prevention (DLP) system.

empty

(new in 11.1)

Note:

The X headers

•X-SM-incoming

•X-SM-outgoing

•X-SM-internal

•X-SM-encrypted

•X-SM-decrypted

are always set with the value "yes" by default if the corresponding situation occurs, irrespective of the optional settings below.

CheckBoxInactive Set header Input to value Input for all incoming and internal mails

By default, this option is inactive.

Sets the specified X header with the assigned value for all incoming and internal emails (please also refer to Set header ñ to value ñ for all internal mails).

CheckBoxInactive Set header Input to value Input for all outgoing mails

By default, this option is inactive.

Sets the specified X header with the assigned value for all outgoing emails.

CheckBoxInactive Set header Input to value Input for all internal mails

By default, this option is inactive.

Sets the specified X header with the assigned value for all internal emails, i.e. from one Managed domain to a Managed domain.

CheckBoxInactive Set header Input to value Input For all mails that have been encrypted

By default, this option is inactive.

Sets the specified X header with the assigned value for all emails encrypted by the SEPPmail Secure E-Mail Gateway.

CheckBoxInactive Set header Input to value Input For all mails that have been decrypted

By default, this option is inactive.

Sets the specified X header with the assigned value for all emails decrypted by the SEPPmail Secure E-Mail Gateway.

Archiving

CheckBoxInactive Send a copy of ALL mails to the following address:

By default, this option is inactive.

Sends a 1:1 copy of all emails transported via the SEPPmail Secure E-Mail Gateway before encryption and/or after decryption - to the specified email address.

Custom commands

Using the command set defined in the Ruleset instructions, specific requirements can be added at the appropriate point in the ruleset via Custom commands.

empty

Note:

A syntax check is performed when saving custom commands. Thus, no invalid ruleset is activated.

CheckBoxInactive Custom commands for incoming emails BEFORE decryption:

By default, this option is inactive.

Inserts the code in the input field at the position in the ruleset for incoming emails BEFORE decryption.

CheckBoxInactive Custom commands for incoming emails AFTER decryption

By default, this option is inactive.

Inserts the code in the input field at the position in the ruleset for incoming emails AFTER decryption.

CheckBoxInactive Custom commands for outgoing emails BEFORE encryption:

By default, this option is inactive.

Inserts the code in the input field at the position in the ruleset for outgoing emails BEFORE the encryption.

CheckBoxInactive Custom commands for e-mails from GINA:

By default, this option is inactive.

Inserts the code in the input field at the position in the ruleset for incoming GINA emails.

CheckBoxInactive Custom commands for user creation:

By default, this option is inactive.

Replaces the code for the default procedure for creating new users which has been selected under User creation.

The code, provided that the option is active and upon selection of

•Do not create accounts (also disables custom commands for user creation) never

•Create accounts for new users if user tries to sign/encrypt will only be executed with the encryption/signature attempt

•Create accounts for all users always

empty

Note:

Since this option replaces the selected standard procedure for creating new users, a user would never be created if the option was activated without the code entered!

For this reason, the input field of this option is pre-occupied with the standard code for creating new users.

Provided that the code entered here has not been adapted (i.e. corresponds to the default), it would also be updated with a firmware update, if required.

To receive the default code again after a manual adaptation, if applicable, the content of the input field is to be deleted and the ruleset is to be generated again by means Save.

CheckBoxInactive Custom Macros And Commands For All Emails BEFORE Processing

By default, this option is inactive.

Here, Macros - i.e. code blocks which are defined once and can then be used as often as desired in the Custom commands - can be created.

These are placed at the top of the ruleset (see SMTP Ruleset Display Ruleset). Thus, a code may also be placed before the actual "Mail Processing".

Key server

Key Server enables the additional retrieval of public keys from communication partners. Thus, if applicable, an encryption is also possible if no key material of the recipient is available on the SEPPmail Secure E-Mail Gateway but is present on the entered key server. The key server query takes place before the query of the proprietary key memory (see X.509 Certificates and/or OpenPGP Public Keys).

The query is always executed by the email processing system. If this is a frontend server, it transfers the key material obtained in this way to the backend system for storage.

After saving a key server entry, another input field is displayed.

empty

Note:

Public key servers and key collectors often contain "dead" key material. This means that the recipients often no longer have the private key for the public keys provided via the key server. They are thus unable to read the encrypted emails.

For this reason, it is strongly discouraged from querying such servers.

empty

Note:

For key servers that are entered here, it is assumed that they are trusted.

Certificates that are obtained via the Key Server are therefore also used for encryption if the issuing root certification authority is unknown (see also X.509 Root Certificates).

Type DropDown

Selection of the key material to be queried.

The search filters for a key server query are standardised for the default technologies S/MIME and OpenPGP.

However, if another search filter is required, there is an option of creating a user-defined query via Custom commands, by means of the commands ldap_getpgpkeys() and/or ldap_getcerts().

S/MIME

Default setting.

Selection for S/MIME key search

(default search filter (mail=<email address of the recipient>))

empty

Note:

If a newer certificate than the one found in the certificate memory (X.509 Certificates) is found on the key server, this newer certificate is saved in the certificate memory and thus used for encryption.

empty

Note:

According to RFC 4523 the certificates must be stored on the key server in the attribute "userCertificate;binary" in "binary" format. If the certificates there are in a different format, the detail log (see also Logs No.) will show the notification

Error getting information for certificate: new_from_string error: Crypt::OpenSSL::X509: failed to read X509 certificate. at /usr/local/sepp/lib/Crypto/SMIME/X509.pm line 155.

OpenPGP

Selection for OpenPGP key search.

(default search filter (pgpUserID=<email address of the recipient>)

empty

Note:

If, when querying a public OpenPGP key, a key is found whose key ID is identical to an existing entry in the key memory (OpenPGP Public Keys), this key is overwritten on the appliance by the result of the LDAP query.

Recipient mask (regexp):

Regular expression which determines the target email domain for the query.

For instance, if the query shall only apply to one email domain, the expression could be as follows:

@my-communicationspartner.tld\.com

or, if valid for several e-mail domains, also

@my-communicationspartner.tld\.com|@my-other-communicationpartner.tld\.com

URI

Indicates the path to the key server.

Several values can be entered separated by commas. In this case, the next server is automatically accessed if the previous one cannot be reached.

Examples:

ldap://my-communicationspartner.tld\.com

ldaps://my-communicationspartner.tld\.com

ldaps://my-communicationspartner.tld\.com:1636

ldaps://server1.my-communicationspartner.tld,ldaps://server2.my-communicationspartner.tld\

The access data must be provided by the operator of the key server.

Bind DN

(optional)

User entitled to make queries, e.g.

cn=mycompany,ou=keys,o=my-communicationspartner.tld,c=com

Bind PW

(optional)

Password belonging to the user

empty

Note:

Semicolons ";" and backslashes "\" must each be marked with a backslash as special character, i.e. "\;" and/or "\\".

For instance, the password

p4ss\w0rd;

would have to be entered as follows:

p4ss\\w0rd\;

Base DN

LDAP search path in which the keys to be searched are stored.

CheckBoxInactive Ignore failure

By default, this option is inactive.

Prevents the rejection (bounce) of the email if the LDAP server cannot be reached.

CheckBoxInactive Verify CA is trusted

(new in 14.0.1)

By default, this option is inactive.

If checked, any S/MIME certificate that is downloaded from the key server will be checked against the root CAs, to see if the root is complete, trusted and present.

Advanced options

CheckBoxInactive Completely disable GINA technology

By default, this option is inactive.

Completely deactivates the GINA technology.

As a result, emails marked as "to be encrypted" will be rejected if no other encryption methods (S/MIME, OpenPGP, domain) are available.

empty

Note:

If the GINA technology is switched off via this option, it is to be ensured that all options from "Encryption/Decryption"that use this technology are deactivated. Similarly, this technology may not be used via Custom commands.

CheckBoxInactive Completely disable user-based S/MIME and OpenPGP

By default, this option is inactive.

Disables both the user-related S/MIME as well as the OpenPGP technology.

This option is to be used if only domain and/or GINA encryption is to be applied.

empty

Note:

If this option is selected, it is to be ensured that all options from "Encryption/Decryption" that use this technology are deactivated. Similarly, this technology may not be used via Custom commands.

CheckBoxInactive Use remote GINA server, reachable under the following e-mail address:

By default, this option is inactive.

If, for revision-related reasons, the GINA part must be in a different demilitarised zone (DMZ) than the SMTP processing part, a corresponding separation of the solution by means of this option is possible. The individual functional parts can even be distributed to different locations.

All GINA emails to be encrypted will then be forwarded via the pseudo email address entered here (for example GINA@GINA pseudodomain.local) to the GINA satellite in an S/MIME encrypted manner, via SMTP.

CheckBoxInactive This is a remote GINA server

By default, this option is inactive.

Defines the counterpart to the option Use remote GINA server, reachable under the following e-mail address:, i.e. the GINA satellite.

The satellite appliance must have the pseudo email domain (in the example above: "ginapseudodomain.local") as additional Managed domain (see Mail System Managed Domains). Similarly, the Managed Domains of the basis system must be registered. The GINA configuration and its allocation to the Managed Domains is implemented on the satellite system (see GINA Domains Domains).

Relay for domain:

Here, the Managed Domains of the basic system must be entered as regular expressions (see Mail System Managed Domains).

The domains are separated by a pipe character "|", i.e. domain1\.tld|domain2\.tld|domainn\.tld

empty

Note:

Theoretically, a GINA satellite can be configured in this way for several appliances hosting different Managed Domains.

Relay email address:

Here, the same pseudo email address is to be entered as on the "basic"system under Use remote GINA server, reachable under the following e-mail address:.

Relay domain key fingerprint:

Here, the SHA1 fingerprints of the domain certificates of the "Relay for domain:" indicated under Managed Domains are to be entered as regular expression, each separated by a pipe character "|", i.e. fingerprint1|fingerprint2|fingerprintn

(see ADD/EDIT MANAGED DOMAIN S/MIME domain encryption).

CheckBoxInactive Use Incamail instead of local GINA interface

By default, this option is inactive.

Activates the Swiss Incamail service instead of the GINA technology.

Use custom delivery method:

By default, this option is empty.

If an entry is present, the option is displayed in red.

Determines the type of the email flow.

For example, the option available before version 11.1.11 Re-inject mails to sending mailserver can be called up by entering "loop" (see also Config: Re-Inject Mails To Sending Mail Server), or the option Run in queueless mode can be called up by entering "queueless" (see also Config: Queueless Mode).

Furthermore, this option can be used to map a "Custom commands for outgoing e-mails AFTER encryption" (see also Config: Custom commands for outgoing e-mails AFTER encryption).

The changes made are saved via the Save and create ruleset button. The ruleset is generated with the settings made.

Please enable JavaScript to view this site.

Keyboard Navigation