Why Should One Use Email Certificates?

A normal transmission of an email runs through many points, shown here schematically and simplified:
PC → Switch → Server → Router → Internet → Router → Server → Switch → Server ⇔ Switch ⇔ PC
Sender   Switch   SMTP   Router   Internet   Router   MX   Switch   IMAP   Switch   Recipient

If the email is neither encrypted nor signed, then it can be read and also modified at each of the intermediate points. If it is at least signed, then it is possible to prove whether the email really originated from the sender and whether it has been modified.
If encrypted SMTP is used to send the email and encrypted IMAP is used to retrieve it, for example, then the email is secure against unauthorized reading from the sender to the first server (SMTP) and from the last server (IMAP) to the recipient, but can be attacked in between and the email is also available in plain text on the sender's server (Sent folder) and the recipient's server (Inbox).
If the sender's SMTP server (as at Graz University of Technology) uses ESMTP/TLS and the recipient's MX server also supports this (but you as the sender cannot check this!), then the email is also secure on the way from the sender's SMTP server to the recipient's MX server (i. e. also on the Internet) (as the recipient, you can check this in the header of an email: in the Received: lines there is then something with TLS - but this does not guarantee that this will also be the case with the next email).
If the recipient's IMAP server also supports ESMTP/TLS, then the email is secure on all links between the servers (but not on the SMTP, MX and IMAP servers themselves) - this combination of standards, which has been used at the TU for many years, has been advertised as "E-Mail made in Germany" by some providers in Germany since 2013:

  1. Secure from the sender to its SMTP server (secure SMTP),
  2. secure from the SMTP server to the MX server (ESMTP/TLS),
  3. secure from the MX server to the IMAP/Exchange server (ESMTP/TLS), and
  4. secure from the IMAP/Exchange server to the recipient (secure IMAP/EAS).

However, at the sender (Sent folder) and at the recipient (Inbox), the emails are still present at the server in plain text and partly also in the cache of the client used and also at the other affected servers (SMTP, MX), the emails could be read in plain text and also modified.

Although TU Graz supports (or requires) encryption everywhere in its subarea, the email is only really secure with end-to-end encryption (E2EE) - but how secure then of course still depends on the method used (S/MIME, PGP or a symmetric method) and as we know in the meantime, intelligence services such as the NSA may have access to the S/MIME certificates of commercial providers, so the currently most secure asymmetric method is probably the open source variant of PGP (i. e. GnuGP).

As a sender, if you do not use end-to-end encryption, you only have influence on the first route - the rest depends on the provider's settings!

In summary

Advantages:
  1. Signing allows the recipient to verify whether the email actually comes from the supposed sender (authorship) and whether the email has been modified (integrity).
  2. Encryption prevents third parties from gaining unauthorized access to the content (confidentiality).
To sign, I need a certificate myself; to encrypt, I need (in the case of asymmetric encryption) the certificate of the communication partner.

Disadvantages:

  1. If I lose my private key (computer replacement etc.), then I can no longer read (even earlier) encrypted emails sent to me!
  2. Encrypted emails can neither be checked for spam nor for malware on the server side!
  3. In case of signed or encrypted HTML emails with external images, the reloading of the images in Outlook has to be allowed first.