Summary

  • RFC 1846 in September 1995 described specialized Internet hosts that never accepted mail. With no SMTP listener, a sender could treat an attempted connection as a temporary failure, hold the misaddressed message and retry for days. Its experimental 521 reply let an MX relay or a small rejecting server deliver a permanent answer sooner.
  • The proposal found an interoperability trap: some existing clients requeued after a server sent 521 and closed immediately, but returned the mail when it stayed open for QUIT. RFC 7504 in 2015 formally added 521 for a host that never receives mail and 556 for an intermediary that knows a destination domain accepts no mail.

A silent host gave the sender more work

Internet mail was built to keep trying when a destination looked temporarily unavailable. That patience is useful when a mail server is down for an afternoon. It is absurd when there was never a mail server to begin with. In September 1995, Alain Durand and Francis Dupont pointed to a growing class of specialized hosts: machines doing jobs such as DNS or NTP, not receiving email. People would occasionally address mail to them anyway. A sending SMTP client that found no server could not infer from silence that this host would never receive mail. It queued the message in case a mail server appeared later. The RFC said the resulting wait could last days and end in an unhelpful error.

The cost was paid in a different place from the mistake. The owner of the non-mail host had no inbox to empty. Sending systems consumed queue space and repeated delivery attempts. The person who had typed the address waited for a reply that could not arrive. The recipient address looked syntactically plausible; the fact that its machine did not offer mail service was missing from the conversation. An unanswered connection said only that no one answered then. It did not say whether anyone would answer tomorrow.

The 1982 SMTP model was a conversation: one system opened a channel to another, sent commands and acted on replies. Reply codes were a way for the receiving side to settle what the sending side should do next. Durand and Dupont did not propose adding a mailbox to every specialized host. They wanted the host, or a relay speaking for it, to send one reliable answer: this destination does not take mail. Their experimental RFC 1846 gave that answer the number 521.

There were two possible places to deliver it. An MX relay could accept the conversation and reject a message addressed to the mailless host when the recipient was named. Or the host itself could operate a very small SMTP server whose job was to reject every mail attempt. The first arrangement delegated the refusal to an existing mail intermediary. The second put the refusal at the host that owned the decision. Either way, somebody had to take responsibility for saying “never” instead of leaving senders to interpret a blank connection.

The relay option had its own consistency rule. RFC 1846 said that if a relay at one MX preference level rejected mail on behalf of the mailless host, other lower-preference relays should do the same. Otherwise a sender could hear “never” from one route and try another route that had not learned the policy. The protocol supplied a reply number; an operator still had to make every relevant entrance agree on the policy behind it.

Saying no was not quite enough

The minimal server had a catch. RFC 1846 allowed it to send a 521 greeting as soon as a client connected, followed by the host name or IP address. After that, it could close the connection or stay open and reply 521 to commands other than QUIT. The RFC required a host sending that greeting not to appear as an MX destination for any domain. A machine announcing it never receives mail should not also be advertised as a mail receiver.

The detail that turns the proposal into a history of working software is what happened after the greeting. Durand and Dupont reported that some existing SMTP clients treated an immediate close after 521 as a transient failure and put the message back in the queue. If the little server kept the connection open, those clients issued QUIT and returned the mail. The rejection was identical in meaning. The sequence of bytes around it changed whether the sender believed it. A protocol designer could write a permanent refusal; deployed clients still determined whether it actually ended the retries.

This is why a tiny service was operationally different from no service at all. The tiny server had to remain reachable, pronounce the right host identity and keep the exchange alive for long enough that old clients accepted the verdict. The DNS or time machine did not gain a mailbox. It gained a way to stop other people's mail systems from treating its silence as an invitation to come back.

It was an experiment, not a 1995 Internet standard. RFC 1846 asked implementers to report experience. The document's description of “some existing” clients gives an interoperability observation, not a count of affected systems. Its claims establish the failure mode and proposed repair. They do not tell us how many messages waited in queues or what share of operators deployed 521 that year. To measure either would require period mail logs or an implementation survey.

Twenty years later, the refusal got a narrower job

In June 2015, the IETF incorporated 521 into Standards Track SMTP. The newer RFC said the code had become widely used, but had not previously been formally included in the base protocol. It reserved 521 at connection opening for a host that does not accept mail under any circumstances. That is sharper than a general refusal. A server can reject a particular sender or recipient for many reasons; 521 describes the host's permanent absence from mail service. The new text distinguished it from the broader 554 reply and ended the experiment begun in 1995.

By then, a different form of “no mail here” could be said before contacting the destination host. RFC 7505 documented null MX, a DNS record by which a domain announces that it accepts no mail. Without such a signal, a mail client can look for MX records and, failing to find them, fall back to an A or AAAA address even when that address belongs to a web or other non-mail host. Null MX turns absence into an explicit domain-level declaration. It does not require a dummy server to answer a connection.

RFC 7504 also introduced 556. It gave an intermediate mail system a reply when it knew, from information such as null MX, that a domain in a forwarding address did not receive mail, without first attempting to connect to the target host. The two codes sit at different boundaries. A host says 521 when the connection opens at a machine that never takes mail. An intermediary says 556 when it knows the domain cannot take mail before it opens that connection. The outcome for the mistaken sender should be prompt failure in both cases; the speaker and the source of knowledge differ.

The paradox of 1995 had an answer: sometimes the cheapest way to stop a queue was to run a service whose only job was to refuse service. The later standards offered a second answer in DNS, where a domain could declare the policy without that server. In both eras, the decisive improvement was a clear statement from an authority that knew the destination. Silence made every sender keep guessing. A small, well-placed “no” let the rest of the network get on with its day.