Dombox - SMTP Ports (25 vs 587 vs 465)

HTTP vs HTTPS

You obviously heard of “HTTP” and “HTTPS”. But do you know that we don’t have SMTPS in email? SMTPS was actually introduced in the late 90s, but within a short period of time, it got deprecated.

Whenever we mention the term “HTTP”, we are talking about “Plain Text”. When you load a HTML page, this is how your internet service provider (ISP) sees the data.

<!DOCTYPE html>
<html>
<body>
    <p>Hello World</p>
</body>
</html>

When you submit username and password in a login form, it will be sent as Plain Text like this.

username=someuser&pass=password

Your ISP can modify that data. In 2017, Comcast injected 400+ lines of javascript code to advertise their modem.

HTTPS means fully encrypted. A secure connection is established first before exchanging any data. That means your ISP cannot able to eavesdrop what you do online unless they have access to your web browser or the web server or the private key. The snooped data would look like nothing but a grabage text. So it’s not possible to inject code in the HTTPS case.

HTTP and HTTPS are two different protocols. HTTP official port is 80 and the HTTPS official port is 443. When you visit www.facebook.com in HTTP, you are actually connecting to www.facebook.com:80 and when you visit in HTTPS, you are connecting to www.facebook.com:443

Sir Tim Berners-Lee invented the World Wide Web in 1989 and introduced HTTP 1.0 in 1996 in an Informational RFC. HTTP officially became an internet standard in 1997.

SSL/TLS

Now… let’s talk about some SSL/TLS history.

In the mid 90s, Netscape was the most popular web browser and the browsers were a paid software at that time.

At that time, Microsoft also wanted to get into browser business. Microsoft’s Windows operating system already had 90% of the market share. On new Windows OS releases, Microsoft included the Internet Explorer browser for free, whereas you need to download other browsers. Keep in mind, those were dial-up modem days. Hence, the internet speed was very slow. Microsoft strategies helped them to gain browser market share. IE became the most popular browser in the late 90s.

Netscape actually developed the SSL protocol in mid 90s. The first version had some serious flaws so they never released it to the public. Then, they released SSL 2.0 in 1995. But there were still some flaws.

Microsoft created its own version of SSL for IE in 1995 and they called it the Private Communication Technology (PCT). It works exactly like SSL 2.0 but it also fixed the flaws found in SSL 2.0

Netscape didn’t give up. They started to fix all the SSL flaws encountered back then and released SSL 3.0 in 1996.

Industry insiders doesn’t want another SSL. So, they made Microsoft to negotiate a deal with Netscape where a third party would take over the SSL and PCT projects and make it open source. Thus begun the TLS Era. They named the new open source protocol as TLS.

TLS 1.0 is nothing but SSL 3.0 with some slight modifications. SSL was a proprietary protocol back then. All versions of SSL are outdated now. Your web servers should not support SSL at all.

When it comes to marketing, the term “SSL” is widely used. So use the term “SSL” only if you are planning to buy SSL certificates. For example, the search term “Buy SSL Certificates” can fetch you more relevant results than “Buy TLS Certificates”. So, “Buy SSL, Use TLS”

HTTPS vs SMTPS

TLS 1.0 was introduced in 1999. HTTPS was introduced in 2000.

HTTPS had some advantages when compared to SMTPS.

First, HTTP was relatively young standard while compared to SMTP. Email was invented in 1971 by Ray Tomlinson. 10 years later, Jon Postel defined SMTP in 1982. When TLS 1.0 introduced in 1999, SMTP was a very matured and widely used technology.

Second, HTTP already had redirect capabilities. 301 — Moved Permanently, 302 — Moved Temporarily. Browsers can understand those HTTP status codes. So if you visit http version of www.example.com, the server can respond like this

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com

SMTP don’t have any such redirect capabilities.

Third, the majority of the people in the world, use web browsers for browsing the “world wide web (www)”. So web browsers are the major HTTP clients. TLS is already a byproduct of both Netscape and Microsoft. And they both held the major browser market share. All they have to do is just add HTTPS support in their next browser versions. End of story.

In SMTP case, there is only a dozen commands out there. HELO, MAIL, RCPT, DATA, QUIT etc. So it’s very easy to build your own SMTP client. That means the “SMTP Clients” are not controlled by a handful of entities like “HTTP Clients”. Persuading every SMTP Client and SMTP Server to support SMTPS is not possible here.

SMTP port is 25. When SMTPS got introduced they assigned port 465 for that. Since SMTPS is not backward compatible, they discontinued that port and favoured Opportunistic TLS.

Extended SMTP

