Open mail relay: your server, the internet's spam cannon

02 Technical BreakdownFor engineers

An SMTP conversation is simple: the client says who the mail is from (MAIL FROM), who it's for (RCPT TO), and then sends the content (DATA). When the recipient belongs to a domain the server doesn't own and the server agrees to forward the message anyway, that's relaying. Deciding *who is allowed to relay* is the entire game, and an open relay is simply a server whose answer is "everyone".

On Exchange Server, anonymous relaying only exists when a Receive connector grants the ms-Exch-SMTP-Accept-Any-Recipient extended right to NT AUTHORITY\ANONYMOUS LOGON (or the connector uses ExternalAuthoritative, which hands the same right to MS Exchange\Externally Secured Servers and treats all incoming mail as internal). The classic self-own, and it comes up on r/sysadmin depressingly often: an admin adds that right to the Default Frontend connector, whose RemoteIPRanges is 0.0.0.0-255.255.255.255, because some website or app needs to send mail. Connector matching is most-specific-IP-wins, so a connector scoped to one app's IP is safe; the same permission on a connector that matches the whole internet is a global relay.

On Postfix, the default is safe: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination. The trouble lives in mynetworks: set it to your whole /16 and you're trusting the neighbourhood; set mynetworks_style = class and Postfix trusts your provider's entire network (the docs literally say "Don't do this"). The sneakier failure is anything that makes remote traffic look local. Admins on reddit have been bitten by iptables masquerading, where all port-25 traffic appears to come from the firewall, which sits inside mynetworks, and by SSH port-forwarding, where everything arrives from 127.0.0.1. One poor soul only noticed when he found roughly 57,000 spam messages sitting in his outbound queue. There's also the pre-2.10 footgun: a PERMIT rule placed before reject_unauth_destination inside smtpd_recipient_restrictions makes you an open relay for those hosts. Exim and Sendmail have their own equivalents: Exim defaults to closed (relay_from_hosts = 127.0.0.1, empty relay_to_domains), and Sendmail has denied relaying since 8.9, unless someone enables promiscuous_relay. Yes, that's a real feature name.

How fast does abuse arrive? Frighteningly fast, and this has been true for two decades: a 2004 expert report to the FTC documented bulk-mail tools that search for open relays automatically, mailing lists of verified working relays sold as subscriptions, and honeypot relays found and used by spammers within days of going live. The economics are grim too, one message with 50 BCC recipients makes your server deliver 50 copies, so the spammer's slow connection becomes your fast one. And the fallout mechanics: Spamhaus's Exploits Blocklist lists IPs doing exactly this, receivers query the combined ZEN list at connection time and reject your mail outright, and after you fix the cause, manual delisting reviews take a day or three, with Gmail and Microsoft throttling you for a few more while their internal reputation recovers. Requesting removal before fixing the root cause tends to get the listing extended, so the order is strict: fix first, delist second.

The historical irony, because it's worth savouring: open relaying was the default until the mid-nineties, then in 1997 the MAPS Real-time Blackhole List started naming and shaming relays, and over the following years the share of open relays among mail senders fell from over 90% to under 1%. The internet solved this problem a quarter of a century ago. What's left is accidents: a permission added to make an app work, a NAT rule nobody re-read, a "temporary" config from 2011.

One last distinction, because it matters for the test results: a server that accepts mail from a forged *internal* sender to an internal recipient, from outside, without authentication, is not strictly an open relay (that mail is inbound), but phishers love it, because the mail arrives looking like it came from the CEO. That's mail spoofing, a related but different problem with a completely different fix, and it's exactly what the next post covers.