-3

RFC standards literally force us to accept unencrypted connections on port 25. To understand why, we have to understand how emailing works. But emailing is quite a complex topic and I created this example together with a table to try and understand everything.

Can anyone read and tell me if I am wrong in any part of the explanation? Because I am not quite sure if my understanding of the topic is correct.

EXAMPLE

When user (sender) sends email through "mail user agent" (MUA), this email is immediately transfered to the "mail submission agent" (MSA) which is or isn't on a separate machine. MSA preprocesses the email and hand it over to "mail transfer agent" (MTA) on the same machine. MTA (sender) then uses DNS and determines to which MTA (receiver) email should be sent. This portion of the transport is only done over port 25. When the MTA (reciever) gets the email, it handles it over to the MSA on the same machine and then user (receiver) can read the email using MUA.

Communication between MUA & MSA and MSA & MTA can use secure ports but connection betweem MTA & MTA can't. Table below shows which protocols are used or can be used and which ports can be used for each step of the above example. We also use ✘ and ✔ where there is a choice to indicate what a modern setup should use.

# sender receiver protocols we can use ports of respective protocols
1 MUA MSA (✘) SMTP
(✔) SMTPS		 (✘) 25
(✔) 587
2 MSA MTA (✘) SMTP
(✔) SMTPS		 (✘) 25
(✔) 587
3 MTA MTA (✔) SMTP (✔) 25
4 MTA MSA (✔) SMTP (✔) 25
5 MSA MUA (✘) POP3
(✘) POP3S
(✘) IMAP
(✔) IMAPS		 (✘) 110
(✘) 995
(✘) 143
(✔) 993
71GA
  • 363
  • 1
  • 3
  • 10
  • Why is 587 listed as a "secure" port but 25 is "insecure"? What are these labels supposed to mean? – Michael Hampton Dec 08 '20 at 20:05
  • @MichaelHampton With "secure" I meant "encrypted" (using TLS). Did you ask because there are only ports? MAybee there are no such thing as secure or insecure ports, but there are secure protocols and insecure protocols. – 71GA Dec 08 '20 at 20:15
  • @MichaelHampton I fixed it. Probably now it is more correct. – 71GA Dec 08 '20 at 20:54
  • 2
    Both 25 and 587 can be either encrypted or not. – Michael Hampton Dec 08 '20 at 20:58
  • I don't think so. The difference is that port `587` requires `STARTTLS` to be the first command that is issued after `EHLO`/`HELO` and therefore it somehow demands encryption. Otherwise port `587` issues a warning and will not let users continue untill they use `STARTTLS`. So in a way `587` does not support unencrypted communication. – 71GA Dec 08 '20 at 21:05
  • 2
    Port 587 does not require STARTTLS. See RFC 6409 section 7. – Michael Hampton Dec 08 '20 at 21:43
  • Thank you for helping me understand. – 71GA Dec 10 '20 at 22:52

1 Answers1

5

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.

Community
  • 1
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • Thank you very much for finding my question useful. There is a lot of information and it is hard to not get confused. Like you would know that I am in the middle of setting up DANE, DNSSEC... I think this are a very good technologies! I am planning also to explicity support only TLS 1.3 or maybe TLS 1.2 because some browsers dont yet support TLS 1.3 which is much faster. – 71GA Dec 09 '20 at 08:34