RFC 772
Mail Transfer Protocol
RFC 772: MAIL TRANSFER PROTOCOL 💌
okay so this one is from Network Working Group 🫶 and it's written by S. Sluizer and J. Postel at ISI, dated September 1980. nothing in the original says what it obsoletes or updates, so that's a blank 🙈
PREFACE 🎀
this is a first draft of this protocol and comments are very definitely requested 💖
INTRODUCTION ✨
the objective of Mail Transfer Protocol (MTP) is to transfer mail reliably and efficiently 💌
this paper assumes you already know the protocols in the ARPA Internet Protocol Handbook. ngl the reader will notice strong similarities to parts of the File Transfer Protocol, and that's because ARPANET first set up computer mail as a feature of FTP 🧚 iykyk
- The ARPANET Host-to-Host Protocol [Network Control Protocol] (NCP)
- The Transmission Control Protocol (TCP)
- The TELNET Protocol (TELNET)
- The File Transfer Protocol (FTP)
DISCUSSION 🦋
this section is where we get the terminology and the MTP model. only the terms with special meaning in MTP get defined here. some of them are super specific to the MTP model, so if you're confused, you can jump to the model section and come back 💅
TERMINOLOGY 💅
ASCII
the ASCII character set as defined in the ARPA Internet Protocol Handbook. in MTP, ASCII characters are the lower half of an eight-bit code set (i.e., the most significant bit is zero), and it's called NVT-ASCII 🌸
control connection
the TCP full-duplex communication path, or two NCP simplex communication paths, between a sender-MTP and a receiver-MTP. it carries commands, replies, and mail text. the control connection runs according to the TELNET Protocol 🔥
data mode
the mail is sent over the control connection as a stream of octets. (in FTP terms this is called stream mode 🌈)
data structure
the inside structure of mail is treated as one continuous sequence of data octets. (in FTP terms this is called file-structure 💜)
data representation
all the internal data (aka the mail) is in NVT-ASCII 🍓
host
a computer in the internetwork where mailboxes live 🏠
MTP commands
a set of commands that make up the control info going from the sender-MTP to the receiver-MTP 📮
an ordered set of computer data of arbitrary length, following the standard in RFC 733 (Standard for the Format of ARPA Network Text Messages) 💌
mailbox
a character string (address) that identifies a user you want to send mail to. a mailbox usually has host and user parts. the standard naming convention is "user@host". it's also the "container" where mail is stored 📬
NVT
the Network Virtual Terminal, as defined in the TELNET Protocol 🖥️
octet
bytes in MTP are octets (8 bits). this isn't necessarily the same byte size that a host uses to store data 🫧
reply
a reply is an acknowledgment (positive or negative) that goes from receiver to sender over the control connection, in response to an MTP command. a reply has a completion code (error codes included) followed by a text string. the codes are for programs, and the text is usually for humans 💬
receiver-MTP process
a process that moves mail together with a sender-MTP process. it "listens" on its port/socket L for a connection from a sender-MTP, then sets up a control connection using the TELNET Protocol. it takes MTP commands from the sender-MTP, sends replies, and manages the mail transfer 👑
sender-MTP process
a process that moves mail together with a receiver-MTP process. a local language can be used in the user interface command/reply dialogue. the sender-MTP starts the control connection from its port/socket U to the receiver-MTP process. it starts MTP commands, gets replies, and manages the mail transfer ✨
user
a human (or a process acting for a human) who wants mail transfer service. also, a recipient of computer mail 🙋♀️
THE MTP MODEL 🧚
with all those definitions in mind, here's the model for an MTP service (Figure 1) 👀
------------ ------------
| | | | --------
| | MTP | |<-->| User |
| Receiver-|Commands/Replies| Sender- | --------
-------- | MTP |<-------------->| MTP | --------
| Mail |<-->| | Mail | |<-->| Mail |
|System| | | | | |System|
-------- ------------ ------------ --------
Receiver-MTP Sender-MTP
Model for MTP Use
Figure 1in the model from Figure 1, the sender-MTP starts the TCP/NCP control connection, which follows the TELNET Protocol. when the user starts things, the sender-MTP generates standard MTP commands and sends them to the receiver-MTP over the control connection. the receiver-MTP sends standard replies back to the sender-MTP over that same connection, in response to the commands. on top of that, mail gets sent over the control connection too 💖
MAIL TRANSFER FUNCTIONS 🌈
the control connection handles three jobs: the commands that say what to do, the replies to those commands, and the actual mail transfer. mail only moves through the control connection, periodt 💅
the channel from the sender-MTP to the receiver-MTP is set up by a TCP/NCP control connection from the sender to a standard receiver port/socket. the sender-MTP is in charge of sending MTP commands, reading the replies it gets, and sending the mail. the receiver-MTP reads the commands, sends replies, and receives the mail 🫶
MAIL REPRESENTATION AND STORAGE 💜
mail goes from a storage device on the sending host to a storage device on the receiving host. sometimes the mail needs transforming, because the two systems store data differently. for example, NVT-ASCII gets stored differently on different systems. PDP-10s usually store NVT-ASCII as five 7-bit ASCII characters, left-justified in a 36-bit word. 360s store NVT-ASCII as four 8-bit EBCDIC codes in a 32-bit word. Multics stores NVT-ASCII as four 9-bit characters in a 36-bit word 🖥️
to keep things simple, all data must be represented in MTP as NVT-ASCII 🍓. that means characters have to be converted to the standard NVT-ASCII form when text is sent, even when the sending and receiving hosts are pretty different. the sender turns its internal character representation into the standard 8-bit NVT-ASCII representation (check the TELNET specification). the receiver then turns the standard form back into its own internal form. following this standard, the <CRLF> sequence should be used to mark the end of a line of text ✨
the mail in MTP has no internal structure. it's just one continuous sequence of data octets 🫧
ERROR RECOVERY AND RESTART 💀
heads up: there's no provision for catching bits that get lost or scrambled during data transfer. that level of error control is handled by the TCP/NCP 🙈
there's also no restart procedure to protect senders from big system failures. that includes a host failing, an MTP process failing, or the underlying network failing 😭
MTP COMMANDS ✨
COMMAND SEMANTICS
okay so the MTP commands are how you ask for a mail transfer or mail system function 📬. The syntax of mailboxes MUST conform to receiver site conventions (with standard defaults applicable), bc every site has its own rules 💅. When there's an MTP transfer command, the mail SHALL always be transferred over the control connection, no exceptions 🫶.
MTP follows the TELNET Protocol specs for all communication over the control connection 🧚. The TELNET language can be a negotiated option, but the "TELNET language" and the matching "TELNET end of line code" are REQUIRED to be NVT-ASCII and <CRLF> respectively 🌸. No other TELNET specs get cited, so we're not going down that rabbit hole 🙈.
MTP commands are NVT-ASCII strings ending in <CRLF> 💜. The command codes are alphabetic characters, followed by <SP> (space) if parameters come next, or <CRLF> if they don't 🎀.
Here's the lineup. A few of these show their possible replies right in the description, and replies get their own section after this 👑.
MAIL (MAIL)
This one lets a sender-MTP send mail over the control connection 💌. The argument field has a sender and an optional path sequence. If there's a path, it's an optional list of hosts plus a destination mailbox. When the host list shows up, it's source routing info saying the mail MUST be forwarded to the first host on the list 🧭. After this command line, the receiver treats every character as mail text from the sender. The mail text ends with the sequence "CRLF.CRLF" 💅.
As the mail moves along the path, each forwarding host MUST remove itself from the list 🏃♀️. Once it reaches its ultimate destination (the path sequence only has a possibly empty destination mailbox left), the receiver drops it into that mailbox following its host mail conventions 📥. If the second argument field is blank (one or more spaces) or empty (<CRLF>), the mail is headed for a printer or another designated general delivery spot 🖨️. The mail MAY be marked as sent from the sender named in the first argument field ✉️.
MAIL RECIPIENT SCHEME QUESTION (MRSQ)
This command picks the scheme for sending mail to several users at the same host 🎯. The two schemes are listing the recipients first, or sending the mail first 💁.
MAIL RECIPIENT (MRCP)
This one identifies the individual recipients when you're sending mail for multiple users at one host 👯.
HELP (HELP)
This makes the receiver send helpful info about its implementation status over the control connection back to the receiver 🆘. The command can take an argument (like any command name) and return more specific info. The reply is type 211 or 214 🧠.
QUIT (QUIT)
This tells the receiver it MUST close the control connection 👋.
NOOP (NOOP)
This one doesn't change any parameters or previously entered commands 😌. It does nothing except make the receiver send an OK reply ✅.
COMMAND SYNTAX
The commands (plus their functions and semantics) are TELNET NVT-ASCII strings sent over the control connection 📡. The functions and semantics live in the MTP Commands section, reply sequencing is in Sequencing of Commands and Replies, and Typical MTP Scenarios has examples 📚. This section is where the syntax lives 🤓.
Each command starts with a command code and then an argument field. Command codes are four alphabetic characters. Upper and lower case get treated identically, so any of these can be the mail command:
MAIL Mail mail MaIl mAIlSame goes for parameter values, like R or r for RECIPIENT first. Command codes and argument fields are separated by one or more spaces 🪄.
The argument field is a variable length string ending with <CRLF>. It SHOULD be noted that the receiver is to take no action until it gets the end of line code 💡.
The syntax is in NVT-ASCII, and all argument field characters are ASCII. Square brackets mean optional, and if you skip an option, the appropriate default is implied 🧩.
Here are the MTP commands:
MAIL <SP> FROM:<sender> [<SP> TO:<path>] <CRLF>
MRSQ [<SP> <scheme>] <CRLF>
MRCP <SP> TO:<path> <CRLF>
HELP [<SP> <string>] <CRLF>
QUIT <CRLF>
NOOP <CRLF>The argument field syntax (BNF where it applies) is below. The "..." notation means a field can repeat one or more times 🔁.
<sender> ::= "<" <mailbox> ">"
<path> ::= "<" ["@" <host> "," ...] <mailbox> ">"
<scheme> ::= "R" | "T" | "?"
<string> ::= <char> | <char><string>
<mailbox> ::= <user> "@" <host>
<host> ::= <string>
<user> ::= <string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>CONTROL FUNCTIONS
Most time-sharing systems have ways for a terminal user to get control back from a "runaway" process 🛑. Locally, the system can see every user signal, whether it's a normal character or a special "out of band" signal 🔍. Over the network, though, the system doesn't necessarily see all user signals, because the network's flow control mechanisms MAY cause them to get buffered elsewhere, like in the user's host 😬.
To counter this, TELNET's "Synch" mechanism gets used 🔧. A Synch signal is a TCP Urgent or an NCP Interrupt notification paired with the TELNET command DATA MARK (DM) 💥. It isn't subject to the flow control on the TELNET connection, and it invokes special handling of the data stream by the process that receives it. In this mode, the data stream gets scanned right away for a TELNET Interrupt Process (IP) command. (The reason for using TELNET IP is so an existing server TELNET module can sit "under" the MTP. If this code were implemented directly in MTP, the IP command wouldn't be needed 🤷♀️.) DM is the synchronizing mark in the data stream, saying any special signal already happened and the recipient can go back to normal processing 🦋. For a deeper look, check the TELNET Protocol Specification in the Internet Protocol Handbook 📖.
The effect is to discard all characters (up to the DM) between the sender of the Synch and its recipient. So every character on the control connection gets ignored until the TELNET command DM shows up 🙈. The full sequence is below. Each vertical bar (|) is the boundary between data octets, and IAC is the TELNET command code Interpret As Command 🎀.
Old New
-+-+-+-+-+-----+---+--+---+--+-
...|M|A|I|L| ... |IAC|IP|IAC|DM|...
-+-+-+-+-+-----+---+--+---+--+-MTP REPLIES
Replies are how we keep requests and actions in sync during mail transfer, and how we make sure the sender-MTP always knows the receiver's state 🫡. Every command MUST generate at least one reply, though there can be more than one. If there are several, the multiple replies MUST be easily distinguished 👀. Some commands MUST occur sequentially, like MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL 🔗. Replies to these sequences show an intermediate state exists if all the earlier commands succeeded. If anything fails along the way, the whole sequence has to be repeated from the beginning 😭.
The details of the command-reply sequence are made explicit in the State Diagrams section 🗺️.
An MTP reply is a three digit number (sent as three alphanumeric characters) followed by some text 🔢. The number is for automata to figure out which state to enter next, and the text is for the human 🧑. The three digits are meant to hold enough encoded info that the sender-MTP won't have to look at the text, and it MAY either discard the text or pass it on to the user, as appropriate ✨. The text MAY be receiver-dependent, so you'll likely see different texts for each reply code 🌈.
Formally, a reply is: a three-digit code, a space <SP>, one line of text (where the maximum line length is 65), and a terminal <CRLF> 📏. Sometimes the text runs longer than one line, and then the complete text MUST be bracketed so the sender-MTP knows when to stop reading 🛑. That needs a special first line format to show it's a multi-line reply, plus another format on the last line to designate it. Both lines contain the same reply code, which shows the transaction state 🎀.
So the multi-line format: the first line begins with the exact reply code, immediately followed by a hyphen "-" (also known as minus), then the text. The last line begins with the same code, immediately followed by <SP>, optionally some text, and <CRLF> 💜.
For example:
123-First line
Second line
234 A line beginning with numbers
123 The last lineThe sender-MTP then just searches for the second occurrence of the same reply code followed by <SP> (space) at the beginning of a line, and ignores all the intermediary lines 👀. If an intermediary line begins with a three-digit number, the receiver MUST pad the front to avoid confusion 🫶.
So this trick lets the normal system routines handle the reply info, and we just tack on "artificial" first and last lines 💅. Super clever. Ngl, the rare case is when those routines can spit out three digits and a space at the start of a line. Then each text line should get some neutral text in front, like a space, so it doesn't look like a reply code 🎀
This scheme assumes multi-line replies may not be nested 🙅♀️ Nesting basically won't happen, except for random system messages (also called spontaneous replies) that can interrupt another reply. System messages (i.e., those not processed by the receiver-MTP) will NOT carry reply codes and can show up anywhere in the command-reply sequence. The sender-MTP can ignore them, since they're just info for the human user 🫶
The three digits of a reply each mean something specific ✨ This is what lets a sender-MTP be anywhere from super simple to super sophisticated. The first digit tells you whether the response is good, bad, or incomplete. (Referring to the state diagram) an unsophisticated sender-MTP can figure out its next move (proceed as planned, redo, retrench, etc.) just by looking at that first digit. A sender-MTP that wants to know roughly what kind of error happened (e.g., mail system error, command syntax error) can look at the second digit, and the third digit is saved for the finest-grained info 🔍
There are five values for the first digit of the reply code:
1yz Positive Preliminary reply
The requested action is starting up, so expect another reply before you send a new command. (A sender-MTP that sends another command before the completion reply would be in violation of protocol. However, receiver-MTP processes should queue any commands that arrive while a preceding command is in progress.) 🌸
2yz Positive Completion reply
The requested action finished successfully ✅ You can start a new request now 🦋
3yz Positive Intermediate reply
The command was accepted, but the requested action is on hold until more info arrives. The sender-MTP should send another command giving that info. This reply is used in command sequence groups 🧚
4yz Transient Negative Completion reply
The command was not accepted and the requested action did NOT happen. BUT the error is temporary, so the action can be requested again. The sender should go back to the start of the command sequence (if there is one) 🔁 It's kinda hard to pin down what "transient" means when two different sites (receiver- and sender- MTPs) have to agree on the interpretation 🙈 Each reply in this category might have a different time value, but the sender-MTP is encouraged to try again. A rule of thumb for telling a 4yz from a 5yz (see below): replies are 4yz if they can be repeated without changing the command form or any properties of the sender or receiver. (E.g., the command is repeated identically; the receiver does not put up a new implementation.) 💜
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did NOT happen. The sender-MTP is discouraged from repeating the exact same request (in the same sequence) 💀 Even some "permanent" errors can be fixed, though, so the human user may want to tell the sender-MTP to restart the command sequence later, by taking direct action (e.g., after the spelling has been changed, or the user has altered his/her directory status.) 🍓
The second digit sorts replies into specific categories:
x0z Syntax -- These replies refer to syntax errors,
syntactically correct commands that don't fit any
functional category, and unimplemented or superfluous
commands.
x1z Information -- These are replies to requests for
information, such as status or help.
x2z Connections -- These are replies referring to the control
connection.
x3z Unspecified as yet.
x4z Unspecified as yet.
x5z Mail system -- These replies indicate the status of the
receiver mail system vis-a-vis the requested transfer or
other mail system action.The third digit gives a finer gradation of meaning within each category the second digit sets up. The list of replies below will show you how that works. Each reply text is recommended rather than mandatory, and it may even change depending on the command it goes with. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for situations that are slightly different from the ones described here. They should adapt codes that are already defined instead 🙅♀️📜
A command like NOOP, whose successful execution doesn't give the sender-MTP any new information, returns a 200 reply ✨ The response is 502 when the command requests an unimplemented non-site-specific action. A refinement of that is the 504 reply, for a command that IS implemented but requests an unimplemented parameter 🧠
REPLY CODES BY FUNCTION GROUPS
200 Command okay
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only to
the human user]
215 <scheme> is the preferred scheme
120 <host> Service ready in nnn minutes
220 <host> Service ready for new user
221 <host> Service closing control connection
421 <host> Service not available, closing control connection
[This may be a reply to any command if the service knows it
must shut down]
151 User not local; will forward to <user>@<host>
152 User unknown; mail will be forwarded by the operator
250 Requested mail action okay, completed
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage space
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowed
354 Start mail input; end with <CR><LF>.<CR><LF>NUMERIC ORDER LIST OF REPLY CODES
120 <host> Service ready in nnn minutes
151 User not local; will forward to <user>@<host>
152 User unknown; mail will be forwarded by the operator
200 Command okay
211 System status, or system help reply
214 Help message
[Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only to
the human user]
215 <scheme> is the preferred scheme
220 <host> Service ready for new user
221 <host> Service closing control connection
250 Requested mail action okay, completed
354 Start mail input; end with <CR><LF>.<CR><LF>
421 <host> Service not available, closing control connection
[This may be a reply to any command if the service knows it
must shut down]
450 Requested mail action not taken: mailbox unavailable
[E.g., mailbox busy]
451 Requested action aborted: local error in processing
452 Requested action not taken: insufficient system storage space
500 Syntax error, command unrecognized
[This may include errors such as command line too long]
501 Syntax error in parameters or arguments
502 Command not implemented
503 Bad sequence of commands
550 Requested action not taken: mailbox unavailable
[E.g., mailbox not found, no access]
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowedDISCUSSION OF MAIL TRANSFER
The basic command for sending mail is MAIL 📬 This command causes the transmitted data to be entered into the recipient's mailbox.
MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF><sender> is a mailbox, and <path> is a source routing list of hosts and destination mailbox. If accepted, it returns a 354 reply and treats all succeeding lines as the message text. The text ends with a line containing only a period, and then a 250 completion reply comes back. Various errors are possible 😬
There are two possible preliminary replies a receiver can use to say it's accepting mail for a user whose mailbox isn't on that receiver 💌
151 User not local; will forward to <user>@<host>This reply means the receiver knows the user's mailbox is on another host, and it'll take responsibility for forwarding the mail to that host. For example, at BBN (or ISI) there are several hosts. Each one has a list of many of the users on the hosts. Each host can accept mail for any user on its list and forward it to the correct host 🗺️
152 User Unknown; mail will be forwarded by the operatorThis reply means the host doesn't recognize the user name, but it'll accept the mail and have the operator try to deliver it. This is useful if the user name is misspelled, but it can be a disservice if the mail is really undeliverable 😭
If forwarding by the operator is unacceptable, or if the user would rather send the mail directly to the recipient's actual host, the dialogue can be ended as soon as one of these preliminary responses shows up 🙅♀️
There are two MTP commands that let the text of a message go to several recipients at once, which is way more efficient than sending the text again and again for each extra recipient at a site 🚀 In one, all the recipients are specified first, and then the text is sent. In the other, the order is flipped: the text is sent first, followed by the recipients. Both schemes are needed because neither one alone is optimal for all systems, as will be explained later 🧩 To pick a particular scheme, the MRSQ command is used. To specify recipients after a scheme is chosen, MRCP commands are given. And to furnish the text, the MAIL command is used 💖
SCHEME SELECTION: MRSQ
MRSQ is the way a sender-MTP can check whether MRSQ/MRCP is implemented at all, pick a scheme, reset its state, and even do a bit of rudimentary negotiation. 🎀 Its format looks like this:
MRSQ [<SP> <scheme>] <CRLF>The <scheme> is a single character. There are three defined:
R Recipients first. If this is not implemented, T must be.
T Text first. If this is not implemented, R must be.
? Request for preference. This must always be implemented.No argument means a "selection" of none of the schemes (the default) 💜. The possible replies are:
200 OK, we'll use specified scheme
215 <scheme> This is the scheme I prefer
501 I understand MRSQ but can't use that scheme
5xx Command unrecognized or unimplementedThere are three things you need to know about MRSQ, bestie 🫶. First, an MRSQ with no argument must always return a 200 reply and restore the default state of having no scheme selected. Any other reply means MRSQ and hence MRCP are not understood or cannot be performed correctly 😭.
Second, using "?" as a <scheme> asks the MTP receiver to send back a 215 reply where it names a "preferred" scheme. The format is super simple:
215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>Any other reply (e.g., 4xx or 5xx) implies that MRSQ and MRCP are not implemented, because "?" must always be implemented if MRSQ is 💅.
Third, and this is a big one 🔥, MRSQ always has the side effect of resetting all schemes to their initial state. That reset must be done no matter what the reply turns out to be: 200, 215, or 501. The actions needed for a reset get explained when we talk about how each scheme actually works 🌸.
MESSAGE TEXT SPECIFICATION: MAIL
Regardless of which scheme (if any) has been selected, a MAIL command with a non-null "TO" argument behaves exactly as before. The MRSQ/MRCP commands have no effect on it 🦋. However, a normal MAIL command does have the same side effect as MRSQ: it "resets" the current scheme to its initial state ✨.
It's only when the "TO" argument is null (e.g., MAIL FROM:<X@Y> <CRLF>) that the chosen scheme matters 👑. Rather than producing an error (like most receivers do right now), the receiver will accept message text for this "null" specification. What it does with that text depends on which scheme is in effect, and that gets described in the section on Scheme Mechanics 🧚.
RECIPIENT SPECIFICATION: MRCP
To specify recipient names (i.e., mailboxes) and get some acknowledgment (or refusal) for each name, you use this command 💖:
MRCP <SP> TO:<path> <CRLF>The replies look like this:
Reply for no scheme:
503 No scheme specified yet; use MRSQ
Replies for scheme T are identical to those for MAIL.
Replies for scheme R (recipients first):
200 OK, name stored
452 Recipient table full, this name not stored
553 Recipient name rejected
4xx Temporary error, try this name again later
5xx Permanent error, report to senderHeads up, though: using this command is an error if no scheme has been selected yet. You need an MRSQ <scheme> to have been given before MRCP can be used 🙈.
SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST)
In the recipients-first scheme, MRCP is used to specify names, which the MTP receiver stores in a list or table 📝. Normally the reply to each MRCP will be either a 200 for acceptance or a 4xx/5xx rejection code. All 5xx codes are permanent rejections (e.g., user not known) and should be reported to the human user 😤. The 4xx codes, on the other hand, generally mean some temporary error that might get fixed later 🌈. None of the 4xx/5xx replies affect the MRCP commands before or after them, except for 452, which means no further MRCPs will succeed unless a message is sent to the already stored recipients or a reset is done 🥺.
Sending message text to the stored recipients is done with a MAIL command that has no "TO" argument, so just MAIL <SP> <sender> <CRLF> 💌. Transmitting the text works exactly the same as for a normal MAIL. But here's the twist 👀: a positive acknowledgment at the end of transmission means the message has been sent to ALL recipients remembered with MRCP, and a failure code means it should be considered to have failed for ALL of those specified recipients. This applies regardless of the actual error code. Whatever the reply signifies, all stored recipient names get flushed and forgotten. In other words, things go back to their initial state 🧹. This purging of the recipient name list must also happen as the reset side effect of any use of MRSQ.
A 452 reply to an MRCP can be handled by using MAIL to send the message to the currently stored recipients, and then sending more MRCPs and another MAIL, as many times as necessary. For example, if a receiver only had room for 10 names, a 50-recipient message would get sent 5 times, to 10 different recipients each time 🍓.
If a sender tries to specify message text (a MAIL with no "TO" argument) before any successful MRCPs have been given, it should be treated exactly like a "normal" MAIL with a null recipient would be. Some receivers return an error, such as 550 Null recipient 💀.
See the example in Appendix A for a mail transfer using MRSQ R 📚.
SCHEME MECHANICS: MRSQ T (TEXT-FIRST)
In the text-first scheme, a MAIL with no "TO" argument is used to specify message text, which the receiver stores away 💜. Succeeding MRCPs are then treated as if they were MAIL commands, except that none of the text transfer manipulations get done. The stored message text is sent to the specified recipient, and a reply code comes back that's identical to the one an actual MAIL would get 🦋. (Note that ANY 2xx code indicates success 🎉.)
The stored message text isn't forgotten until the next MAIL or MRSQ, which will either replace it with new text or flush it entirely 🧼. Any use of MRSQ resets this scheme by flushing the stored text, and so does any use of MAIL with a non-null argument ✨.
If an MRCP shows up before any message text has been stored, the sender is effectively trying to send a null message. Some receivers might allow this, and others would return an error code 🤷♀️.
See the example in Appendix B for a mail transfer using MRSQ T 🌸.
WHY TWO SCHEMES ANYWAY?
Because neither one by itself is optimal for all systems 🫠. MRSQ R allows more of a "bulk" mailing, since everything is saved up and then mailed at once. This is super useful for systems like ITS, where the MTP-receiver doesn't write mail directly itself, but hands it on to a central mailer demon of great power 🔥. The more information (e.g., recipients) tied to a single "hand-off," the more efficiently mail can be delivered 🚀.
MRSQ T, by contrast, is geared to receiver-MTPs that want to deliver mail directly, one by one, incrementally 💅. For each recipient, this scheme returns an individual success/failure reply code, which may depend on variable mail system factors like exceeding disk allocation, mailbox access conflicts, and so forth 💾. If these receiver-MTPs tried to copy MRSQ R's bulk mailing, they'd have to make sure a success reply to the MAIL really did mean it had been delivered to ALL recipients specified, not just some 😬.
NOTES:
- Because these commands aren't required in the minimum implementation of MTP, you have to be prepared to deal with sites that don't recognize either MRSQ or MRCP 🙃.
MRSQandMRSQ ?are explicitly designed as tests to see whether either scheme is implemented. MRCP is not designed as a test, and a failure return of the "unimplemented" variety could be confused with "No scheme selected yet," or even with "Recipient unknown" 😵💫. - There's no way to indicate, in a positive response to
MRSQ ?, that the receiver's preferred "scheme" is the default state, i.e., none of the multi-recipient schemes. The reasoning is that in this case it would be pointless to implement MRSQ/MRCP at all, so the response would be negative 🙅♀️. - One reason MAIL is restricted to null "TO" arguments in this multi-recipient extension is the ambiguity that would result if a non-null "TO" argument were allowed. For example, say MRSQ R was in effect, some MRCPs had been given, and then
MAIL FROM:<X@Y> TO:<FOO><CRLF>was sent. There would be no way to tell a failure reply for mailbox "FOO" apart from a global failure for all recipients specified 😱. A similar situation exists for MRSQ T: it wouldn't be clear whether the text was stored and the mailbox failed, or the other way around, or both 🌀. - "Resets" are done by all MRSQs and "normal" MAILs to avoid confusion and overly complicated implementation 🧠. The MRSQ command implies a change or uncertainty of status, and the MAIL command would otherwise need some independent mechanisms to avoid clobbering the databases (e.g., the message text storage area) used by the T/R schemes. However, once a scheme is selected, it stays "in effect," just like an FTP "TYPE A" stays selected 🎀. The recommended way to do a reset without changing the current selection is
MRSQ ?. And remember, "MRSQ" alone reverts to the no-scheme state 💖. - It's permissible to intersperse other MTP commands among the MRSQ/MRCP/MAIL sequences ✨.
Okay, that's the whole MRSQ section, bestie 🌈💜
DECLARATIVE SPECIFICATIONS 💖
MINIMUM IMPLEMENTATION 🎀
okay so, to keep MTP workable without a pile of needless error messages, the following minimum implementation is REQUIRED for all receivers:
COMMANDS -- QUIT
MAIL
NOOPIn terms of FTP, the values of the transfer parameters MUST be:
TYPE -- ASCII
MODE -- STREAM
STRU -- FILE-STRUCTUREAll hosts MUST use the above values for mail transfer. no exceptions, bestie 🫶
CONNECTIONS 🌸
The receiver-MTP SHALL "listen" on Port L. The sender-MTP SHALL initiate the TCP/NCP control connection. The control connection is a full-duplex connection under TCP, and it's two simplex connections under NCP. Receiver- and sender- MTPs SHOULD follow the conventions of the TELNET Protocol as specified in the ARPA Internet Protocol Handbook. Receivers are under no obligation to provide for editing of command lines, and they MAY specify that it be done in the sender host. The control connection SHALL be closed by the receiver at the sender's request after all transfers and replies are completed. ✨
SEQUENCING OF COMMANDS AND REPLIES 🦋
The communication between the sender and receiver is meant to be an alternating dialogue. So the sender issues an MTP command, and the receiver responds with a prompt primary reply. The sender SHOULD wait for this initial primary success or failure response before sending further commands. it's giving turn-taking 💅
Certain commands require a second reply, and the sender SHOULD also wait for it. These replies can report on the progress or completion of mail transfer. They're secondary replies to mail transfer commands. 📬
One important group of informational replies is the connection greetings. Under normal circumstances, a receiver will send a 220 reply, "awaiting input", when the connection is completed. The sender SHOULD wait for this greeting message before sending any commands. If the receiver is unable to accept input right away, it SHOULD send a 120 "expected delay" reply immediately and a 220 reply when it's ready. That way the sender knows not to hang up if there's a delay. 🌈
Note: all the greeting type replies have the official name of the server host as the first word following the reply code.
The table below lists alternative success and failure replies for each command. These MUST be strictly adhered to. A receiver MAY substitute text in the replies, but the meaning and action implied by the code numbers and by the specific command reply sequence cannot be altered. no cap, this part is serious 🙈
COMMAND-REPLY SEQUENCES 🍓
In this section, the command-reply sequence is presented. Each command is listed with its possible replies, and command groups are listed together. Preliminary replies come first (with their succeeding replies indented under them), then positive and negative completion, and finally intermediary replies with the remaining commands from the sequence following. The 421 reply (service not available, closing control connection) MAY be given at any point if the MTP-receiver knows it MUST shut down. This listing forms the basis for the state diagrams, which will be presented separately. 💜
CONNECTION ESTABLISHMENT
120
220
220
421
MAIL ACTION COMMANDS
MAIL
151, 152
354
250
451, 552
354
250
451, 552
450, 550, 452, 553
500, 501, 502, 421
MRSQ
200, 215
500, 501, 502, 421
MRCP
151, 152
200
200
450, 550, 452, 553
500, 501, 502, 503, 421
QUIT
221
INFORMATIONAL COMMANDS
HELP
211, 214
500, 501, 502, 421
MISCELLANEOUS COMMANDS
NOOP
200
500 421STATE DIAGRAMS 🔥
Here we present state diagrams for a very simple minded MTP implementation. Only the first digit of the reply codes is used. There is one state diagram for each group of MTP commands. 🧚
The command groupings were decided by building a model for each command and then grouping together the commands with structurally identical models. ✨
For each command there are three possible outcomes: "success" (S), "failure" (F), and "error" (E). In the state diagrams below we use the symbol B for "begin", and the symbol W for "wait for reply". 🫶
We first present the diagram that represents most MTP commands:
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+This diagram models the commands:
HELP, MRCP, MRSQ, NOOP, QUIT.A more complex diagram models the MAIL command:
---- 1
| |
+---+ cmd -->+---+ 2 +---+
| B |---------->| W |---------->| E |
+---+ +---+ -->+---+
| | |
3 | | 4,5 |
-------------- ------ |
| | | +---+
| ------------->| S |
| | 1,3 | | +---+
| 2| --------
| | | |
V | | |
+---+ text +---+ 4,5 ----->+---+
| |---------->| W |---------->| F |
+---+ +---+ +---+Note that the "text" here is a series of lines sent from the sender to the receiver with no response expected until the last line is sent. (The last line MUST consist of only a single period.) okay, the period is the big finale 🎀
Finally we present a generalized diagram that could be used to model the command and reply interchange:
------------------------------------
| |
Begin | |
| V |
| +---+ cmd +---+ 2 +---+ |
-->| |------->| |---------->| | |
| | | W | | S |-----|
-->| | -->| |----- | | |
| +---+ | +---+ 4,5 | +---+ |
| | | | | | |
| | | 1| |3 | +---+ |
| | | | | | | | |
| | ---- | ---->| F |-----
| | | | |
| | | +---+
-------------------
|
|
V
EndCONNECTION ESTABLISHMENT 🌷
The MTP control connection is established via TCP/NCP between the receiver process port/socket L and the sender process port/socket U. This protocol is assigned the service port/socket 57 (71 octal), that is L=57. 🦋
APPENDIX A ✨
Example of MRSQ R (Recipients-first) 💅
This is an example of how MRSQ R is used. First the sender MUST establish that the receiver in fact implements MRSQ.
S: MRSQ <CRLF>
R: 200 OK, no scheme selectedAn MRSQ with a null argument always returns a 200 if implemented, selecting the default "scheme", i.e., none of them. If MRSQ were not implemented, a code of 4xx or 5xx would be returned. 🙈
S: MRSQ R <CRLF>
R: 200 OK, using that schemeAll is well, so now the recipients can be specified. 🎀
S: MRCP TO:<Foo@Y> <CRLF>
R: 200 OK
S: MRCP TO:<Raboof@Y> <CRLF>
R: 553 No such user here
S: MRCP TO:<bar@Y> <CRLF>
R: 200 OK
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 200 OKNote that the failure of "Raboof" has no effect on the storage of mail for "Foo", "bar" or the mail to be forwarded to "fubar@Z" through host "X". Now the message text is furnished, by giving a MAIL command with no "TO" argument. 💖
S: MAIL FROM:<waldo@A><CRLF>
R: 354 Type mail, ended by <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail sentThe mail text has now been sent to "Foo" and "bar" as well as forwarded to "fubar@Z". slay, we did it 👑
APPENDIX B 🌈
Example of MRSQ T (Text-first) 🧚
Using the same message as the previous example, we check that the receiver implements MRSQ.
S: MRSQ ? <CRLF>
R: 215 T Text first, pleaseMRSQ is indeed implemented, and the receiver says it prefers "T", but that needn't stop the sender from trying something else. 🦋
S: MRSQ R <CRLF>
R: 501 Sorry, I really can't do thatIt's possible that it could have understood "R" also, but in general it's best to use the "preferred" scheme, since the receiver knows which one is most efficient for its particular site. 🍓
S: MRSQ T <CRLF>
R: 200 OK, using that schemeScheme "T" is now selected, and the message text is sent by giving a mail command with no "TO" argument. 🔥
S: MAIL FROM:<WALDO@A><CRLF>
R: 354 Type mail, ended by <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail storedNow recipients can be specified. 💜
S: MRCP TO:<Foo@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<Raboof@Y> <CRLF>
R: 553 No such user here
S: MRCP TO:<bar@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 200 OKThe text has now been sent to "Foo" and "bar" at host "Y", and it will be forwarded to "fubar@Z" through host "X", and it still remains stored. A new message can be sent with another MAIL/MRCP ... sequence, but a careful sender would reset the state using the exchange below. ✨
S: MRSQ ? <CRLF>
R: 215 T Text first, pleaseThat resets the state without altering the scheme in effect. the end, bestie 🫶💖
📦 where this page comes from
- ietf: rfc772 1980-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms