2

I have recently been developing a C# client which sends emails via a SMTP server. However I have been as to what the different terms ment, like: STARTTLS/TLS/SSL... I had a faint idea of what they ment out of context, but email wise i had no clue.

Upon further investigating I found that SMTP clients communicate with servers in 2 different ways (2 encrypted ways); Explicit SSL/TLS & Implicit SSL/TLS.

From what I understand Explicit SSL/TLS is how STARTTLS works, it asks the server on an unsecured connection if TLS is supported and if it is, it continues with an encrypted connection. Implicit TLS however is secure from the begining of the connection to the end, it is never unsecure.

I might be wrong about this, please correct me if I am.

The question is why is port 587 (Explicit SSL/TLS) the preferred port over port 465 (Implicit SSL/TLS).

I know that port 465 is deprecated and I can see the usefulness of port 587 that it works both encrypted and unencrypted and its up to the client to find out what the server supports.

But I rarely see security updates which is in favor of ease of use, which is why i am confused. Why did we go from fully secure to secure only some of the way?

I hope my question makes sense.

Choppa dude
  • 25
  • 1
  • 3
  • See https://en.wikipedia.org/wiki/SMTPS#History - which might show that 465 is actually not (or no longer) deprecated. – Steffen Ullrich May 28 '21 at 10:48
  • 1
    587 could be also looked at in the sense of a `client` port (SUBMISSION) where you are a client of the email provider, provide credentials and continue, the main benefit of 587 over 465 was email systems did not require trusted certificates to connect, wherein SSL's connection protocol's first step is to validate certificates. Also w/STARTTLS you still have the ability to configure force encryption and auth. I can only assume with the rise of e2e encryption, 465 regained it's place as 587 can easily be MiTM'd by your ISP/Upstream. Since you're building a client, don't forget s/mime support – Jacob Evans May 28 '21 at 11:45
  • Similarly, LDAP is 389 w/starttls or 636, generally 389 is still primary even if TLS is enforced/required – Jacob Evans May 28 '21 at 11:47
  • I have not voted to close this as a duplicate of [smtps and submission confusion](https://serverfault.com/questions/605715/postfix-smtps-and-submission-confusion) because that question also needs work and its accepted answer has not been updated past significant events in 2018. – anx May 30 '21 at 18:46
  • Wrong, now 465/tcp is preferred. https://datatracker.ietf.org/doc/html/rfc8314#section-7.3 – John Greene Mar 31 '22 at 23:24

3 Answers3

5

Why is port 587 preferred?

Any document claiming so is historic. Today, port 465 is preferred.

The reason it used to be preferred (by some, not all operators):

  • after STARTTLS was formalized, compatibility & security considerations were different
  • a suitable and already used TCP port number had been reassigned by IANA

The reason we should now all prefer implicit TLS:

  • unnecessary workarounds and compatibility layers added to otherwise robust security mechanisms are considered undesirable
  • an alternate port usage has been assigned to resolve the port conflict
  • we now have little use case left for offering optional transport security

Everyone is advised to migrate to implicit TLS. Please only send mail using secure transports. Please discourage or remove unnecessary complexity and failure modes.

anx
  • 6,875
  • 4
  • 22
  • 45
  • Example of a recent security bug in `STARTTLS` compatibility code: [CVE-2021-33515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33515) – anx Jun 25 '21 at 09:12
  • https://datatracker.ietf.org/doc/html/rfc8314#section-7.3 – John Greene Mar 31 '22 at 23:24
  • 1
    Yes; this ... https://blog.apnic.net/2021/11/18/vulnerabilities-show-why-starttls-should-be-avoided-if-possible/ – John Greene Apr 16 '22 at 13:17
1

It is currently the other way around. On the question why, RFC 8314, 3 has the reasoning:

Although this [STARTTLS] mechanism has been deployed, an alternate mechanism where TLS is negotiated immediately at connection start on a separate port (referred to in this document as "Implicit TLS") has been deployed more successfully. To encourage more widespread use of TLS and to also encourage greater consistency regarding how TLS is used, this specification now recommends the use of Implicit TLS for POP, IMAP, SMTP Submission, and all other protocols used between an MUA and an MSP.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
-3

SMTP uses port 25 for server-to-server communication, and port 587 for client-to-server communication.

There is no real difference in protocol here, but administrators of larger sites likely want different policies for receiving mail from other domains vs receiving mail from own customers that is likely going out to other domains, and that's why two different ports exist: it allows firewall rules to distinguish easily.

Mail servers for incoming mail do not need to verify users' credentials, ever, so they do not need to be given access to this database, while mail servers for outgoing mail need to authenticate local users, so they do need that access -- but they don't need to be reachable from everywhere in the world.

Port 465 is an SSL-only variant of port 25, but this is already handled fine with opportunistic encryption negotiated through the STARTTLS response to the EHLO command, and the STARTTLS command, which is faster than trying port 465 first, running into a timeout and then trying port 25.

Port 587 never had an SSL-only variant port assigned, and its use case is still relevant.

Server-to-server transfers use opportunistic encryption and likely fall back to unencrypted transmission if that fails -- end-to-end security is provided by encrypting the mail itself, because even with encrypted connections between servers, the mail is processed on each server.

Clients are supposed to use port 587, negotiate encryption and have a sensible policy what to do when that negotiation fails, for example it could be acceptable to continue using a challenge-response authentication method and transmit the mail unencrypted, while a password authentication scheme would become unsafe without an encryption layer below.

Simon Richter
  • 3,209
  • 17
  • 17
  • 1
    As of 2017-12-12, IANA port assignments [include the re-assigned Port 465](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=465), now clearly identified as `submissions` - an alternative to the `submission` port, *not* the `smtp` port. – anx May 30 '21 at 18:35