E-mail transmission example

Solution 1:

This is based on a misconseption that the ports have anything to do with encryption. However, I find this a good question, as it gives a chance to correct this misunderstanding.

The ports are not to indicate encryption, but used for different purposes:

  • Port 25 is used for SMTP (RFC 5321) message relay between MTA:s.
  • Port 587 is used for message submission (RFC 6409) from MUA to MSA.
  • Both of these can be encrypted with STARTTLS (RFC 3207).
  • Additionally, there is SMTPS that wraps the SMTP (from MUA to MSA) inside TLS on port 465. This was registered in 1997 but revoked in 1998, when STARTTLS was standardised. However, this has been reversed 20 years later in 2018, as RFC 8314 now considers cleartext obsole and brings back implicit TLS for POP, IMAP and SMTP submission.

Most of the email today is encrypted in transit (between MTAs), says Google Transparency Report.

The communication between MTAs should still approve unencrypted connections for backwards compatilibity and, therefore, it is easy for a man-in-the-middle to downgrade the connection by removing the 250-STARTTLS reply indicating the support for the extension. However, if the sender supports opportunistic DANE (RFC 7672) and the receiver has a TLSA record stating that they do not need unencrypted delivery attempts (as an exception to the backwards compatibility), this kind of attacks will fail.

The following illustration (CC BY-SA 3.0 from Ale2006-from-en in Wikipedia Message submission agent) shows the different server roles, and the blue arrows can be implemented by different SMTP variations. Also notice that the same server can have multiple roles in delivering the message.

SMTP transfer model

To enhance your table:

# sender receiver protocols and ports in use
1 MUA MSA (✘) submission 587 with STARTTLS
(✔) SMTPS 465 with implicit TLS
2 MSA MTA Internal delivery (same server with two roles)
3... MTA MTA (possibly MX) (✘✘) unencrypted SMTP 25
(✘) SMTP 25 with STARTTLS
(✔) SMTP 25, STARTTLS enforced with DANE
N-1 MX MDA➔MS Internal delivery (same server with multiple roles)
N MS MUA (✘) IMAP 143 with STARTTLS
(✔) IMAPS 993 with implicit TLS

The last two steps cannot exactly be seen as sender and receiver, as the Message User Agent MUA connects to the Message Store MS and pulls the message instead of push. The final MX MTA delivers the mail to the MS with a functionality called Message Delivery Agent (MDA). The Message Submission Agent (MSA) only refers to sending mail. More detailed information on these definitions can be found on Internet Mail Architecture RFC 5598.