Let’s travel back to mid 90s again. In 1995 “SMTP Service Extensions” got introduced. This is also known as “Extended SMTP” or “ESMTP”. So when SMTPS discontinued in the late 90s, we already had ESMTP support.

mail.example.com connecting to mail.yahoo.com with its IP address
yahoo.com => 220 mail.yahoo.com Yahoo ESMTP Service Ready
example.com => EHLO mail.example.com
yahoo.com => 250-Hello, nice to meet you, mail.example.com
yahoo.com => 250-SIZE 1000000
yahoo.com => 250-8BITMIME
yahoo.com => 250 STARTTLS
example.com => STARTTLS
yahoo.com => 220 Go ahead
Key exchange happens here and the rest of the email part is encrypted

Pay attention to the third line here. EHLO means “Extended Hello”. If a server already supports those ESMTP commands, then it’s gonna respond with its list of supported extensions in multiline format (See hyphen near 250 code).

If the server doesn’t recognise EHLO command, that means it doesn’t support ESMTP. RFC 821 compatible SMTP server gonna respond with 500 error. 500 error means “Syntax error, command unrecognised”. So you can retry with the normal HELO command.

The 250-SIZE extension is for “Message size declaration”. There are more SMTP extensions available. CHUNKING, PIPELINING, SMTPUTF8 etc. But we are interested in the STARTTLS extension.

STARTTLS

STARTTLS extension got introduced in 1999. Paul Hoffman discontinued port 465 in Nov 1998 and introduced STARTTLS two months later in Jan 1999.

STARTTLS is an “Opportunistic TLS” command. Whereas SMTPS is “Implicit TLS”.

SMTPS is equivalent to HTTPS. Top to bottom everything encrypted. On the other hand, STARTTLS is an Opportunistic encryption. The opportunity for encryption is checked here in “Plain Text”.

In our last SMTP example, upto the line “220 Go ahead”, the conversation happens in “Plain Text” format. The key get exchanged and everything after that line like MAIL FROM, RCPT TO etc are encrypted.

STRIPTLS

There is one problem here. A man-in-the-middle attack can be initiated in the Opportunistic TLS that’s known as “STRIPTLS” attack.

In STRIPTLS attack, the attacker gonna strip the STARTTLS command. An experienced attacker would make the command unrecognised by replacing the characters to make it compatible with the Packet Size. e.g. STARTTLS => STARTXXX

Let’s go over our ESMTP example, one more time.

mail.example.com connecting to mail.yahoo.com with its IP address
yahoo.com => 220 mail.yahoo.com Yahoo ESMTP Service Ready
example.com => EHLO mail.example.com
yahoo.com => 250-Hello, nice to meet you, mail.example.com
yahoo.com => 250-SIZE 1000000
yahoo.com => 250-8BITMIME
yahoo.com => 250 STARTXXX

In the last example, the client (sender) is asking “Hello, What are the extensions do you support?” and the receiver (server) responds with the list of extensions.

The attacker replaced the STARTTLS command in the last example. Since the client (sender) doesn’t recognize the STARTXXX command, the whole mail will be transferred in “Plain Text”. Some ISPs in the US and Thailand performed this attack on their customers back in 2014.

STRIPTLS attack is a serious issue. An attacker can hijack your social media account with the help of STRIPTLS attacks.

e.g. Attacker Initiates forgot password request in Facebook, performs STRIPTLS attack. Now the attacker has your password reset confirmation link. We are using Facebook as an example. It can be applicable to any site that let you reset your password with a confirmation link.

Port History

Let's have a clear understanding of SMTP port history.

Port 25

Year introduced: 1982

Since the inception of SMTP, the port always been 25. Port 25 is a public port. i.e. anyone can use that port to deliver mail.

Port 25 will be used when a mail get transferred from one domain to another.

RFC 821 — Page 43 reads as follows

The SMTP transmission channel is a TCP connection established between the sender process port U and the receiver process port L. This single full duplex connection is used as the transmission channel. This protocol is assigned the service port 25 (31 octal), that is L=25.

IANA service name: smtp

Port 587

Year introduced: 1998

When you send a mail from your mail client like iPhone app or any desktop mail app, SMTP is being utilised in two areas. Submission and Transfer.

Your mail client (e.g. An iPhone mail app) submits the mail to the mail server (e.g. gmail.com) via SMTP.

The mail server performs spam and virus checks and then transfers the mail to the real recipient (e.g. someone@yahoomail.com).

So port 25 utilised for both “Submission” and “Transfer”.

After the invention of world wide web, internet started to see a hike in email usage. Mail services like HotMail, YahooMail started to appear in the 90s.

