Striking a balance between cost and benefit for e-mail encryption (Part 3)

In Parts 1 and 2 of this series of articles, we provided information and advice to assist you in the evaluation of e-mail encryption solutions.

The aim of this third and final article is to explain why the activation of TLS (Transport Layer Security) on in-house e-mail systems does not definitively resolve the issue of e-mail encryption. In addition, we describe a possible solution for the majority of companies.

The activation of TLS is already possible for all conventional e-mail systems, but is not standard practice for several reasons. Since both the sender and recipient systems must have this option activated to encrypt a connection with TLS, an IT administrator cannot simply activate TLS on the own system to get the issue done. Of course, an agreement could be reached with a limited number of communication partners for aligning the systems aligned accordingly. However, there would still be no certainty at any time that TLS was actually being used for e-mail transmission. In addition, it is understandably not practical for the IT administrator to check all e-mail correspondence and subsequently coordinate the TLS connection with each new communication partner. Cost and benefit would not strike a balance here.

Therefore, a solution that checks in advance for the presence of TLS in the communication partner's e-mail system would be welcome. Even if TLS is inactive, the sender would still want to be sure that the message is sent in encrypted form, as in such cases e-mail systems normally default to the unencrypted transmission path and all efforts to encrypt the communication are then in vain.
Furthermore, it would be practical if both sender and recipient could actually see that the message was transmitted in encrypted form.

The RMail solution from Frama combines these possibilities. Messages sent via TLS are always marked as such. Both sender and recipient can therefore see that the message was sent encrypted. If TLS is not available for the transmission, RMail instead encrypts the message via Secure PDF and transmits it to the recipient. The password can then be provided to the recipient in several different ways.
As the sender, you can therefore always be sure that each e-mail is actually sent in encrypted form. You also receive proof of delivery and can therefore be certain that your e-mail has reached the recipient. This also covers the guarantee of encrypted transmissions as required by law, including the obligation to present proof (e.g. the EU’s General Data Protection Regulation (GDPR)).

RMail is thus a solution that guarantees — and provides proof of — encrypted e-mail transmission. Thanks to its simple integration and ease of use, it allows the balance between cost and benefit for e-mail encryption to finally be achieved.