Summary

  • SMTP's 1982 design let a receiving server accept a message for onward relay, turning it into a sending server for the next leg.
  • RFC 2505 in 1999 made unauthorized relay a decision the MTA had to refuse: a claimed HELO name or MAIL FROM address could not grant the ride.

Imagine a taxi dispatcher who asks a passenger, “Who are you?” The passenger says, “The mayor.” The dispatcher shrugs and sends a car across the country at someone else's expense. Early Internet mail depended on couriers between systems, but by 1999 the open-relay version of that courtesy had become a splendid business arrangement for people who owned neither the car nor the fuel.

The original SMTP specification, RFC 821, from August 1982, treated relaying as an ordinary possible job. A receiving SMTP server could accept or reject a message bound for another server. If it accepted, it became a sender for the next leg. The specification also separated the mailbox address from a route through hosts. A chain of mail carriers was a functional part of connecting different places, not a mistake waiting to be corrected.

The problem was who could command that chain. RFC 2505, published in February 1999 as Best Current Practice 30, called unauthorized use of a host as a mail relay theft of its resources and a risk to its reputation. Its summary opened with a blunt instruction: stop unauthorized relaying. The mail-transfer agent needed a control that could refuse the job before it became somebody else's courier.

The RFC laid out four pieces of an SMTP conversation with unequal trust. HELO supplies a hostname claimed by the caller. MAIL FROM supplies a claimed return address. Both are easy to forge. RCPT TO names the intended recipient; the server also sees the network address of the SMTP caller. A server that let the first two strings authorize forwarding was taking a passenger's costume as a transport license.

The recommended rule moved the decision to the relay's own responsibilities. Accept mail for a recipient domain the server serves or has agreed to forward for. Accept relay work from a caller authorized by its source address or, where the operator trusts DNS, its host name. Refuse the rest. The logic is small enough to fit on a counter sign. The hard part lies in knowing which domains and callers belong on the list, and in making sure the check reads the real destination.

That last point had a nasty historical wrinkle. RFC 2505 warned that source-route forms such as @a,@b:, percent hacks and UUCP-style exclamation paths could obscure the destination tested by a simplistic rule. A server could approve what looked like local mail and then discover it had been asked to carry the message onward. Legitimate gateways also used unusual addressing, so operators were told to inventory their routing before tightening the gate. The policy had to know the roads it governed.

A second June 1999 document, RFC 2635, titled DON'T SPEW, spoke to providers as well as users. Its advice to an ISP was practical: keep mail servers from being open to strangers' forwarding, publish an acceptable-use policy, verify misuse before acting on an account, and keep abuse and postmaster contacts that someone actually reads. The relay rule lived in software; the complaint loop needed people and contracts. The Internet had discovered that a machine could be configured as a gate, while accountability still needed a staffed desk.

The later SMTP specification, RFC 5321 in 2008, records the tension that remained. Mail systems inherit a strong tradition of delivering a message or returning it, while unwanted bulk mail can make that tradition costly and exploitable. Selective rejection and dropping had become part of operational reality, but silent disappearance threatened confidence in mail delivery. The 1999 relay gate solved one authorization question; it did not repeal the obligation to make mail behavior intelligible to its users.

The change was less romantic than the old ideal of every host helping every message along. It was also more honest. A mail server could still carry legitimate traffic across networks. It simply needed to know whose mail it was authorized to carry, rather than taking a forged greeting at face value. The free taxi kept its engine. The dispatcher finally started checking who owned the fare.