Proposal: SMTP Over TLS on Port 26

SMTP is still suffering from downgrade attacks like STRIPTLS. While we have “Opportunistic TLS”, we still don’t have “Implicit TLS” in the SMTP. Just to be clear, we do have “Implicit TLS” for “SMTP Submission” on port 465. But we don’t have a secure port 25 alternative. i.e. The real SMTPS.

Both MTA-STS and DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires TLSA dns record support.

This proposal fixes STARTTLS downgrade issue and propose a new port 26, an “Implicit TLS” alternative for port 25 and recommends the MX server to signal the port via a prefix.

Proposal

20 years back “Opportunistic TLS” was introduced instead of “Implicit TLS”. That's because there was no way for a server to “signal” the port 465 existence. Actually there was a way (Prefix). But they missed that.

Port 465 was discontinued in the late 90’s and then reassigned to “submissions” in 2018.

This 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”.

Example:

ACME, Inc. has the following MX servers.

mx1.acme.com
mx2.acme.com
mx3.acme.com
mx4.acme.com
mx5.acme.com

They all should be prefixed like this if they support STARTTLS on port 25.

starttls-mx1.acme.com
starttls-mx2.acme.com
starttls-mx3.acme.com
starttls-mx4.acme.com
starttls-mx5.acme.com

Now ACME, Inc. need to protect those records via DNSSEC since DNS responses can be modified.

If ACME, Inc. use a third party mail hosting services like Google G-Suite, Google MX servers will begin with “starttls-” prefix. However acme.com still need to protect their DNS via DNSSEC.

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.

So now SMTP clients can check for whether MX server starts with the string “smtps”. If it starts with that string, then the clients gonna connect to port 26 (smtps). A normal client that doesn’t know what “smtps” stands for gonna connect to port 25 as usual.

Final Result:

| Port            | 25        | 26        | 587        | 465         |
| --------------- | --------- | --------- | ---------- | ----------- |
| Service Name    | smtp      | smtps     | submission | submissions |
| Protocol Name   | SMTP      | SMTPS     | Submission | SubmissionS |
| Auth Required?  | No        | No        | Yes        | Yes         |
| Implicit TLS?   | No        | Yes       | No         | Yes         |
| Plain Text?     | Yes       | No        | Yes        | No          |
| Discovery?      | MX Record | MX Record | Direct     | Direct      |
| Public?         | Yes       | Yes       | No         | No          |

IANA Considerations

Service Name

Let’s give a service name for IANA identification. Obviously it’s “smtps”.

IANA Service Name: smtps

Port

Port 26 is unassigned. And it’s very adjacent to port 25. So let’s use port 26.

IANA Recommended Port: 26

Certificate Validation

The whole point of SMTPS (port 26) is about security. Clients should treat SMTPS as it treat HTTPS. So when the certificate is invalid, clients should drop the connection rather than proceeding with invalid certificates.

Mail server admins must make sure that they have valid SSL certificates on port 26 before naming their MX servers with “smtps” prefix.

SMTPS ≠ HTTPS

In HTTPS, you have url like this. https://www.google.com

That says the following two things.

Protocol: HTTPS

Domain: www.google.com

If the certificate presented by the server, doesn’t match the domain, then the certificate is INVALID. End of story.


In SMTPS, you have an email address john@acme.com

Original Domain: acme.com

The MX record says, smtps-aspmx.l.google.com

Protocol: SMTPS

Delivery Server Domain: google.com

Since MX records can point to any domain, SSL certificates cannot be trusted here.

For example, what if some attacker, change the MX response from smtps-aspmx.l.google.com to smtps-mx1.attacker.com

Now, you are delivering your mails to the attacker.com domain instead of google.com domain.

If you don’t want your DNS responses to be spoofed, then you MUST enable DNSSEC for your domain.

Migration

Self-Hosted

This example assumes that your domain name is example.com and your mail servers are mx1.example.com, mx2.example.com, mx3.example.com, mx4.example.com and mx5.example.com

Step 1: Serve SMTPS mail server on port 26 and make sure to port 25 supports “Opportunistic TLS”.

Note: Both port 25 and 26 must have valid SSL certificates.

