Summary

  • Early SMTP made VRFY and EXPN diagnostic windows into user names and mailing lists; a successful answer could disclose a mailbox or every member of a list.
  • Reply 252 created a truthful third state: the server would not verify the user, yet could accept a message and attempt delivery. It separated directory disclosure from transport intent without pretending that either was a final delivery result.

When a mail server answered like a directory

RFC 821 gave operators a wonderfully concrete debugging exchange. Send VRFY Smith. A matching server might answer 250 with Fred Smith’s full name and mailbox. If it knew that Smith had moved, it could return a forwarding address. If the string matched nobody, it could say so. If two Smiths made the request ambiguous, it had to return 553 User ambiguous.

The companion command, EXPN, went further. Give it the name of a mailing list and a successful multiline response could enumerate the mailboxes on that list, one per line. The specification was explicit: a positive VRFY answer had to contain the mailbox; a positive EXPN answer had to give the list’s mailboxes. These were not vague hints. They converted local directory state into protocol evidence a remote client could use.

That evidence had real value. A misspelled name could be found before a message was sent. A forwarding rule could be discovered. A list loop could be traced through multiple levels of expansion. SMTP’s early designers put the diagnostic beside the transport because both depended on the same delivery knowledge.

They also placed the disclosure surface on the same public listener.

The useful answer became the exploitable answer

RFC 1123 strengthened the diagnostic expectation in 1989. It required a receiving SMTP implementation to support VRFY, recommended EXPN, and still permitted installations to disable either command or selected lists. Its discussion captured the tension without resolving it by slogan: administrators regularly used the commands to diagnose delivery, but list expansion could be a significant privacy and security exposure.

Once unsolicited bulk mail became an operating fact, the same interface acquired a different customer. VRFY let a remote requester test names. EXPN could turn one known list identifier into many addresses. RFC 2505 therefore recommended that mail transfer agents control who could issue the commands through an on/off setting or access lists. It proposed 252 as the default response when VRFY was off or blocked and recommended that EXPN be off by default.

This was not the discovery of a bad command. It was recognition that diagnostic authority depends on who is asking. An internal operator auditing routing and an anonymous address harvester may send the identical octets; the legitimate scope comes from authentication and administrative relationship, not from command syntax.

The honest third answer

Binary answers would have created a protocol trap. A server that returned 250 after checking only that an address looked syntactically plausible would manufacture verification it had not performed. A server that always returned 550 would manufacture non-existence. RFC 5321 rejects both behaviours as nonconforming.

Reply 252 provides the escape: “Cannot VRFY user, but will accept message and attempt delivery.” It does not say that the mailbox exists. It does not say that a future RCPT TO command must be accepted in every context. It certainly does not say that the message reached a person. It says only that the server cannot or will not make the requested directory assertion while leaving open the ordinary delivery procedure.

The distinction is especially important for an MX server acting for another domain. It may know that the syntax is acceptable and that the destination falls within a domain it handles, yet lack a real-time view of the final mailbox database. 252 preserves that uncertainty instead of forcing an incorrect yes or no.

Security policy uses the same semantic tool. RFC 5321 says that when a site disables the commands for security reasons, it must return 252 rather than a code that could be confused with successful or unsuccessful verification. Refusal to disclose is not evidence that the user is absent.

Acceptance, verification and delivery are different records

The history of 252 matters because email systems repeatedly collapse adjacent states. Syntax validity becomes “verified address.” A 250 at one SMTP hop becomes “delivered.” A blocked lookup becomes “mailbox does not exist.” Each shortcut enlarges the authority of a partial observation.

SMTP needs at least three separate records. Directory verification says that the server actually established an address or expansion. Transaction acceptance says that a server took responsibility at a particular step. Final delivery evidence concerns the outcome after later routing, queueing, forwarding and recipient processing. 252 occupies a deliberately narrow interval before those outcomes.

This is why a monitoring system should not rewrite 252 into either a green verification check or a hard invalid-address flag. The correct state is explicit uncertainty with an available transport path. A later message transaction may add evidence; the lookup response cannot anticipate it.

Closing one window may leave another open

Disabling VRFY does not erase all recipient evidence. RFC 5321 notes that some servers reveal comparable information through RCPT responses. Others defer recipient validation until after message data is received, so RCPT may reveal almost nothing. The marginal security of hiding VRFY therefore depends on the entire acceptance pipeline.

This limits triumphal claims. A command-level policy can reduce cheap, direct directory queries. It cannot guarantee that timing, reply-code differences, catch-all domains, bounce behaviour or downstream delivery reports disclose nothing. Operators must inspect the composite surface rather than award themselves privacy because one verb returns 252.

The same caution runs in the opposite direction. A server should not expose EXPN publicly merely because determined harvesters have other methods. Reducing the cheapest and most authoritative enumeration path still changes cost and confidence. Security is often the control of evidence quality and query price, not the achievement of perfect secrecy.

Diagnostics survived behind a boundary

RFC 5321 retains a case for both commands. Authenticated users and administrators inside a domain can use them to audit mail routing, find inadvertent forwarding and understand list behaviour. An organisation may make the commands available only to authenticated requesters. The function survives; the anonymous entitlement does not.

That is a more precise outcome than universal disablement. The server keeps the capacity to answer. Policy decides when the requester’s identity and scope justify disclosure. A list owner might inspect one list without gaining a catalogue of every list. A mail administrator might verify internal routing from a management network without offering the same view to the Internet.

The current IANA SMTP registry preserves the distinction at the service boundary. It records server implementation support for VRFY as required while its appearance in the EHLO extension list is optional. It also marks both VRFY and EXPN as MUST NOT for Message Submission use. A user authenticated to submit outgoing mail is not automatically entitled to query the receiving system’s directory.

SMTP learned not to answer one question by lying or becoming mute. It learned to answer a smaller question truthfully. The server could decline to certify a person, preserve the possibility of accepting mail, and reserve richer diagnostics for a relationship that justified them. In a protocol built from replies, 252 became a boundary around what the reply was allowed to know.

Sources