3

Does port 25(smtp) used by MTAs work under plain text/non-encrytion ?

I couldn't find any resources that state smtp with 25 by default is plain text.

From Opportunistic_TLS

(See the code section S: <waits for connection on TCP port 25>...)

, it seems that port 25(smtp) supports STARTTLS, so does this indicate that

  1. port 25 with smtp used by MTAs is non-encryted by default ?
  2. and it can (only) be secured in a STARTTLS way ?
5

Months later, I read more materials and some RFC and I don't argee some of @Overmind 's answer.

Opportunistic_TLS or STARTTLS, I think they are refering to one thing. That is, if server supports TLS connection, then a client would perfer to connection with TLS, if not, a client is ok with plain text connection.

Port 25 used by MTAs may support TLS or may not. It's completely depending on the mail server. (If a server supports TLS, you can see the STARTTLS option after telnet and EHLO.)

  • If a server MTA a supports TLS, and a client MTA b is asking for TLS connection, then TLS connection will be established.

  • If a server MTA a doesn't support TLS, and a client MTA b can be configured to continue to talk in plain text or abort delivering. (For example, MTA software Postfix seems to support these kind of settings, and it can be set to ask for TLS connection only for some user specified domains.)


The introduction of port 587 was originally aimed to replace port 25 in MUA (end user mail client e.g. ThunderBird) to MTA mail submission. And it's designed in a Opportunistic_TLS way. If server supports TLS, then talk in TLS. If not, then I am ok with plain text.

So as you can see Opportunistic_TLS or STARTTLS is just a mechanism. This pattern can be used in MTA to MTA, MUA to MTA or any other communications. It has nothing to do with the protocols.

And I don't think the default submission port should be 587 as @Overmind said. mail submisson should be enforce TLS instead of Opportunistic_TLS. enforce TLS is: if server doesn't support TLS connection, then client won't talk to the server. And port 465 is employed for enforce TLS requirement.

So in your mail client, you should always use 465 for mail submission.

Check this good article for more https://www.fastmail.com/help/technical/ssltlsstarttls.html

1
  • 1
    That is the valid answer indeed. About port 587 vs 465, most resources available are outdated and will wrongly advise not using Enforced/Implicit TLS on 465 but rather Opportunistic/Explicit (START)TLS on 587. That is not the best practice as of 2020 (long story made short: STARTTLS is vulnerable to Man In The Middle attacks if not properly configured on both client and server sides, whereas Implicit TLS is secure by design). Check RFC 8314 (not yet validated but on its way) at tools.ietf.org/html/rfc8314 for up-to-date insights on exchanging mail in a secure way with TLS. – chikamichi Jun 9 '20 at 20:07
2

There are two scenarios for SMTP traffic:

  • Server to Server
  • Client to Server.

Server to Server e-mail communication takes place over port 25. This port continues to be used primarily for SMTP relaying. SMTP relaying is the transmittal of email from email server to email server. You have to accept SMTP traffic at port 25 to receive communications from other domains. This is unsecured, information is sent as clear text / ASCII. It is not sent over SSL.

Client to Server scenario: On the server you can configure different submission ports (open ports you will accept e-mail on). These can be anything, but clients will have to know to use them.

The most common ports are 25 and 587, but a client-server system should not use 25. If you want secure outgoing communication, use 587 with TLS. This is the default e-mail submission port. When an e-mail client or server is submitting an email to be routed by a proper e-mail server, it should always use this port. This port, coupled with TLS encryption, will ensure that email is submitted securely and following the guidelines set out by the IETF.

Do not confuse ports with communication protocols.

SMTP is a protocol – it specifies the way information is transmitted. It can transmit it securely or insecurely.

The SMTP port is actually a listening port and clients connect to this in order to use the server's functionality.

The SMTP Server, on the other hand, is something separate from the protocol itself that actually does the transmission.

So yes, what you read is correct: port 25 is considered to be an incorrect use in a client-server scenario.

2
  • I think I understand the client to server part. But seriously, server to server with port 25 in plain text, no secure option at all ? Does it mean that any routers between one MTA to another can read the email ? And other servers/computers in the same network can sniff and read the emails directly ? – Rick Jun 12 '19 at 11:05
  • 1
    Initially, a server-to-server SMTP connection is always in plain text on port 25. if both source and target server support the TLS extension then usually the plain connection gets converted into a encrypted connection with the STARTTLS command. To check if an e- mail was transmitted over an encrypted connection, read the "Received"-Headers in the resulting message after it was transmitted. If there is a ESMTPS ID (with an S), then it's secure. If there's no S, it's not. You can read about STARTTLS here: itprotoday.com/email-and-calendaring/… – Overmind Jun 12 '19 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.