Quick Reference
Prefer Implicit TLS ports, they're more secure and if you use a Reverse Proxy, should be less hassle (although it's probably wiser to expose these ports directly to docker-mailserver).
Overview of email ports
| Protocol | Explicit TLS1 | Implicit TLS | Purpose |
|---|---|---|---|
| SMTP | 25 | N/A | Transfer2 |
| ESMTP | 587 | 4653 | Submission |
| POP3 | 110 | 995 | Retrieval |
| IMAP4 | 143 | 993 | Retrieval |
- A connection may be secured over TLS when both ends support
STARTTLS. On ports 110, 143 and 587,docker-mailserverwill reject a connection that cannot be secured. Port 25 is required to support insecure connections. - Receives email,
docker-mailserveradditionally filters for spam and viruses. For submitting email to the server to be sent to third-parties, you should prefer the submission ports(465, 587) - which require authentication. Unless a relay host is configured(eg SendGrid), outgoing email will leave the server via port 25(thus outbound traffic must not be blocked by your provider or firewall). - A submission port since 2018 (RFC 8314). Previously a secure variant of port 25.
What ports should I use? (SMTP)
Flowchart - Mermaid.js source:
View in the Live Editor.
flowchart LR
subgraph your-server ["Your Server"]
in_25(25) --> server
in_465(465) --> server
server(("docker-mailserver<br/>hello@world.com"))
server --- out_25(25)
server --- out_465(465)
end
third-party("Third-party<br/>(sending you email)") ---|"Receive email for<br/>hello@world.com"| in_25
subgraph clients ["Clients (MUA)"]
mua-client(Thunderbird,<br/>Webmail,<br/>Mutt,<br/>etc)
mua-service(Backend software<br/>on another server)
end
clients ---|"Send email as<br/>hello@world.com"| in_465
out_25(25) -->|"Direct<br/>Delivery"| tin_25
out_465(465) --> relay("MTA<br/>Relay Server") --> tin_25(25)
subgraph third-party-server["Third-party Server"]
third-party-mta("MTA<br/>friend@example.com")
tin_25(25) --> third-party-mta
end
Inbound Traffic (On the left):
- Port 25: Think of this like a physical mailbox, it is open to receive email from anyone who wants to.
docker-mailserverwill actively filter email delivered on this port for spam or viruses and refuse mail from known bad sources. While you could also use this port internally to send email outbound without requiring authentication, you really should prefer the Submission ports(587, 465). - Port 465(and 587): This is the equivalent of a post office box where you would send email to be delivered on your behalf(
docker-mailserveris that metaphorical post office, aka the MTA). Unlike port 25, these two ports are known as the Submission ports and require a valid email account on the server with a password to be able to send email to anyone outside of the server(an MTA you do not control, eg Outlook or Gmail). Prefer port 465 which provides Implicit TLS.
Outbound Traffic (On the Right):
-
Port 25: Send the email directly to the given email address MTA as possible. Like your own
docker-mailserverport 25, this is the standard port for receiving email on, thus email will almost always arrive to the final MTA on this port. Note that, there may be additional MTAs further in the chain, but this would be the public facing one representing that email address. -
Port 465(and 587): SMTP Relays are a popular choice to hand-off delivery of email through. Services like SendGrid are useful for bulk email(marketing) or when your webhost or ISP are preventing you from using standard ports like port 25 to send out email(which can be abused by spammers).
docker-mailservercan serve as a relay too, but the difference between a DIY relay and a professional service is reputation, which is referenced by MTAs you're delivering to such as Outlook, Gmail or others(perhaps anotherdocker-mailserverserver!), when deciding if email should be marked as junked or potentially not delivered at all. As a service like SendGrid has a reputation to maintain, relay is restricted to registered users who must authenticate(even on port 25), they do not store email, merely forward it to another MTA which could be delivered on a different port like 25.
Explicit vs Implicit TLS
Explicit TLS (aka Opportunistic TLS) - Opt-in Encryption
Communication on these ports begin in cleartext, indicating support for STARTTLS. If both client and server support STARTTLS the connection will be secured over TLS, otherwise no encryption will be used.
Support for STARTTLS is not always implemented correctly, which can lead to leaking credentials(client sending too early) prior to a TLS connection being established. Third-parties such as some ISPs have also been known to intercept the STARTTLS exchange, modifying network traffic to prevent establishing a secure connection.
Due to these security concerns, RFC 8314 (Section 4.1) encourages you to prefer Implicit TLS ports where possible.
Implicit TLS - Enforced Encryption
Communication is always encrypted, avoiding the above mentioned issues with Explicit TLS.
You may know of these ports as SMTPS, POP3S, IMAPS, which indicate the protocol in combination with a TLS connection. However, Explicit TLS ports provide the same benefit when STARTTLS is successfully negotiated; Implicit TLS better communicates the improved security to all three protocols (SMTP/POP3/IMAP over Implicit TLS).
Additionally, referring to port 465 as SMTPS would be incorrect, as it is a submissions port requiring authentication to proceed via ESMTP, whereas ESMTPS has a different meaning(STARTTLS supported). Port 25 may lack Implicit TLS, but can be configured to be more secure between trusted parties via MTA-STS, STARTTLS Policy List, DNSSEC and DANE.
Security
TODO: This section should provide any related configuration advice, and probably expand on and link to resources about DANE, DNSSEC, MTA-STS and STARTTLS Policy list, with advice on how to configure/setup these added security layers.
TODO: A related section or page on ciphers used may be useful, although less important for users to be concerned about.
TLS connections on mail servers, compared to web browsers
Unlike with HTTP where a web browser client communicates directly with the server providing a website, a secure TLS connection as discussed below is not the equivalent safety that HTTPS provides when the transit of email (receiving or sending) is sent through third-parties, as the secure connection is only between two machines, any additional machines (MTAs) between the MUA and the MDA depends on them establishing secure connections between one another successfully.
Other machines that facilitate a connection that generally aren't taken into account can exist between a client and server, such as those where your connection passes through your ISP provider are capable of compromising a cleartext connection through interception.