Summary

  • RFC 772 and RFC 780 offered two MTP multi-recipient choreographies: R retained recipients first, while T retained the text first. The receiver controlled which usable scheme governed the exchange.
  • MRSQ discovered, selected and reset the scheme; MRCP named a recipient, but its evidence meant something different under R and T. Order allocated memory, responsibility and the scope of failure.
  • RFC 788 and RFC 821 replaced that negotiation with one visible order: MAIL, repeated RCPT, then DATA. One body could still serve many recipients; the protocol discarded alternate wire grammars, not multi-recipient efficiency.

The question that erased its own context

In RFC 780, MRSQ is simultaneously a capability probe, a preference query, a selection command and a reset. With no argument, it selects no scheme and returns the exchange to its neutral state. With ?, it asks which scheme the receiver prefers. With R or T, it proposes one of the two procedures.

The query is not observationally harmless. Every MRSQ use resets the associated multi-recipient state. A sender that asks the receiver’s preference in the middle of an exchange can discard an accumulated recipient list or a stored message body. A diagnostic system that treats MRSQ ? as a read-only inspection therefore changes the transaction it is attempting to inspect.

A supporting receiver answers the preference query with a 215 reply naming a scheme. It must implement at least one of R or T, but it need not honor the sender’s first choice. The sender can suggest; the receiver decides what it can actually use.

That authority follows the location of the relevant knowledge. Only the receiver knows whether its local mailer wants a complete recipient batch, whether it delivers one address at a time, how many paths fit in its table, and whether retaining the body is cheaper than retaining a list. MRSQ exposed that local implementation decision directly in the protocol conversation.

R built the list before accepting the body

Under the recipients-first scheme, the sender issues a series of MRCP TO:<path> commands. The receiver answers each one and remembers the paths it accepts. Rejection of one address does not invalidate addresses already retained, nor does it prevent later addresses from being considered, except where resource exhaustion prevents the receiver from storing more state.

When the list is ready, the sender uses MAIL FROM:<sender-path> without a TO argument and transfers the message body once. A positive completion after the body applies to every remembered recipient; a failure at that point is treated as failure for the whole remembered group. The receiver then flushes the list.

R fits an implementation that hands one combined envelope and body to a central mailer. It assembles the delivery work before the expensive data transfer and avoids sending identical text separately for each address.

Its economy is bounded by memory. RFC 780 describes a 452 response when the recipient table has no room for another path. The sender can transmit the body to the group already stored, collect another group, and transmit the body again. Fifty recipients and space for ten names may require five batches. “One copy” is therefore not a metaphysical property of the message; it is an outcome constrained by the receiver’s available state.

Nor is R an atomic-delivery promise. Each MRCP reply says whether a path can enter the pending group. The later MAIL completion reports the group outcome after the shared body arrived. Those are different checkpoints. Calling the first acceptance final delivery would erase the very distinction the procedure creates.

T accepted the body before learning the list

Text-first reverses the retained object. A MAIL FROM:<sender-path> without a recipient transfers and stores the message body. Subsequent MRCP commands apply that stored body to recipient paths one by one, returning a result for each without retransmitting the text.

The body remains available until another MAIL replaces it or an MRSQ resets the scheme state. T therefore saves bandwidth too. It does not stream the body again for each recipient; it holds the larger object once and reuses it as addresses arrive.

This arrangement suits a receiver that performs delivery incrementally. A mailbox allocation problem, an access conflict or another local condition can be reflected in the reply for the affected recipient at the time the receiver tries to apply the stored message.

The reversal creates its own exposure. When the receiver accepts the body, it does not yet know whether any valid recipient will follow. An MRCP before a body has been stored becomes, in the RFC’s terms, an attempt involving a null message, and implementations may accept or reject it. Sequence is not presentation around the command; sequence determines what object exists.

The same successful number did not prove the same event

Under R, a successful MRCP chiefly proves that a recipient path has been recorded for a later collective operation. Under T, the body already exists, so a successful MRCP reports the application of that body to one named path. A log line containing only the command and reply can be insufficient evidence unless the active scheme and previous reset points are known.

The problem becomes sharper across incomplete traces. MRSQ destroys prior scheme state. A new MAIL can replace retained text. If a capture omits one of those boundaries, an analyst may attach an MRCP to a body that no longer exists or to a recipient table already flushed.

Negotiable order consequently expands the shared state machine. There are two possible retained objects, two meanings for a recipient acknowledgement, multiple reset transitions and different scopes for the final failure. The flexibility is locally sensible, but every sender, receiver, relay, tester and trace reader must understand both stories.

The receiver knew the shape of its own workshop

RFC 772 and RFC 780 do not present R as correct and T as defective, or the reverse. R is natural for a system that hands a completed recipient set and one body to a central process. T is natural for a system that works through recipients incrementally and wants to expose local delivery constraints separately.

