RTFM · Networking

MailDragon ports and their purpose

Mail uses several TCP ports because server-to-server delivery, authenticated submission, and mailbox access are different jobs. Open only the listeners your MailDragon configuration actually provides.

The port map is a design decision

Common MailDragon-facing ports
Port	Protocol role	Who should use it
25/TCP	SMTP server-to-server transfer	Other mail servers delivering mail to your domain.
465/TCP	Message submission with implicit TLS	Mail clients using this explicit submission method.
587/TCP	Message submission, normally upgraded with STARTTLS	Mail clients sending authenticated mail.
143/TCP	IMAP with optional STARTTLS	Only if deliberately offered.
993/TCP	IMAP with implicit TLS	Normal secure IMAP mailbox access.
110/TCP and 995/TCP	POP3 and POP3 with implicit TLS	Only for a real POP3 requirement.

Port 25 is not a mail-client submission port. It is the public SMTP service used by other mail systems. Port 587 is usually the safer client submission choice because it is explicitly for authenticated users. IMAP retrieves and synchronises mailboxes; it does not send mail to other domains.

Do not open a listener just because it appears in this table. MailDragon may intentionally not enable it. First inspect the live Postfix and Dovecot configuration and ss output, then make matching router, firewall, and proxy rules.

Build the exposure path from the inside out

1. Prove MailDragon listens
Run ss -lntp on the MailDragon host. Record which daemon owns each expected port and whether it binds the correct IPv4 and IPv6 addresses.
2. Permit the port on the host
Add the selected TCP ports to nftables only on the intended public or proxy-facing interface. A private backend should normally accept those ports only from HAProxy or the relevant server network.
3. Deliver traffic to the edge
On a router, forward only the selected TCP ports. On a VPS, configure the provider firewall if present. With HAProxy, publish the ports at HAProxy and keep the backend private.
4. Publish names and identity
MX and A/AAAA records identify the receiving hostname; reverse DNS identifies the actual sending address. Test them independently.

Listener and TLS proof

# On the MailDragon host or HAProxy edge.
ss -lntp

# Check a small chosen set only.
ss -lntp '( sport = :25 or sport = :465 or sport = :587 or sport = :993 )'

# From an independent test host.
openssl s_client -connect mail.example.test:465 -servername mail.example.test
openssl s_client -starttls smtp -connect mail.example.test:587 -servername mail.example.test
openssl s_client -connect mail.example.test:993 -servername mail.example.test

Common problems have different causes

TCP 25 is unavailable from the Internet: check provider or ISP policy before rewriting MailDragon. Some home and tunnel providers filter it deliberately.
Submission works on 465 but not 587: compare the Postfix listener and STARTTLS configuration; these are different TLS styles, not interchangeable port labels.
IMAPS 993 reaches the host but the certificate is wrong: inspect the Dovecot/MailDragon TLS identity or the proxy design. A public web certificate does not automatically configure mail services.
A proxy has a listener but users cannot authenticate: first prove the backend TCP connection, then inspect the MailDragon logs and authentication configuration. A TCP health check cannot prove a mailbox login.