Summary

  • RFC 1204 recommended returning 250 after a syntactically valid USER even when the posting server did not recognise the username. The reply intentionally prevented account enumeration; it was not proof that the account existed.
  • A later PASS 250 asserted that the supplied password had been verified against the previously presented username. DATA 354 then meant readiness for message bytes, while the post-body 250 meant local queue acceptance.
  • The same 250 also answered NOOP with a statement only about the posting server’s current internal condition. A code without its command, state and responsible component cannot identify the fact observed.

A positive answer was used to preserve an unknown

The most interesting sentence in RFC 1204 follows what appears to be a routine success reply. The February 1991 memo says that USER identifies the username of someone trying to submit mail. It lists 250 as meaning that the username has been accepted. Then it narrows that apparent success: a server should return the same reply for an unrecognised name, provided the string is syntactically correct.

The reason was explicit. A client should not be able to test whether a particular username existed in the posting server’s database. The protocol therefore preserved an unknown on purpose. From the client’s position, 250 was compatible with at least two internal states—recognised and unrecognised—and the indistinguishability was the control, not an omission in the documentation.

That design makes a useful historical correction to the habit of reading protocol replies as miniature verdicts. A positive class and the word “accepted” can sound like confirmation of the object named in the preceding command. Here, the server accepted the username as the next syntactically valid input to the state machine. It did not disclose whether the account record existed.

The RFC Editor record classifies the memo as Experimental. The current IETF Datatracker record adds an important bibliographic limit: it is a Legacy-stream document from before a formal source was recorded, is not endorsed by the IETF and has no formal standing in the present standards process. The memo is evidence of a proposed mechanism in 1991, not evidence of current recommendation or widespread deployment.

The posting server occupied a new authority boundary

RFC 1204 began with a period-specific problem. It said personal-computer operating systems did not provide a mechanism for user authentication, while a mail network needed some way to reduce sender forgery. Its answer was an agent on a mail service host: a message-posting server would authenticate a PC user and submit mail to a delivery system such as Sendmail or MMDF on that user’s behalf.

The architecture contained three actors even before a recipient entered the picture. The PC client supplied inputs. The posting server owned the local username/password check and the posting queue. A separate delivery system owned the later attempt to move the message. RFC 1204 assigned TCP port 218 to this Netix protocol and borrowed the command-and-reply style of SMTP and FTP.

That borrowing matters, but it does not make every familiar number portable across contexts. RFC 821 described SMTP as a lock-step exchange in which a sender issued commands and a receiver returned numeric replies. RFC 1204 reused DATA, the dot-terminated message body and familiar reply families. It also added its own USER and PASS meanings. The command and current state supplied the scope that the digits alone could not carry.

PASS made the assertion that USER withheld

After USER 250, the client could send PASS with the password associated with the previously supplied username. A 250 at this later step had a stronger and different meaning: RFC 1204 said the password had been accepted and verified as correctly associated with that username. A wrong association received 530; syntax, sequencing and internal failures had their own codes.

The transition is precise. USER 250 allowed the dialogue to continue without revealing recognition. PASS 250 recorded a credential comparison. The first response was deliberately non-enumerating; the second depended on a relationship between two supplied values and the server’s account material.

Even the second result had limits. The memo assigned the judgment to the posting server. It did not define legal identity, prove who was sitting at the PC, attest authorship of every byte in a later message or grant authority over every destination. A credential check is useful because its scope is bounded. Inflating it beyond that scope would erase the components that still had decisions to make.

Later SMTP work used different machinery. RFC 4954 defined a negotiated AUTH extension using SASL mechanisms and distinct success replies; it also required a configuration that rejects plaintext password mechanisms unless TLS or another protection against snooping is present. Those later requirements should not be projected backwards onto MPP. They show how authentication became a separately negotiated service surface, not that RFC 1204 supplied modern channel protection or caused the later design.

Readiness for the body was not custody of the body

A successful password exchange permitted DATA. The posting server’s 354 reply said that it was ready to accept message text. The client then sent the content and ended it with the SMTP-style dot sequence. Readiness was a change in parser state: bytes could follow under the rules for message data. It was not yet an assertion that the complete message had arrived or been stored.

Only after the terminator could the server return another 250. At this point RFC 1204 gave the code a third meaning: the message text had been successfully queued for delivery. A 451 meant that an internal error had occurred and the text had not been queued.

The queue was a real custody boundary. It was stronger than 354, because the server now claimed to hold an accepted unit for later work. But the specification immediately kept that claim upstream of delivery. The posting server should attempt to submit accepted messages to the delivery system as soon as possible. Failure in delivery, the memo said, should be handled by that delivery system; the posting server should not interfere.

Thus the post-body 250 did not collapse the rest of the mail path. It said nothing about a later relay accepting the message, a mailbox storing it, a user agent exposing it, a person reading it or an institution acting on it. Those events belonged to other components and later observations.

NOOP 250 meant something narrower again

RFC 1204 used the same code once more. NOOP performed no posting action. In reply, 250 meant that the message-posting server had not encountered an internal error during the current session. It did not inspect a recipient mailbox or certify the delivery system.

Now the danger of code-only telemetry becomes visible. Four records that all say 250 may describe:

  • a username string allowed to proceed while account recognition remains hidden;
  • a password verified against the supplied username;
  • a completed message accepted into a local queue; or
  • a posting server that reports no current internal session error.

Normalising all four as success=true destroys information. The useful record needs the protocol, connection, command, reply, state before the command, state after it, component that emitted the reply and the object to which the reply applies. Without that provenance, an operator cannot tell privacy-preserving ambiguity from authentication, queue custody from health, or local health from delivery.

Later submission standards kept the roles visible

RFC 6409 later formalised message submission on port 587. It defined a Message Submission Agent as a process that accepts a message from a user agent and either delivers it or relays it to a Message Transfer Agent. It also explained why submission and relay can carry different policy and security rules.

That later architecture is useful context, not a genealogy claim. RFC 1204’s experimental posting server and RFC 6409’s MSA are not interchangeable records. What persists is the operational reason to name the boundary. A component that accepts a user’s submission has different knowledge and authority from a component that transfers mail onward. Its positive reply can be correct and still leave delivery open.

RFC 1204 is therefore valuable less as a forgotten port than as a lesson in deliberate semantics. The protocol did not accidentally fail to answer whether the user existed; it refused to leak that answer at USER. It did not use one success code to mean one universal fact; it made the command sequence carry the distinctions. And it did not let a local queue speak for the delivery system beyond it.

Sources