The sender cannot see the size of the remote table, the architecture behind the listening process or the moment at which mailbox resources are committed. Giving the sender final authority would make the less-informed party choose the receiver’s internal workload. The protocol therefore lets the sender express a preference while leaving effective control with the receiver.

That distribution is rational connection by connection. Across a network, however, it requires every implementation to carry the complexity of both possible external orders. A decision can be well informed locally and still be expensive as part of a universal interface.

SMTP fixed the visible order

RFC 788, published in November 1981, defines a single transaction sequence. MAIL FROM identifies the sender and opens the transaction. One or more RCPT TO commands negotiate recipients. DATA finally transfers the text. The dialogue is explicitly lock-step, and the transaction commands are required in that order.

MRSQ and mail’s MRCP disappear from this grammar. A receiver can no longer demand the text before any recipient is named. A rejected RCPT still need not invalidate the transaction for other recipients, so SMTP retains recipient-specific envelope decisions before the shared data phase.

RFC 821 preserves the same structure in 1982. It also encourages sending one copy of the data for multiple recipients at the same destination host. SMTP did not abandon the efficiency problem that R and T addressed. It standardized one external method for solving it: establish the envelope with repeated RCPT commands, then send DATA once.

This distinction matters because simplification is easily mistaken for lost capability. The removed feature was not “mail one body to several people.” The removed feature was the receiver’s ability to choose whether that body appeared on the wire before or after the recipient sequence.

One grammar, many internal implementations

Fixing the wire order does not dictate how a server must organize its internals. An SMTP receiver may still buffer a recipient set, stream data into temporary storage, pass work to a central queue, or defer local delivery. The standard constrains what peers observe, not every data structure behind the endpoint.

That separation moves adaptation inward. Under MTP’s negotiated schemes, the client and receiver coordinated over the receiver’s preferred storage order. Under SMTP, the receiver absorbs the difference between a uniform dialogue and its local architecture. The peer gains a smaller state space; the receiver retains implementation freedom behind the contract.

This is a recurring protocol bargain. External variety can make local optimization explicit, yet it charges every participant for branches it may rarely use. A fixed sequence may force an endpoint to buffer or reorder internally, but it lowers the number of interoperation paths that the network must test and preserve.

Lock-step is not the same question as order

RFC 788 calls the exchange lock-step: the sender waits for a reply before proceeding. That waiting discipline is distinct from whether MAIL, recipients and text can be logically reordered. Later SMTP mechanisms may reduce waiting or permit several commands to be sent before their replies return, but they do not restore a receiver-selected text-first transaction.

RFC 5321 still describes a mail transaction as MAIL, one or more RCPT commands, and DATA. Parameters and extensions can enrich those stages. They do not revive MRSQ’s choice between retaining addresses first and retaining the body first.

Confusing the two dimensions produces bad historical comparisons. Pipelining concerns when commands may be transmitted relative to replies. MRSQ concerned which logical object came first and which state the receiver owned. Faster waiting does not imply negotiable choreography.

The efficiency rule survived the command names

RFC 1123 strongly urges senders to issue multiple RCPT commands followed by one DATA when several recipients are handled by the same host. Repeating RCPT and DATA for each recipient wastes transmission and processing.

That operational advice reveals continuity beneath the syntax break. Early MTP treated R and T as two ways to avoid repeating a body. SMTP retained the shared-body objective but chose recipients-first as the common visible sequence. The network standardized the interface while preserving the result that mattered.

The history is therefore not a clean contest between an inefficient predecessor and an efficient successor. It is a narrowing of where the choice could be expressed. Receivers lost authority over the public ordering; implementations kept authority over their local buffering and delivery machinery.

MRCP has a narrow historical meaning here

In these mail documents, MRCP means “Mail Recipient.” It belongs to the early Mail Transfer Protocol command set. The same letters were later used for Media Resource Control Protocol, an unrelated technology.

That acronym collision is not merely a search inconvenience. A modern query can rank the later protocol so heavily that an early mail trace appears nonsensical or is silently relabeled. Dates, surrounding commands and source documents are part of the identity of a protocol token.

The same caution applies to deployment claims. The RFCs define behavior and explain implementation tradeoffs; they do not supply a census of how often R or T was used, a single decisive meeting at which the choice was abolished, or a measured performance gain caused by removal. The documentary record supports a change in specification, not invented adoption statistics.

A protocol can preserve the goal while deleting the option

MRSQ made a receiver’s private architecture visible as a negotiation over order. R asked the receiver to remember names; T asked it to remember text. Each made different evidence available at different moments, and each placed a different resource at risk.

SMTP’s fixed MAIL–RCPT–DATA sequence did not declare those internal architectures illegitimate. It stopped requiring remote peers to participate in choosing between them. The receiver could still build the workshop it needed, but the loading dock acquired one schedule.

This is the deeper transition. Protocol evolution often keeps an old objective while removing the mechanism that once exposed it. The objective here was one-body efficiency for multiple recipients. The exposed mechanism was receiver-selected ordering. SMTP retained the former and standardized away the latter.

Sources