Step 2: Update firewall rules

Step 3: Add new hostnames with the same IP addresses

; mail domain
example.com.              MX      5 mx1.example.com.
example.com.              MX     10 mx2.example.com.
example.com.              MX     20 mx3.example.com.
example.com.              MX     20 mx4.example.com.
example.com.              MX     40 mx5.example.com.

; SMTP server host names (Old)
mx1.example.com.          A     192.0.2.1
mx2.example.com.          A     192.0.2.2
mx3.example.com.          A     192.0.2.3
mx4.example.com.          A     192.0.2.4
mx5.example.com.          A     192.0.2.5

; SMTP server host names (New)
smtps-mx1.example.com.   A     192.0.2.1
smtps-mx2.example.com.   A     192.0.2.2
smtps-mx3.example.com.   A     192.0.2.3
smtps-mx4.example.com.   A     192.0.2.4
smtps-mx5.example.com.   A     192.0.2.5
                        

Note: I excluded AAAA records for simplicity. If you have AAAA records, don’t forget to duplicate that too.

Step 4: Update MX records

; mail domain
example.com.        MX      5 smtps-mx1.example.com.
example.com.        MX     10 smtps-mx2.example.com.
example.com.        MX     20 smtps-mx3.example.com.
example.com.        MX     20 smtps-mx4.example.com.
example.com.        MX     40 smtps-mx5.example.com.
                        

Step 5: Wait for DNS propagation (Wait time depends on your TTL value). Use tools like whatsmydns to check propagation.

e.g. https://www.whatsmydns.net/#MX/gmail.com

Step 6: Remove “SMTP server host names (Old)” once DNS propagated.

Third-Party Hosted

Third-Party mail servers are more like “Software Distributors”. Instead of distributing the “softwares”, they distributed “MX records”. e.g. Google Apps aka. G Suite

Millions of domains depend on the MX records. So third-party mail servers need to main two versions of MX Records for some years.

The following example uses example.net as third party mail hosting provider.

Third party mail servers should work on both cases.

; mail domain
example.com.        MX      5 mx1.example.net.
example.com.        MX     10 mx2.example.net.
example.com.        MX     20 mx3.example.net.
example.com.        MX     20 mx4.example.net.
example.com.        MX     40 mx5.example.net.

; mail domain
example.com.        MX      5 smtps-mx1.example.net.
example.com.        MX     10 smtps-mx2.example.net.
example.com.        MX     20 smtps-mx3.example.net.
example.com.        MX     20 smtps-mx4.example.net.
example.com.        MX     40 smtps-mx5.example.net.
                        

Third party mail servers should encourage their customers to update the MX records with the new version for better security.

They should gracefully degrade the older version of MX record. e.g. They should notify their customers via email saying old version will not work after X years.

When the grace period is over, third party mail hosting providers should fetch the MX record from their customers domain and warn them if they still use the older version.

Internationalized Domain Names

IDN converts non ASCII characters to ASCII characters.

Tested on: https://www.punycoder.com/

Input

smtps-افغانستا.afghanistan.com
smtps-الجزائر.algeria.com
smtps-österreich.austria.com
smtps-বাংলাদেশ.bangladesh.com
smtps-беларусь.belarus.com
smtps-belgië.belgium.com
smtps-българия.bulgaria.com
smtps-تشادر.chad.com
smtps-中国.china.com
smtps-القمر.comoros.com
smtps-κυπρος.cyprus.com
smtps-českárepublika.czech-republic.com
smtps-مصر.egypt.com
smtps-ελλάδα.greece.com
smtps-magyarország.hungary.com
smtps-ísland.iceland.com
smtps-भारत.india.com
smtps-ايران.iran.com
smtps-éire.ireland.com
smtps-איקו״ם.israel.com
smtps-日本.japan.com
smtps-الأردن.jordan.com
smtps-қазақстан.kazakhstan.com
smtps-한국.korea.com
smtps-кыргызстан.kyrgyzstan.com
smtps-ລາວ.laos.com
smtps-لبنان.lebanon.com
smtps-македонија.macedonia.com
smtps-موريتانيا.mauritania.com
smtps-méxico.mexico.com
smtps-монголулс.mongolia.com
smtps-المغرب.morocco.com
smtps-नेपाल.nepal.com
smtps-عمان.oman.com
smtps-قطر.qatar.com
smtps-românia.romania.com
smtps-россия.russia.com
smtps-србијаицрнагора.serbia-montenegro.com
smtps-இலங்கை.sri-lanka.com
smtps-españa.spain.com
smtps-ไทย.thailand.com
smtps-تونس.tunisia.com
smtps-türkiye.turkey.com
smtps-украина.ukraine.com
smtps-việtnam.vietnam.com

