Home / server / Questions / 1045480
Accepted
71GA
Asked: 2020-12-09 11:53:54 +0800 CST

E-mail transmission example

  • 772

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
email smtp imap pop3

1 Answers

  1. Best Answer

    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.

    • 5