Encrypted email you can trust. Private communications that remain private. Protecting your messages from prying eyes. In the world of email security, these are the promises of STARTTLS – a clever technology that brought encryption to the masses by upgrading existing plaintext sessions to secure TLS connections.
For 25 years, STARTTLS has delivered opportunistic email encryption to billions of users by transforming common protocols like SMTP, POP3, and IMAP into encrypted channels. Using dedicated ports like 587 combined with proper security practices, STARTTLS provides strong defenses against email interception and attacks.
This definitive guide covers everything you need to know about taking advantage of STARTTLS encryption for email privacy and security in your own systems. Let’s get started!
A Brief History of Email Encryption Protocols
In the early days of email, messages were transmitted in plaintext with no encryption. As email grew in popularity for personal and business use, the need for security and encryption became apparent. This section will explore the evolution of email encryption protocols like SSL, TLS, and most importantly, STARTTLS.
The Early Days of Plaintext Email
It may be hard to imagine today, but email communication was entirely plaintext and insecure when protocols like SMTP, POP3, and IMAP were first adopted in the 1980s and 90s. Encryption technology like SSL and TLS did not yet exist.
Sending a sensitive email over early protocols meant any attacker could intercept and read the entire contents with ease. And passwords or other confidential data were transmitted openly, completely visible to anyone monitoring the connection.
Of course, email adoption exploded even with these security gaps, as the benefits of fast asynchronous communication outweighed potential risks for most personal users.
But for businesses, lack of encryption posed significant problems. No company wanted confidential documents or communications leaked publicly. And password theft via email interception became increasingly common.
It was clear early on that email desperately needed a security upgrade. The only question was – how to add encryption without breaking all existing email infrastructure?
The Advent of SSL and TLS for Encryption
In the mid 90s, Netscape developed Secure Sockets Layer (SSL) encryption to secure web traffic. SSL used public key cryptography to encrypt data in transit between a client and server.
SSL certificates validated a server’s identity, preventing man-in-the-middle attacks. And the SSL handshake allowed clients and servers to establish secure connections.
SSL was quickly adopted to encrypt website traffic over HTTP. But applying SSL to existing email protocols proved more complex.
Transport Layer Security (TLS) emerged in 1999 as a more advanced encryption protocol. It included improved encryption algorithms and integrity checks compared to SSL.
Almost all modern encrypted web traffic uses TLS instead of SSL today (though the terms are still used interchangeably).
With strong encryption available, the race was on to implement SSL/TLS for email. But how could this be added without breaking existing email infrastructure and client software?
The Role of STARTTLS in Upgrading Connections
Since email protocols like SMTP were designed without encryption, they used plaintext ports by default for communication:
- SMTP = Port 25
- POP3 = Port 110
- IMAP = Port 143
The idea arose to designate new alternative ports that required encryption:
- SMTP over SSL/TLS = Port 465
- POP3 over SSL/TLS = Port 995
- IMAP over SSL/TLS = Port 993
But major problems quickly emerged. Many email clients only worked with the default plaintext ports. And even if they supported SSL, changing ports was complex for average users.
STARTTLS provided an elegant solution. It allowed clients to start a session in plaintext, then upgrade to TLS encryption by sending a STARTTLS command. The existing session was secured without changing ports or breaking client compatibility.
This allowed services to support both plaintext and encrypted connections simultaneously during the transition period. Users could upgrade security at their own pace.
Of course, STARTTLS has downsides too. Transmitting information before TLS upgrade leaves data briefly exposed. And the upgrade is dependent on proper client/server STARTTLS support.
But overall, STARTTLS succeeded in bringing email encryption into the mainstream. It remains widely used today across SMTP, IMAP, POP3, and other protocols.
The encryption protocols powering STARTTLS have evolved over time from SSL to TLS 1.2 and 1.3. And debates continue about the long-term role of STARTTLS vs implicit TLS for email security.
But without STARTTLS providing a flexible path to encryption, we may have been stuck in the days of plaintext email much longer. STARTTLS paved the way for encrypted email to become the universal standard it is today.
How STARTTLS Differs from Implicit TLS
STARTTLS and implicit TLS both provide email encryption, but take different approaches. Understanding how they differ in establishing connections and using ports reveals the pros and cons of each method.
Default Ports for Plaintext vs Encrypted Email
To appreciate how STARTTLS differs from implicit TLS, we first need to understand the default port conventions:
- Plaintext protocols use standard ports:
- SMTP = Port 25
- POP3 = Port 110
- IMAP = Port 143
- Encrypted protocols use alternative ports:
- SMTP over TLS = Port 465
- POP3 over TLS = Port 995
- IMAP over TLS = Port 993
These alternative ports were designated for implicit TLS – encryption is required from the start of the connection. Trying to communicate in plaintext on these ports will fail.
Upgrading Existing Connections with STARTTLS
STARTTLS allows clients to establish a normal plaintext session on the standard unencrypted ports first.
Once connected, the client issues a STARTTLS command to upgrade the existing insecure session to encrypted TLS:
- Client connects to server on a standard plaintext port
- Client sends STARTTLS command
- Client and server perform TLS handshake to encrypt session
- Session continues securely over the upgraded encrypted channel
This makes STARTTLS backwards compatible – it works on the default ports without breaking older client software that doesn’t support alternative encrypted ports.
Forcing Encryption with Implicit TLS
Implicit TLS takes a different approach – it enforces encryption by only allowing secure connections on special alternative ports like 465, 993, and 995.
With implicit TLS:
- Client attempts to connect to the alternate encrypted port
- The server immediately performs a TLS handshake to encrypt the session
- If encryption fails, the connection is rejected
This guarantees encryption since plaintext connections are not allowed. But both client and server must support the alternate port and implicit TLS.
However, some email servers block alternate ports, which can cause connection failures. And many old email clients don’t work with the alternate ports meant for implicit TLS.
Key Differences Summarized
In summary, the key differences between STARTTLS and implicit TLS are:
|Upgrades plaintext sessions on standard ports||Forces encryption on alternate ports|
|Encryption is negotiated on an existing connection||Encryption required from the start|
|Compatible with old software and firewalls||Rejected if handshake fails|
|Brief data exposure before TLS upgrade||Fully encrypted session|
So in essence:
- STARTTLS maintains backwards compatibility by upgrading old ports
- Implicit TLS prioritizes security by enforcing encryption on new ports
Over time, implicit TLS is gaining favor as the most secure approach. But STARTTLS remains widely used to support legacy systems and allow transitional upgrades.
Which method a client uses depends on software capability and port availability. Apps with modern encryption support often default to implicit TLS for enhanced security.
But STARTTLS provides the flexibility to connect from restrictive networks and use old devices that cannot handle the newer implicit TLS ports.
Using Port 587 for STARTTLS-Enabled SMTP
For submitting outgoing email, SMTP port 587 has emerged as the recommended standard to support STARTTLS encryption. Let’s examine why port 587 is favored over other options, how STARTTLS enables secure SMTP connections on this port, and some key compatibility considerations.
Why Port 587 is Recommended for SMTP Submission
Briefly, the history of SMTP port conventions is:
- Port 25 was originally used for all SMTP traffic
- Port 465 was designated for implicit SMTP over TLS
- Port 587 was added specifically for SMTP submissions
Today, port 587 is recommended for client submissions for these reasons:
- Port 25 is reserved for communication between mail servers only
- Port 465 has compatibility issues with some mail services
- Port 587 is dedicated to client submission with STARTTLS
Relegating client submissions to port 587 allows mail providers to restrict port 25 to just server-to-server SMTP transactions. This reduces abuse from spammers and botnets exploiting open relays on port 25.
And while port 465 supports implicit TLS, some providers block this port. Port 587 overcomes this issue by using STARTTLS for opportunistic encryption.
So port 587 provides the best of both worlds – support for secure STARTTLS connections while avoiding port blocks.
How STARTTLS Works with Port 587
On port 587, the SMTP transaction begins as plaintext before being upgraded to TLS:
- Client establishes connection on port 587
- Server offers STARTTLS option in SMTP banner
- Client issues STARTTLS command
- Server and client perform TLS handshake to encrypt session
- Session continues over encrypted connection
Requiring clients to authenticate with a username and password before enabling STARTTLS protects against any sensitive data leakage.
Once STARTTLS is negotiated, all further SMTP commands and data transmit securely. The message contents are encrypted until delivery.
Compatibility Considerations for Port 587
Port 587 is well-supported today across most major mail clients and servers:
- Web clients like Gmail, Outlook.com, Yahoo Mail all use port 587 by default for sending
- Mail apps like Thunderbird and Apple Mail also default to 587
- Mail servers like Exchange and Postfix enable 587 with STARTTLS
However, some legacy systems and older clients still fail to connect over port 587 for various reasons:
- Very old servers may not be updated to support submission on port 587
- Legacy clients hard-coded to use port 25 will reject other ports
- Firewalls may allow port 25 but block ports 465 and 587
Workarounds exist like configuring port forwarding rules. But ideally, legacy email software should be updated to support modern security standards.
Fortunately, as outdated mail systems fade out, port 587 is reaching near universal adoption. When configured properly, it offers a future-proof SMTP submission solution with opportunistic TLS encryption through STARTTLS.
Configuring Clients and Servers for STARTTLS
To use STARTTLS encryption, both the email client and server must be properly configured. We’ll cover the key settings needed to enable STARTTLS on servers, configure client software, and troubleshoot connection issues.
Enabling STARTTLS Support on Email Servers
Most modern mail servers like Exchange, Postfix, and G Suite support STARTTLS by default for SMTP, IMAP, and POP3. But some legacy servers require enabling STARTTLS manually.
On open source SMTP servers like Postfix, look for SMTP settings like:
smtpd_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/mail.pem smtpd_tls_key_file = /etc/ssl/private/mail.key smtpd_use_tls = yes
This specifies the server should use opportunistic TLS, require auth before STARTTLS, and points to the SSL/TLS cert files.
For IMAP/POP3, Postfix configs would be:
imap_tls_security_level = may imap_tls_cert_file = /etc/ssl/certs/mail.pem imap_tls_key_file = /etc/ssl/private/mail.key pop3_tls_security_level = may pop3_tls_cert_file = /etc/ssl/certs/mail.pem pop3_tls_key_file = /etc/ssl/private/mail.key
Consult your server docs for details on enabling STARTTLS support. A valid TLS certificate is required.
Settings for Email Clients to Use STARTTLS
Email clients should have an option like “Use STARTTLS when available” under account settings. This enables opportunistic TLS.
Some clients have a “Use TLS” option which enforces implicit TLS only. This conflicts with servers lacking implicit support.
Clients should connect on the standard SMTP, IMAP, and POP3 ports of 25, 143, 110 rather than alternate encrypted ports when using STARTTLS.
Troubleshooting STARTTLS Connection Issues
To diagnose STARTTLS problems:
- Verify the server offers STARTTLS – connect with Telnet and check for the STARTTLS banner
- Try an encrypted TLS connection test with OpenSSL s_client
- Inspect client/server logs to confirm STARTTLS use and see any TLS errors
- Test with port 587 for SMTP since this is dedicated to STARTTLS submission
- Update old SSL/TLS versions as needed – TLS 1.2+ is recommended
- Check firewalls, antivirus, proxies for interference with TLS handshakes
- Confirm trusted valid certificates – expire or self-signed certs cause problems
With robust server and client STARTTLS implementations, opportunistic email encryption should negotiate smoothly without disruption. Pay attention to any TLS errors and upgrade outdated software to maintain secure connections.
Best Practices for Using STARTTLS Securely
While STARTTLS facilitates encrypted email sessions, additional steps are needed to utilize it safely. Follow these best practices to maximize your STARTTLS security:
Validating Server Certificates and Identities
When initiating a STARTTLS handshake, the server provides a digital certificate to prove its identity.
Clients should validate these certificates to avoid man-in-the-middle attacks:
- Verify the certificate is issued by a trusted certificate authority
- Check that the domain in the certificate matches the server domain
- Confirm the certificate is not expired or revoked
- Use certificate pinning to detect unauthorized certificates
- Consider using DANE TLSa to validate certificates against DNS records
Scrutinizing certificates before encrypting traffic ensures you are communicating with the legitimate server.
Keeping Up with Encryption Standards and Protocols
As attacks against SSL and TLS progress, new versions aim to stay ahead of vulnerabilities.
Make sure your software is up-to-date with modern encryption standards:
- Use TLS 1.2 or higher (disable outdated SSL and TLS 1.0/1.1)
- Ciphers should use perfect forward secrecy and 2048+ bit keys
- Prefer elliptic curve cryptography (ECC) ciphers for performance
- Disable NULL, MD5, SHA-1, RC4 and other weak ciphers
- Watch for new TLS 1.3 adoption and implementation best practices
Proactively updating your TLS configuration prevents downgrade attacks and known protocol weaknesses.
Monitoring for Plaintext Leaks with STARTTLS
A common STARTTLS misconfiguration is allowing unauthorized plaintext transmission:
- Sensitive information sent before STARTTLS negotiates encryption
- Clients not validating server certificates properly
- Buggy clients attempting TLS on plaintext ports
Monitor your traffic to catch any unintended plaintext leaks:
- Inspect packet captures for plaintext secrets on TLS ports
- Log traces of SMTP, POP3, IMAP sessions to confirm proper STARTTLS use
- Test externally by transmitting plain “canaries” and watch for exposure
- Script port scans to confirm non-TLS ports reject unencrypted sessions
With vigilance, you can enforce that communications only flow through secure encrypted channels as intended.
By validating certificates, hardening TLS, and detecting misconfigurations, you can trust that STARTTLS connections provide rock-solid security. Keep your knowledge sharp and configurations current to maximize protection.
The Future of Email Encryption with STARTTLS
STARTTLS has provided a robust way to incrementally add encryption to email over the last 20 years. But what does the future hold for STARTTLS and email security?
Wider Adoption of Implicit TLS Expected
As legacy mail software fades out, services are pushing clients toward implicit TLS with required encryption ports like 465, 993, 995 rather than opportunistic STARTTLS.
The advantages of implicit TLS include:
- Encryption guaranteed from the start of the session
- No risk of accidentally leaking plaintext data before STARTTLS
- Simpler configuration without STARTTLS handshakes
The downside is reduced compatibility with older systems lacking support for the alternate implicit TLS ports.
But as clients and servers are steadily updated to support implicit TLS, its usage will likely eclipse STARTTLS over time. Email providers will also continue locking down port 25 for server-only communication to limit exploits.
New Protocols May Eventually Replace STARTTLS
While TLS 1.3 currently powers most encrypted web traffic, QUIC and HTTP/3 may begin taking over as they support encryption by default.
The IETF has also proposed EMAIL, a new secure email transport protocol designed as a potential successor to SMTP, POP3, and IMAP.
If these newer protocols gain adoption, they could eventually replace opportunistic STARTTLS for email encryption as well.
However, given the slow pace of upgrading email infrastructure, don’t expect STARTTLS to disappear anytime soon even if other standards emerge.
Continued Importance of Encryption for Email Privacy
Regardless of the specific protocol, end-to-end email encryption will only grow in importance for privacy and security:
- Surveillance capitalism fuels demand for encrypted communications
- Regulations like GDPR require safeguarding personal data
- Email scams and phishing require stronger authentication
- Politically sensitive correspondence needs protection
- Businesses want to avoid email data breaches
So while the technology powering email encryption may change, the fundamental need for security is not going away.
Even if STARTTLS itself is eventually superseded, it helped bring ubiquitous email encryption into the mainstream. And any successor protocols will build on this foundation of opportunistic TLS that STARTTLS established.
The specific path forward is unclear, but the overarching trend toward universal encrypted email is certain. STARTTLS paved the way by retrofitting encryption into existing email systems, a contribution that will reverberate for decades to come.
Key Takeaways on Using the STARTTLS Port
The key points to remember about using port 587 and STARTTLS for email encryption are:
- STARTTLS allows opportunistic encryption by upgrading an insecure session to TLS on the standard email ports.
- Port 587 is the recommended standard for STARTTLS-enabled SMTP submissions.
- Implicit TLS differs by requiring encryption from the start on special ports like 465.
- Always validate server certificates and identities before encrypting STARTTLS connections.
- Keep client and server TLS configurations up-to-date and disable outdated protocols.
- Monitor for misconfigurations that allow unintended plaintext transmissions.
- Migration toward implicit TLS on clients and servers is gradually progressing.
- STARTTLS paved the way for ubiquitous email encryption and remains widely supported.
- Encryption will only grow more important for email privacy, regardless of the specific protocols used.
Following security best practices for STARTTLS allows businesses and individuals to encrypt email in a backwards compatible way during the encryption transition period. As implicit TLS gains adoption, STARTTLS provides a flexible path to incrementally securing legacy email systems.
Frequently Asked Questions About STARTTLS
Let’s review some common questions about using STARTTLS for email encryption:
What is the difference between STARTTLS and implicit TLS?
STARTTLS upgrades an existing insecure session to encrypted TLS, while implicit TLS requires encryption from the start on special ports. STARTTLS works on the standard email ports and provides opportunistic encryption.
Is STARTTLS secure?
Yes, when configured properly STARTTLS provides secure encrypted communication. The encryption is negotiated after the session starts, so some initial data may leak before STARTTLS activates. Always validate server certificates to avoid interception.
Do email clients support STARTTLS?
Most modern email clients and servers have support for STARTTLS to enable encrypted SMTP, POP3, and IMAP sessions. Some very old legacy systems may lack STARTTLS capabilities.
What port should I use for STARTTLS SMTP?
Port 587 is the recommended standard port for STARTTLS-enabled SMTP submission by clients. Port 25 is for server-to-server mail transactions only.
How can I tell if STARTTLS is working?
Check application logs to confirm STARTTLS is negotiated properly during sessions. Watch for any TLS errors. You can also use packet captures or protocol analyzers to validate encryption is activated after STARTTLS commands.
Is STARTTLS being phased out?
STARTTLS remains widely supported, but a gradual transition is happening toward implicit TLS for enhanced security. STARTTLS may eventually be phased out as legacy systems with compatibility requirements are decommissioned.
What TLS version should I use with STARTTLS?
TLS 1.2 or higher is recommended. TLS 1.3 is ideal if supported. Avoid outdated protocols like SSLv3 or TLS 1.0.