Initial situation:

TLS is indicated as a possible available encryption version However, practice has shown that TLS is always only used as an additional security option in connection with another procedure (S/MIME, OpenPGP, GINA).

 

Question:

Can TLS also be configured as an additional, standalone encryption version?

 

Answer:

Contrary to the other procedures mentioned, TLS is not a form of content encryption but only a transport (connection) encryption. Thus, TLS can only be guaranteed until the next email system. However, since emails are mostly routed via several email systems, TLS generally cannot guarantee continuous encryption.

For this reason, by default, TLS is not listed in the Encryption Hierarchy.

However, under certain circumstances, TLS can be added as an additional encryption technology to the Encryption Hierarchy:

•The SEPPmail Secure E-Mail Gateway forms the threshold to the Internet
This means that emails are directly addressed to the recipient.
 

•The recipient has signalised that their system receiving emails from the internet is located in their own network.
 

•TLS encryption has been set up on the SEPPmail Secure E-Mail Gateway under Mail System TLS settings with a level higher than "may" (see ADD TLS DOMAIN TLS settings) for this communication partner.

 

The actual integration into the Encryption Hierarchy is finally realised by activating the option "Consider "forced TLS" as encrypted" under Mail Processing Ruleset generator Encryption Outgoing e-mails.

From now on, TLS would be used as a reliable encryption procedure to the correspondingly set up target domain even before GINA.

 

TLS will still be used as an additional encryption method at all times.