About ports and encryption in mail servers

When configuring the outgoing mail server on the mail client, you see 3 options for encryption - without encryption, SMTPS and STARTTLS, as well as 3 possible ports - 25, 465, 587. What to choose and what for - let's understand.

Video

Previous < Mail Server Operating Modes
Next> DNS Records for Mail Servers


When you send a message to someone, your mail client uses ESMTP to send this message, and then your mail server uses the same protocol if it needs to send this message to another server. And while everyone speaks and writes SMTP, it is usually about ESMTP - the same SMTP, but with a set of extensions, such as authorization and encryption. Yes, once SMTP did not even support authorization.



Now a little about SMTPS. Once the Internet was so simple that everything in it was transmitted in clear text. Then came cryptographic encryption protocols, the same SSL. And services that previously transmitted information in an open form, began to wrap traffic in SSL.



But it was not easy to do this on the same standard ports - the client and server must agree on an encryption method, and for a service on one port to work simultaneously for some with encryption, and for others without - it would require changes in the protocols. And in order not to complicate everything, they began to sculpt separate ports for encrypted connections - this is how 443 for HTTPS and 465 for SMTPS appeared. But we realized it right now - there are few dedicated ports, the number of services is growing, and if each of them will use several ports with encryption and without encryption for their purposes - trouble.



And in the end, they decided to modify the protocols a bit. In some cases, this did not work out very well, for example, for HTTP, and in the case of SMTP, it turned out to be a perfectly suitable option. For this, the STARTTLS extension was added to SMTP. In general, the STARTTLS extension is not only used for SMTP, in general it is a command to start encryption negotiations. Unlike SMTPS, which uses a dedicated port 465 and immediately encrypts the connection, STARTTLS is just an extension for SMTP, which means that the session is initiated as a regular SMTP session. Mail servers greet each other, and then offer to start encrypting and select the available cryptographic protocols.



As a result, with the advent of STARTTLS from the standards, they decided to remove SMTPS on port 465 as a separate service. They removed it from the standards, but the service remained, and is still in use. As for encryption, I’ll still make a separate topic, but for now let's talk about STARTTLS.



I said earlier that with STARTTLS, mail servers or a client / server open a connection without encryption, and then agree on encryption. They use the same SSL / TLS for encryption. But what if they cannot agree? It turns out they will communicate in unencrypted form? On the internet? Meanwhile, they agree without any encryption, thereby easily deceiving the server or client by the lack of available encryption methods. And at one time they caught one of the providers in such an attack. And then you need such encryption, you ask. Not everything is so hopeless. In fact, the administrator can disable the ability to send mail if it is not possible to agree on encryption, and mail clients are required to warn that the server does not support encryption.



And so, we figured out that there is SMTP that works on port 25, there are SMTPS that works on 465, but there is another port - 587, which is also used by the mail server.



As you noticed, email clients connect to servers via SMTP. And mail servers connect to each other via SMTP as well. I also said in the last part that there are such servers - relay hosts that forward mail. For certain reasons, mostly human, there are relay hosts on the Internet that allow unauthorized users to redirect messages from any address. And these hosts appear every time when a negligent admin raises the mail server, and this happens often. As a result, cybercriminals raise temporary servers or infect computers of users who send spam through these relay hosts without authorization.



As a result, some Internet providers block any user connections to port 25.



This port is open between servers on the Internet, but they made a separate service for users - MSA (message submission agent - sending agent), thereby separating user connections from server connections that still communicate via MTA. In general, MSA even works on port 25, but the official port for it is 587. So what prevents spammers from using this port? The fact that the MSA, as a rule, requires user authorization. This is not the only reason for the existence of MSA - since it works with email clients, it is better optimized for the work of clients - it immediately warns of any errors in messages, for example, the absence of the recipient's domain address.



And finally, let's follow the process of sending an email message. To do this, use wireshark, an email client and a gmail account. It all starts with the standard TCP handshake, after which the SMTP session is started. During the session, the mail client and server greet each other, after which the mail client offers to encrypt the session, the server agrees, after which the keys are exchanged and the TLSv1.3 session begins, after which the client logs in encrypted and sends a message that is not visible for a traffic interceptor.