There was a hike in email spam too. Hackers started to hijack user computers by spreading worms and use them to send out spam mails without the users knowledge.

Internet Service Providers (ISP) who have millions of customers don’t want their Internet Service utilised for sending spam mails. i.e. They don’t want their service used for “Transfer” (direct-to-mx). Blocking all outgoing port 25 connections also blocks genuine mail submission connections.

So there was a need for another port dedicated for “Submission”. RFC 2476 introduced port 587. It’s an exact replica of port 25 functionality. But requires authentication for mail submission (i.e. iPhone mail app to Gmail Server).

In other words, port 25 is for “Public SMTP aka. Transfer”, port 587 is for “Private SMTP aka. Submission”

RFC 2476 — Abstract reads as follows

SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add ‘Received’, ‘Return-Path’, and other header fields as required by [SMTP-MTA].

However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).

Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper ‘Date’ header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way. Such completions or modifications have been shown to cause harm when performed by downstream MTAs — that is, MTAs after the first-hop submission MTA — and are in general considered to be outside the province of standardized MTA functionality.

Separating messages into submissions and transfers allows developers and network administrators to more easily:

Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail

Implement authenticated submission, including off-site submission by authorized users such as travelers

Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission

Detect configuration problems with a site’s mail clients

Provide a basis for adding enhanced submission services in the future

This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.

Page 3 reads as follows

Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified here.

IANA service name: submission

The service name should have been termed as: SMSP (Simple Mail Submission Protocol)

Port 465

Introduced: Early 1997

Discontinued: Late 1998

Reintroduced: 2018

This is one messed up port.

When TLS got introduced in the late 90s, IANA quickly registered the port 465 with service name “smtps”. In other words, this port is supposed to be used for secure version of the real SMTP. i.e. Port 25 alternative (Transfer).

But there was no way to use that port in “Transfer”. The problem is identifying whether the receiving server supports SMTPS or not. Recall our “301 — Moved Permanently” example. So they took a different route and introduced Opportunistic TLS in port 25. i.e. STARTTLS

The port 465 was never used in the “Transfer”. Hence, IANA revoked “smtps” service and assigned the port 465 to a completely irrelevant service called “URL Rendezvous Directory for SSM”

This is where things get interesting. IANA paid attention only to the “Transfer” part. But mail client softwares started to use that port for “Submission”. i.e. Secure alternative for Port 587.

Softwares are long lived. I mean, come on… People still use IE6.

When IANA assigned that port to some other service, developers continued to offer secure version of port 587 unofficially in port 465.

RFC 8314 made port 465 official in 2018. So IANA reassigned that port with the service name “submissions”. It’s not a plural form. “s” stands for “secure”. It should be pronounced as “SubmissionS”

IANA service name: submissions

The service name should have been termed as: SMSPS (Simple Mail Submission Protocol Secure)

RFC 8314 — Section 7.3 reads as follows

Historically, port 465 was briefly registered as the "smtps" port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service. In hindsight, the "smtps" registration should have been renamed or reserved rather than revoked. Unfortunately, some widely deployed mail software interpreted "smtps" as "submissions" [RFC6409] and used that port for email submission by default when an end user requested security during account setup. If a new port is assigned for the submissions service, either (a) email software will continue with unregistered use of port 465 (leaving the port registry inaccurate relative to de facto practice and wasting a well-known port) or (b) confusion between the de facto and registered ports will cause harmful interoperability problems that will deter the use of TLS for Message Submission. The authors of this document believe that both of these outcomes are less desirable than a "wart" in the registry documenting real-world usage of a port for two purposes. Although STARTTLS on port 587 has been deployed, it has not replaced the deployed use of Implicit TLS submission on port 465.

Port 26 New Proposal

SMTP Over TLS on Port 26 is our new proposal.

Email "Submission" part supports both SMTP (587) and SMTPS (465)

Email "Transfer" part supports only SMTP (25). SMTPS is still missing.

Our proposal offers two ways.

1. STARTTLS Prefix

Use this prefix on your MX records only to deal with STARTTLS downgrade issue.

e.g. mx1.example.com should be prefixed like starttls-mx1.example.com.

Where “starttls-” says “Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.

2. SMTPS Prefix

Use this prefix on your MX records if you wanna support both Implicit TLS on port 26 and Opportunistic TLS on port 25.

e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.

Where “smtps-” says “We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection”.

In “starttls-” prefix, port 25 MUST support encryption with Valid SSL certificates.

In “smtps-” prefix, BOTH port 26 and port 25 MUST support encryption with Valid SSL certificates.

Continue our SMTP Over TLS on Port 26 proposal here.