Output

xn--smtps--ujiaa3a2hwd7d6c.afghanistan.com
xn--smtps--njiha3c3cj6u.algeria.com
xn--smtps-sterreich-etb.austria.com
xn--smtps--ngnwtxb5c3b1fc1k.bangladesh.com
xn--smtps--8nfh0bydycmz1k.belarus.com
xn--smtps-belgi-9bb.belgium.com
xn--smtps--8nfhs5c4a6d4g5c.bulgaria.com
xn--smtps--ujix0cu4a.chad.com
xn--smtps--gw7is51d.china.com
xn--smtps--uji4fthtam.comoros.com
xn--smtps--nze4bikxu.cyprus.com
xn--smtps-eskrepublika-6rb09f.czech-republic.com
xn--smtps--uli5a7l.egypt.com
xn--smtps--uwe4b0ai0ea.greece.com
xn--smtps-magyarorszg-mpb.hungary.com
xn--smtps-sland-tcb.iceland.com
xn--smtps--uwm3d1a3l.india.com
xn--smtps--ujia3g5job.iran.com
xn--smtps-ire-g4a.ireland.com
xn--smtps--g1h4b9a4b4g5g.israel.com
xn--smtps--ul2mm8f.japan.com
xn--smtps--1ii5a7eta1s1a.jordan.com
xn--smtps--8nfaa2e8c3bn55jda.kazakhstan.com
xn--smtps--876wx05u.korea.com
xn--smtps--8nfx0b2a0b6apo4kc.kyrgyzstan.com
xn--smtps--nyuq2h.laos.com
xn--smtps--ujih5wvab.lebanon.com
xn--smtps--8nfa9aj8avyso23b.macedonia.com
xn--smtps--ujiaz3e6lpaw3ad.mauritania.com
xn--smtps-mxico-hbb.mexico.com
xn--smtps--uof8dahllc8b2a.mongolia.com
xn--smtps--ujii4f6d3em.morocco.com
xn--smtps--nxmq6e3f5d.nepal.com
xn--smtps--uji7lmel.oman.com
xn--smtps--uli1c2f.qatar.com
xn--smtps-romnia-xbb.romania.com
xn--smtps--upf1crla3o.russia.com
xn--smtps--8nfaahy1db4eryeei9hsr.serbia-montenegro.com
xn--smtps--1eq6f9a3uui4b.sri-lanka.com
xn--smtps-espaa-beb.spain.com
xn--smtps--84t8dyo.thailand.com
xn--smtps--gki6e0ita.tunisia.com
xn--smtps-trkiye-jlb.turkey.com
xn--smtps--8nfa5esa9a7a0b.ukraine.com
xn--smtps-vitnam-gj6f.vietnam.com

So clients should look for prefixes like

“smtps-”, “starttls-”, “xn — smtps-” “xn — starttls-”

Conclusion

In HTTPS, you prepend the “https” in the URL like https://www.google.com to signal the port 443 existence.

In this proposal you are doing the same thing with “smtps-” and “starttls-” prefixes.

https://www.google.com => www.google.com:443

smtps-mx1.example.net => smtps-mx1.example.net:26

starttls-mx1.example.net => starttls-mx1.example.net:25

Security Considerations

DNS Query responses are prone to forgery. So protect your DNS entries with the help of DNSSEC.

Port 26 will be a secure alternative for Port 25. So Internet Service Providers are advised to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary.

MTA-STS — Requires additional TXT record and a HTTPS server

DANE — Requires DNSSEC and TLSA records.

SMTP Require TLS — Introduces SMTP service extension, REQUIRETLS, and message header field, RequireTLS.