RFC 780
Mail Transfer Protocol
Part 1 of 6 🎀
Title Block 📬
Okay bestie, this is RFC 780, titled MAIL TRANSFER PROTOCOL 💌 from the Network Working Group. It was written by Suzanne Sluizer and Jonathan B. Postel 🫶 at ISI, the Information Sciences Institute at the University of Southern California (4676 Admiralty Way, Marina del Rey, California 90291, phone (213) 822-1511). It's dated May 1981 🗓️, and it replaces RFC 772 ✨.
Here's the table of contents, so you know what's coming:
1. INTRODUCTION .................................................. 1
2. THE MTP MODEL ................................................. 2
3. BASIC MAIL .................................................... 4
3.1. Forwarding ............................................... 5
3.2. Source Routing ........................................... 6
4. MULTI-RECIPIENT MAIL .......................................... 8
4.1. Scheme Selection: MRSQ ................................... 8
4.2. Message Text Specification: MAIL ......................... 9
4.3. Recipient Specification: MRCP ........................... 10
4.4. Scheme Mechanics: Recipients First ...................... 10
4.5. Scheme Mechanics: Text First ............................ 12
4.6. Discussion .............................................. 12
5. SPECIFICATIONS ............................................... 16
5.1. MTP Commands ............................................ 16
5.1.1. Command Semantics ..................................... 16
5.1.2. Command Syntax ........................................ 18
5.2. MTP Replies ............................................. 22
5.2.1. Reply Codes by Function Group ......................... 23
5.2.2. Reply Codes in Numeric Order .......................... 24
5.3. Sequencing of Commands and Replies ...................... 25
5.4. State Diagrams .......................................... 28
5.5. Details ................................................. 30
5.5.1. Minimum Implementation ................................ 30
5.5.2. Transparency .......................................... 30
5.5.3. Sizes ................................................. 30
APPENDIX A: TCP ................................................. 32
APPENDIX B: NCP ................................................. 33
APPENDIX C: NITS ................................................ 34
APPENDIX D: X.25 ................................................ 35
APPENDIX E: Theory of Reply Codes ............................... 36
GLOSSARY ......................................................... 39
REFERENCES ....................................................... 421. Introduction ✨
The whole point of the Mail Transfer Protocol (MTP) is to move mail reliably and efficiently 📨.
MTP doesn't care what transmission subsystem is underneath it 🙌. It only needs a reliable, ordered data stream channel. The appendices explain how to use MTP with different transport services, and there's a Glossary that defines the terms used in this document 📖.
The big feature here is that MTP can relay mail from one transport environment to another 🔁. A transport service gives you an interprocess communication environment (IPCE) 🧩. An IPCE can cover one network, several networks, or just a subset of a network. A process can talk directly to any other process inside its own IPCE. Mail is a special case of interprocess communication 💌. Mail can get from one IPCE to another by being relayed through a process that's connected to two (or more) IPCEs. To be more specific, a host that sits on two different transport systems can relay mail between hosts on those systems. The big realization is that transport systems (IPCEs) are not one-to-one with networks 🤯.
2. The MTP Model 💖
Here's the basic model of communication. When the user starts things up, the sender-MTP sets up the full-duplex transmission channel 🎀. The sender-MTP generates MTP commands and sends them to the receiver-MTP. The receiver-MTP sends MTP replies back to the sender-MTP in response to those commands.
In the simplest case, once the channel is up, the MTP-sender sends a MAIL command that says who the sender and receiver of the mail are 📩. If the MTP-receiver can accept the mail, it sends back a go ahead reply 🚦. Then the MTP-sender sends the mail data, ending with a special sequence. If the MTP-receiver successfully processes the mail, it sends back an OK reply ✅.
-------------------------------------------------------------
+----------+ +----------+
+------+ | | | |
| User |<-->| | MTP | |
+------+ | Sender- |Commands/Replies| Receiver-|
+------+ | MTP |<-------------->| MTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
Sender-MTP Receiver-MTP
Model for MTP Use
Figure 1
-------------------------------------------------------------MTP gives you the mechanisms to transmit mail. It can go directly from the sending user's host to the receiving user's host when both hosts are connected to the same transport service 🏠. When the source and destination hosts aren't on the same transport service, it goes through one or more relay MTP-servers instead 🔀.
To manage relaying, the MTP-server has to be given the name of the ultimate destination host, as well as the destination mailbox name 📮.
The arguments to the MAIL command are a FROM path and a TO path 🛣️. The TO path is a source route, while the FROM path is a return route. The return route can be used to send a message back to the sender when something goes wrong with a relayed message 🙈.
Everything above described sending one copy of one message from a source to a destination host, and the possibility of relaying messages between different transport services. MTP also supports sending one copy of a message to multiple recipients 👯.
For mail to be transmitted successfully, the destination users have to be known at the destination receiver-MTP, and the mail data has to be correctly received and stored 💾. In the single recipient case above, a positive response to the MAIL command meant the recipient was known, and the final OK response meant the mail was received and stored.
To handle multi-recipient mail, MTP offers two procedures: Text-First and Recipients-First 🧁. In the text-first scheme, the mail data is sent and acknowledged first, and then each recipient is sent and acknowledged (or refused) separately. In the recipients-first scheme, the recipients get negotiated first, and then the text is sent and acknowledged for all recipients at once. The receiver-MTP picks the scheme, and that choice depends on how the destination host handles mail 🎯.
The multi-recipient procedures are optional, and which scheme gets used is negotiated. The multi-recipient schemes are strongly encouraged, because of the savings they bring in transmission and processing 💅.
The mail commands and replies have a rigid syntax 🧱. Replies also carry a numeric code. The examples below use real commands and replies. The complete lists of commands and replies are in Section 5 on specifications 📋.
Commands and replies are not case sensitive. A command or reply word can be upper case, lower case, or any mix of the two 🔤. This is not true for mailbox user names, though 🙅. For some hosts, the user name is case sensitive, so MTP implementations must preserve the case of user names exactly as they appear in mailbox arguments 🫶.
3. BASIC MAIL ✨
okay so the basic command for sending mail is MAIL 💌 It's the thing that drops the data into the recipient's mailbox, or accepts it to be relayed onward to the destination host.
The mail text also travels over the same transmission channel 📨 That means the end of the text has to be clearly marked so the command and reply chat can pick back up. MTP marks the end with a line containing only a period. There's also a transparency procedure so that period doesn't accidentally clash with the user's actual text (see Section 5.5.2) 🫶
MAIL <SP> FROM:<sender-path> <SP> TO:<receiver-path> <CRLF>The <sender-path> holds the source mailbox, and the <receiver-path> holds the destination mailbox. If it's accepted, the receiver-MTP sends back a 354 reply and treats every line after that as message text. The text ends with a line containing only a period, and then a 250 completion reply comes back. Various errors are possible too, so keep your eyes open 👀
Honestly, the paths are more than just mailboxes 🗺️ They can be source routes. The <receiver-path> is a source routing list of hosts plus the destination mailbox, and the <sender-path> is a reverse source routing list of hosts plus the source mailbox.
Example of MAIL (Basic Mail) 💖
This MAIL command says the mail is sent by Waldo at host A and is headed for Foo at host Y. Here we're assuming host A talks to host Y directly.
S: MAIL FROM:<waldo@A> TO:<Foo@Y> <CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail sentAnd just like that, the mail text has been sent to "Foo" ✨
Example 1
3.1. FORWARDING 🦋
There are two possible preliminary replies a receiver can use to say "I'm accepting mail for a user whose mailbox isn't on this host" 🧚
151 User not local; will forward to <user>@<host>This one means the receiver-MTP knows the user's mailbox lives on another host and will take responsibility for forwarding the mail there. It only gets sent when the sender wouldn't expect the mail to be forwarded. So if <receiver-path> in the command shows mail relaying, this reply isn't used. It's handy for an organization with several hosts where each host has a big list of users. A host can accept mail for anyone on its list and forward it to the right host 💅
152 User Unknown; mail will be forwarded by the operatorThis one means the host doesn't recognize the user name, but it'll still accept the mail and have the operator try to deliver it. That's useful when someone misspells a name 🙈 It can be a disservice if the mail really is undeliverable, though.
If operator forwarding isn't okay, or the sending user would rather send directly to the recipient's actual host, the action can be aborted 🛑
The MTP-sender has to accept or reject the proposal in the preliminary reply by sending either a continue (CONT) or an abort (ABRT) command. If it's a continue, the next reply from the MTP-receiver will be one of the replies expected for the MAIL command, most likely 354 Start mail input, .... If it's an abort, the next reply from the MTP-receiver will be 201 Command okay, action aborted 🎀
3.2. SOURCE ROUTING 🗺️
The receiver-path can be a source route of the form @ONE,@TWO,JOE@THREE, where ONE, TWO, and THREE are hosts. This form is there to emphasize the difference between an address and a route. Iconic distinction, honestly 👑
Someday far off, the mailbox format might need a region identifier, like user@host@region. If that happens, the MTP path convention could be extended to host@region,host@region,...user@host@region. For example, ONE@R1,TWO@R2,JOE@THREE@R3 🌈
The mailbox is an absolute address, and the route is info about how to get there. Those two concepts should not be confused 🫶
The elements of the receiver-path get moved to the sender-path as the message is relayed from one MTP to another. The sender-path is a reverse source route, meaning a source route back to the originator of the message 🔁 When an MTP deletes its identifier from the receiver-path and inserts it into the sender-path, it must use the name it's known by in the environment it's sending into, not the environment the mail came from. That's because an MTP might be known by different names in different environments 🫠
When source routing is in use, the receiver-MTP will receive mail that needs relaying to another MTP. It can accept the job of relaying or reject it, just the same way it accepts or rejects mail for a local user. It doesn't use the 151 "User not local" or 152 "User Unknown" preliminary replies for this. Once the receiver-MTP accepts the relaying job, it receives the mail text and transforms the command arguments. It removes its own identifier from the receiver-path and puts it at the beginning of the sender-path. Then the receiver-MTP becomes a sender-MTP, sets up a transmission channel to the next MTP in the receiver-path, and sends the mail along 🚀
If an MTP has accepted the relaying job and later finds that the receiver-path is wrong, or that the mail can't be delivered for whatever reason, it must construct a notification message and send it to the originator of the undeliverable mail, as indicated by the sender-path. This notification message must come from the MTP at this host. So the sender-path of the notification message itself will be MTP@<host>, and in the notification message header the From field will be MTP at <host>. Of course, MTPs should not send notification messages about problems with notification messages 🙅♀️
4. MULTI-RECIPIENT MAIL 🌸
There are two MTP commands that let the text of one message go to several recipients at once. This is way more efficient than sending the text over and over for each extra recipient at a host 💜 In one scheme, all the recipients get specified first, and then the text gets sent. In the other scheme the order flips: the text goes first, followed by the recipients. The sender-MTP suggests the scheme it'd prefer, but the receiver-MTP is the one who controls which scheme actually gets used. To pick a scheme, the MRSQ command is used. To specify recipients after a scheme is chosen, MRCP commands are given. And to furnish text, the MAIL command is used 📬
Both schemes exist because neither one alone is best for every system. MRSQ R allows more of a "bulk" mailing, since everything gets saved up and then mailed all at once. That's super useful for systems like ITS, where the MTP-receiver doesn't write mail directly and instead hands it off to a central mailer demon 🤖 The more information (like recipients) attached to a single "hand-off," the more efficiently the mail can be delivered ✨
MRSQ T, on the other hand, is built for receiver-MTPs that want to deliver mail directly, one by one, in an incremental way 🍓 For each recipient, this scheme returns an individual success or failure reply code, which can depend on messy mail system stuff like exceeding disk allocation, mailbox access conflicts, and so on. 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 meant the mail had been delivered to ALL recipients specified, not just some 😭
4.1. SCHEME SELECTION: MRSQ 💅
MRSQ is how a sender-MTP can test for MRSQ/MRCP implementation, select a particular scheme, reset its state, and even do a bit of basic negotiation. The format is:
MRSQ [<SP> <scheme>] <CRLF><scheme> is a single character. These are 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, use the specified scheme
215 <scheme> This is the scheme I prefer
504 I understand MRSQ but can't use that scheme
5xx Command unrecognized or unimplementedThere are three important things about MRSQ 👑 The first is that an MRSQ with no argument must always return a 200 reply and restore the default state of having no scheme selected. Any other reply implies that MRSQ, and therefore MRCP, isn't understood or can't be performed correctly.
The second is that using ? as a <scheme> asks the MTP-receiver to return a 215 reply, in which the receiver names a "preferred" scheme. The format of that reply is simple:
215 <SP> <scheme> [<SP> <string>] <CRLF>Any other reply (like 4xx or 5xx) implies that MRSQ and MRCP aren't implemented, because ? must always be implemented if MRSQ is 🙈
The third is that MRSQ always has the side effect of resetting all schemes to their initial state. That reset has to happen no matter what the reply is (200, 215, or 504) 🔄 The actions needed for a reset get explained when we talk about how each scheme actually works.
One more note: the receiver gets to choose which scheme is used, so the sender must be prepared to do either one 🫶
4.2. MESSAGE TEXT SPECIFICATION: MAIL 📝
No matter which scheme (if any) has been selected, a MAIL command with a non-null receiver-path argument behaves exactly as before. MRSQ and MRCP have no effect on it. Still, a normal MAIL command does have the same side effect as MRSQ: it "resets" all schemes to their initial state 🌀
The chosen scheme only matters when the receiver-path argument is null:
MAIL FROM:<sender-path> <CRLF>Instead of throwing an error, the receiver accepts message text for this "null" recipient specification 💖 What it does with that text depends on which scheme is in effect, and that gets described in the section on Scheme Mechanics.
4.3. RECIPIENT SPECIFICATION: MRCP 🎀
To specify recipient names (aka mailboxes) and get an acknowledgment (or a refusal) for each one, the following command is used:
MRCP <SP> TO:<receiver-path> <CRLF>Okay bestie, so the receiver's replies to MRCP are where the fun really starts 🎀✨
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
550 Recipient name rejected
4xx Temporary error, try this name again later
5xx Permanent error, report to senderQuick reminder: using this command with no scheme picked yet is an error 🙅♀️. You need an MRSQ <scheme> first if you want to use MRCP 💅
4.4. SCHEME MECHANICS: MRSQ R (RECIPIENTS-FIRST) 🍓
Okay, so in the recipients-first scheme, MRCP is how you tell the receiver which names to hang onto in a list or table 📋 Usually each MRCP gets a 200 if it's accepted, or a 4xx/5xx if it isn't. The 5xx ones are permanent no-go's (like "user not known"), so you should pass those along to the actual human 🫶 The 4xx ones are more like "not right now, try again later" ⏳
Here's the lowkey important bit: none of the 4xx/5xx replies mess with the MRCP commands before or after them 🦋 The one exception is 452, which means no more MRCPs will work unless you send a message to the names you already stored, or you do a reset 😭
To send the actual message to everyone you stored, you give a MAIL command with no receiver-path argument, so basically MAIL <SP> FROM: <sender-path> <CRLF> 💌 The text gets transmitted exactly like a normal MAIL. Now here's the plot twist: a positive acknowledgment at the end means the message went to ALL the recipients you remembered with MRCP, and a failure code means it's considered failed for ALL of them, no matter what the actual error code was 💀 Either way, every stored recipient name gets flushed and forgotten, so everything goes back to its initial state 🧹 That purge has to happen as a side effect of any MRSQ (or any MAIL with a non-null receiver-path argument) too ✨
If you hit a 452 (out of storage space), you can use MAIL to send the message to whoever's currently stored, then send more MRCPs and another MAIL, as many times as you need 🔁 For example, if a receiver only has room for 10 names, a 50-recipient message gets sent 5 times, each time to 10 different people 🌸
And if a sender tries to send message text (MAIL with no receiver-path argument) before any successful MRCPs, that gets handled just like a "normal" MAIL with a null recipient. Some receivers will throw a "550 Null recipient" error at you 🙈
Here's how it looks in action 👀
First the sender has to confirm that the receiver implements MRSQ.
S: MRSQ <CRLF>
R: 200 OK, no scheme selectedAn MRSQ with a null argument always gives a 200 if it's implemented, and it picks the default "scheme," which is just none of them 🤷♀️ If MRSQ weren't implemented, you'd get a 4xx or 5xx back instead.
S: MRSQ R <CRLF>
R: 200 OK, using that schemeYay, the scheme is set, so now we can add recipients 🎉
S: MRCP TO:<Foo@Y> <CRLF>
R: 200 OK
S: MRCP TO:<Raboof@Y> <CRLF>
R: 550 No such user here
S: MRCP TO:<bar@Y> <CRLF>
R: 200 OK
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 200 OK"Raboof" getting rejected doesn't change anything for "Foo," "bar," or the mail that's getting relayed to "fubar@Z" through host "X" 🦋 Now we hand over the message text with a MAIL command that has no receiver-path argument.
S: MAIL FROM:<waldo@A><CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail sentAnd just like that, the mail has gone to "Foo" and "bar," and got relayed to "fubar@Z" 🥳
Example 2
4.5. SCHEME MECHANICS: MRSQ T (TEXT-FIRST) 📝
Now the text-first scheme flips things around 🙃 Here, MAIL with no receiver-path argument is how you send the message text, and the receiver stores it away for later. After that, every MRCP gets treated as if it were a MAIL command, except none of the text transfer stuff happens again. The stored text just goes to whoever you named, and you get back the same reply code that a real MAIL would've gotten. (Quick note: any 2xx code means success 🙌)
The stored text sticks around until the next MAIL or MRSQ, which will either swap it out for new text or flush it completely 🗑️ Any MRSQ resets this scheme by flushing the stored text, and so does any MAIL with a non-null receiver-path argument.
If an MRCP shows up before any message text has been stored, the sender is basically trying to send a null message 🫠 Some receivers might be cool with that, and others will return an error code.
Let's see the vibe in the example 👇
First the sender has to confirm that the receiver implements MRSQ.
S: MRSQ ? <CRLF>
R: 215 T Text first, pleaseMRSQ is definitely implemented, and the receiver says it prefers "T." The sender is free to try something else though 💅
S: MRSQ R <CRLF>
R: 504 Sorry, I really can't do thatThe receiver might have understood "R" too, but honestly it's usually best to go with the "preferred" scheme, since the receiver knows which one is most efficient for its own site 🧠
S: MRSQ T <CRLF>
R: 200 OK, using that schemeScheme "T" is locked in now, so the message text gets sent with a MAIL command that has no receiver-path argument.
S: MAIL FROM:<WALDO@A><CRLF>
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah blah....etc. etc. etc.
S: <CRLF>.<CRLF>
R: 250 Mail storedTime to add recipients 🎀
S: MRCP TO:<Foo@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<Raboof@Y> <CRLF>
R: 550 No such user here
S: MRCP TO:<bar@Y> <CRLF>
R: 250 Stored mail sent
S: MRCP TO:<@Y,@X,fubar@Z> <CRLF>
R: 250 Mail accepted for relayingSo the text went to "Foo" and "bar" at host "Y," and it'll get relayed to "fubar@Z" through host "X." It also still stays stored 📦 You can send a new message with another MAIL/MRCP ... sequence, but a careful sender would reset the state with the exchange below 🧼
S: MRSQ ? <CRLF>
R: 215 T Text first, pleaseThat resets the state without changing the scheme that's in effect 🦋
Example 3
4.6. DISCUSSION 💭
So, these commands aren't part of the minimum MTP implementation, which means you have to be ready for sites that don't recognize MRSQ or MRCP at all 😭 "MRSQ" and "MRSQ ?" were explicitly designed as tests to check whether either scheme is implemented 🔍 MRCP wasn't designed as a test, though, so a failure of the "unimplemented" variety could get mixed up with "No scheme selected yet," or even with "Recipient unknown" 🫣
There's no way to say, in a positive reply to MRSQ ?, that a receiver's preferred "scheme" is the default state (none of the multi-recipient schemes). The reasoning is that if that were the case, implementing MRSQ/MRCP would be pointless, so the answer would be negative anyway 🤓
The reason MAIL is limited to null receiver-path arguments in this multi-recipient extension is the ambiguity a non-null one would cause. For example, say MRSQ R is in effect, some MRCPs have been given, and then someone does MAIL FROM:<X@Y> TO:<FOO@Z><CRLF>. There'd be no way to tell a failure reply for mailbox "FOO" apart from a global failure for all the recipients specified 😵 It's the same deal for MRSQ T: you wouldn't know whether the text was stored and the mailbox failed, or the other way around, or both 💀
All schemes get reset by every MRSQ and every "normal" MAIL, to avoid confusion and overcomplicated implementations 🧩 The MRSQ command implies a change or uncertainty of status, and MAIL would otherwise need some separate mechanism to avoid clobbering the data bases (like the message text storage area) used by the T/R schemes. Once a scheme is selected, though, it stays in effect ✨ The recommended way to reset without changing the current selection is MRSQ ?. And remember, plain MRSQ alone reverts to the no-scheme state 🌈
5. SPECIFICATIONS 📜
5.1. MTP COMMANDS 🛠️
5.1.1. COMMAND SEMANTICS
The MTP commands are how you request mail transfer or the mail system function you want 💌 They're character strings ending in <CRLF>. The command codes are alphabetic characters, followed by <SP> if parameters come after, or <CRLF> if they don't. The syntax of mailboxes must conform to receiver site conventions 🫶 The MTP commands are discussed below, and MTP replies are discussed in Section 5.2 ✨
MAIL (MAIL) 📨
This command sends mail over the transmission channel. The argument field holds a sender-path sequence and an optional receiver-path sequence.
The sender-path sequence is an optional list of hosts plus the sender mailbox. When the list of hosts is there, it's "reverse" source routing information, and it shows the mail was relayed through each host on the list (the first host in the list was the most recent relay) 🔄 This list gets used as source routing to send non-delivery notices back to the sender. As each relay host adds itself to the beginning of the list, it must use its name as known in the network it's relaying the mail to, rather than the network the mail came from (if they're different) 🌐
If the receiver-path sequence is there, it's an optional list of hosts plus a destination mailbox. When the list of hosts is present, it's source routing information, and it means the mail must be relayed to the first host on the list 🚀
The receiver treats the lines after the command as mail text from the sender. The mail text ends with the character sequence <CRLF>.<CRLF> (see Section 5.5.2 on Transparency) 🎀
As mail gets relayed along the receiver-path sequence, each relay host has to remove itself from that sequence and put itself at the beginning of the sender-path sequence 🦋. Once mail reaches its final destination (the receiver-path sequence has only a destination mailbox), the receiver-MTP drops it into that mailbox following its host mail conventions 💌. For example, MAIL FROM:<X@Y> TO:<@A,@B,C@D> <CRLF> eventually gets relayed as MAIL FROM:<@A,X@Y> TO:<@B,C@D> <CRLF>. It's giving relay race 🏃♀️💨
If the receiver-path sequence is empty, the mail is meant for a printer or another designated spot for the host's general delivery mail (if that's allowed at this host) 🖨️. The mail may be marked as sent from the sender listed in the sender-path sequence field ✨.
MAIL RECIPIENT SCHEME QUESTION (MRSQ) 🎀
This MTP command picks a scheme for sending mail to several users at the same host. The two schemes are recipients-first and text-first, so it's basically choosing who goes first 🍓
MAIL RECIPIENT (MRCP) 💜
This command names the individual recipients of the mail when one transmission is delivering mail for multiple users at one host 📬
HELP (HELP) 🧚
This command makes the receiver send helpful info about its implementation status over the transmission channel. The command can take an argument (for example, any command name) and then return more specific info as a response 🌸
QUIT (QUIT) 👋
This command says the receiver must close the transmission channel. Bye bye bestie 🫶
NOOP (NOOP) 😴
This command doesn't change any parameters or commands that were already entered. It doesn't do anything except tell the receiver to send an OK reply ✅
CONTINUE (CONT) 🔁
This command says the previously specified action should keep going. It's only sent after a preliminary reply 💅
ABORT (ABRT) 🛑
This command says the previously specified action should be aborted. It's only sent after a preliminary reply too. It doesn't do anything else except make the receiver send an OK reply 🙈
5.1.2. COMMAND SYNTAX ✨
The commands start with a command code, then an argument field. Command codes are four alphabetic characters. Upper and lower case letters get treated the exact same way, so any of these could be the mail command 💖
MAIL Mail mail MaIl mAIlThe same goes for symbols that stand in for parameter values, like R or r for RECIPIENT first. The command codes and argument fields are separated by one or more spaces 🌈
BUT (this is important!) case matters in the sender-path and receiver-path arguments. In some hosts, the user "foo" is totally different from the user "Foo" 👀
The argument field is a variable length string of characters that ends with the character sequence <CRLF>. The receiver shouldn't do anything until it gets the end of the line 🧐
Square brackets mark an optional argument field. If you don't take the option, the appropriate default is implied. Every character is in the ASCII character set 🔤
Here are the MTP commands 💅
MAIL <SP> FROM:<sender-path> [<SP> TO:<receiver-path>] <CRLF>
MRSQ [<SP> <scheme>] <CRLF>
MRCP <SP> TO:<receiver-path> <CRLF>
HELP [<SP> <string>] <CRLF>
QUIT <CRLF>
NOOP <CRLF>
CONT <CRLF>
ABRT <CRLF>The syntax of those argument fields is below, written in BNF notation where it fits. The "..." notation means a field can repeat one or more times 🧩
<sender-path> ::= <path>
<receiver-path> ::= <path>
<scheme> ::= "R" | "T" | "?"
<string> ::= <char> | <char> <string>
<path> ::= "<" ["@" <host> "," ...] <mailbox> ">"
<host> ::= <a> <string> | "#" <number> | "[" <dotnum> "]"
<mailbox> ::= <user> "@" <host>
<user> ::= <string>
<char> ::= <c> | '\' <c> | '\' <s>
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
<number> ::= <d> | <d> <number>
<snum> ::= three digits representing an integer value in the
range 0 through 255
<specials> ::= '<', '>', '(', ')', '\', ',', ';', ':', '@',
'"', and the control characters (ASCII codes 0 through 37
octal inclusive and 177 octal)
<a> ::= any one of the 26 letters A through Z in either case
<c> ::= any one of the 128 ASCII characters except
<specials>
<d> ::= any one of the ten digits 0 through 9
<s> ::= any one of <specials>Okay, the backslash, \, is a quote character 🫣 It tells you the next character should be read literally instead of with its usual meaning. For example, "Joe\,Smith" can be a single nine character user field, with the comma as the fourth character 💁♀️
Hosts usually go by names that get translated to addresses in each host. Sometimes a host isn't known to the translation function, and then communication is blocked 😭 To get around that, numeric forms are allowed for host "names" too. One option is a decimal integer with a pound sign in front, "#", which says the number is the host's address 🔢 The other option is four small decimal integers separated by dots and wrapped in brackets, like "[123.255.37.321]", which means a 32 bit ARPA Internet Address in four eight bit fields 🌟
5.2. MTP REPLIES 💌
Replies to MTP commands are designed to keep requests and actions in sync during mail transfer, and to make sure the sender-MTP always knows what state the receiver-MTP is in 🫶 Every command must generate exactly one reply. Some commands also have to happen in order, like MRSQ T->MAIL->MRCP or MRSQ R->MRCP->MAIL 🔄
The details of the command-reply sequence are explained in Sections 5.3 and 5.4 on Sequencing and State Diagrams 📖
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. The text is for the human user 🧑💻 The three digits are supposed to hold enough encoded info that the sender-MTP never has to read the text. It can throw the text away or pass it along to the user, whichever makes sense ✨ The text may depend on the receiver, so there are probably different texts for each reply code. More on how reply codes get assigned is in Appendix E on the Theory of Reply Codes 🧠 Formally, a reply is defined as: a three-digit code, <SP>, one line of text, and <CRLF>.
5.2.1. REPLY CODES BY FUNCTION GROUPS 🎀
200 Command okay
201 Command okay, action aborted
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
504 Command parameter not implemented
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 transmission channel
421 <host> Service not available, closing transmission channel
[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
552 Requested mail action aborted: exceeded storage allocation
[For current mailbox location]
553 Requested action not taken: mailbox name not allowed
[E.g., mailbox syntax incorrect]
354 Start mail input; end with <CRLF>.<CRLF>5.2.2. 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
201 Command okay, action aborted
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 transmission channel
250 Requested mail action okay, completed
354 Start mail input; end with <CRLF>.<CRLF>
421 <host> Service not available, closing transmission channel
[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
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
504 Command parameter not implemented
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 allowed
[E.g., mailbox syntax incorrect]5.3. 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 answers with a prompt primary reply. The sender should wait for that response before sending any more commands ⏳✨
5. Specifications, Part Two: Replies That Keep the Vibe Going 💖
The 1xx (preliminary) and 3xx (intermediate) replies are basically the server saying "hold up, we need more stuff before this is done" 🎀. Preliminary replies need either a continue or an abort command before anything moves forward. Intermediate replies need further commands that depend on the action in progress 🦋.
One of the most important replies is the connection greeting 👑. Normally, the receiver sends a 220 "Awaiting input" reply once the connection is set up. The sender should wait for that greeting before sending any commands, so don't jump the gun 🙈. If the receiver can't take input right away, it should immediately send a 120 "Expected delay" reply. The sender can then say it's willing to wait with a continue command, or say it isn't with the abort command. The receiver answers an abort with a 201 reply, and answers a continue with the 220 reply once it's ready ✨.
Note: all the greeting type replies have the official name of the server host as the first word following the reply code.
For example:
220 <SP> USC-ISIF <SP> Service ready <CRLF>The table below lists the alternative success and failure replies for each command 💅. These must be strictly adhered to. A receiver can change the text in the replies, but the meaning and action implied by the code numbers, and by the specific command reply sequence, can't be changed 🔥.
COMMAND-REPLY SEQUENCES
Each command is listed with its possible replies 🌸. Preliminary replies come first, with the replies that follow them indented underneath. After that come the success and failure completions, and finally the intermediary replies, along with the remaining commands in the sequence. The prefixes are "P" for preliminary, "I" for intermediate, "S" for success, "F" for failure, and "E" for error. The 421 reply (service not available, closing transmission channel) can be given to any command if the MTP-receiver knows it has to shut down 😭. This listing is the basis for the State Diagrams in Section 5.4 🧚.
CONNECTION ESTABLISHMENT
P: 120 -> CONT -> S: 220
F: 421
ABRT S: 201
F: 421
S: 220
F: 421
MAIL
P: 151 -> CONT -> I: 354 -> text -> S: 250
152 F: 451,552,450,
550,452,553
ABRT -> S: 201
F: 451,552,450,550,452,553
I: 354 -> text -> S: 250
F: 451,552,450,550,452,553
F: 451, 552, 450, 550, 452, 553
E: 500, 501, 502, 421
MRSQ
S: 200, 215
E: 500, 501, 502, 504, 421
MRCP
P: 151 -> CONT -> S: 200, 215, 250
152 F: 451,552,450,550,452,553
ABRT -> S: 201
F: 451,552,450,550,452,553
S: 200, 215, 250
F: 451, 552, 450, 550, 452, 553
E: 500, 501, 502, 503, 421
QUIT
S: 221
E: 500, 421
HELP
S: 211, 214
E: 500, 501, 502, 504, 421
NOOP
S: 200
E: 500, 421
CONT
S: depends on previous command
F: depends on previous command
E: 500, 501, 502, 504, 421
ABRT
S: 201,
E: 500, 501, 502, 504, 4215.4. STATE DIAGRAMS 🦋
Here are the state diagrams for a very simple-minded MTP implementation ✨. Only the first digit of each reply code is used. There's 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 🧩.
Every command has three possible outcomes: "success" (S), "failure" (F), and "error" (E). In the diagrams below, B stands for "begin" and W stands for "wait for reply" 💜.
First up is the diagram for most of the MTP commands 💅:
1,3 +---+
----------->| E |
| +---+
|
+---+ cmd +---+ 2 +---+
| B |---------->| W |---------->| S |
+---+ +---+ +---+
|
| 4,5 +---+
----------->| F |
+---+This diagram models the commands:
HELP, MRCP, MRSQ, NOOP, QUIT, ABRT.The MAIL command gets a more complex diagram 🌈:
ABRT +---+ 1,3
CONT ---- ------------->| W |-------
| | +---+ |
| |1 4,5| |2 V
+---+ cmd -->+---+ 2 | | +---+
| B |---------->| W |-------------------->| E |
+---+ +---+ ------------>+---+
3| |4,5 | | |
| | | | |
-------------- ------ | | |
| | | | ---->+---+
| ----------------------->| S |
| | | | | +---+
| | -------- |
| | | | |
V 2| |1,3 | |
+---+ text +---+ | ------->+---+
| |---------->| W | --------------->| F |
+---+ +---+-------------------->+---+
4,5Note that the "text" here is a series of lines sent from the sender to the receiver. No response is expected until the last line is sent 🍓.
5.5. DETAILS 🎀
5.5.1. MINIMUM IMPLEMENTATION
To make MTP workable, every receiver is required to have the following minimum implementation 💖:
COMMANDS -- MAIL
QUIT
NOOP5.5.2. TRANSPARENCY
Without some provision for data transparency, the character sequence <CRLF>.<CRLF> ends the mail text, so a user couldn't send it 😭. Users usually don't know about these "forbidden" sequences. To let all user-composed text go through transparently, the following procedures are used ✨.
- Before sending a line of mail text, the sender-MTP checks the first character of the line. If it's a period, one extra period is inserted at the beginning of the line.
- When the receiver-MTP gets a line of mail text, it checks the line. If the line is made up of a single period, it marks the end of the mail. If the first character is a period and there are other characters on the line, the first character is deleted 🫶.
5.5.3. SIZES
Several objects ought to have defined maximum sizes 📏:
- user: The maximum total length of a user name is 40 characters.
- host: The maximum total length of a host name or number is 20 characters.
- path: The maximum total length of a sender-path or receiver-path is 100 characters.
- command line: The maximum total length of a command line, including the command word and the
<CRLF>, is 200 characters. - reply line: The maximum total length of a reply line, including the reply code and the
<CRLF>, is 65 characters. - text line: The maximum total length of a text line, including the
<CRLF>, is 1000 characters.
As far as possible, implementation techniques that impose no limits at all on the length of these objects should be used 🌸.
APPENDIX A ✨
TCP Transport service
The Transmission Control Protocol [1] is used on the ARPA Internet, and on any network that follows the US DoD standards for internetwork protocols 🌐.
Connection Establishment
The MTP transmission channel is a TCP connection between the sender process port U and the receiver process port L. This single full-duplex connection serves as the transmission channel. This protocol is assigned service port 57 (71 octal), so L=57 💜.
Data Transfer
The TCP connection supports the transmission of 8-bit bytes. The MTP data is 7-bit ASCII characters. Each character is sent as an 8-bit byte with the high-order bit cleared to zero 🧚.
APPENDIX B 🦋
NCP Transport service
The ARPANET Host-to-Host Protocol [2], implemented by the Network Control Program, may be used on the ARPANET 👑.
Connection Establishment
The MTP transmission channel is set up via NCP between the sender process socket U and the receiver process socket L. The Initial Connection Protocol [3] is followed, which results in a pair of simplex connections. This pair of connections is used as the transmission channel. This protocol is assigned contact socket 57 (71 octal), so L=57 🎀.
Data Transfer
The NCP data connections are established in 8-bit byte mode. The MTP data is 7-bit ASCII characters. Each character is sent as an 8-bit byte with the high-order bit cleared to zero 💅.
APPENDIX C 🌈
NITS
The Network Independent Transport Service [4] may be used 🫶.
Connection Establishment
The MTP transmission channel is set up via NITS between the sender process and the receiver process. The sender process executes the CONNECT primitive, and the waiting receiver process executes the ACCEPT primitive ✨.
Data Transfer
The NITS connection supports the transmission of 8-bit bytes. The MTP data is 7-bit ASCII characters. Each character is sent as an 8-bit byte with the high-order bit cleared to zero 💖.
APPENDIX D 💀
X.25 Transport service
It may be possible to use the X.25 service [5], as provided by the Public Data Networks, directly. But there are indications that it's too error-prone to count as a reliable channel 😭. It is suggested that a reliable end-to-end protocol, such as TCP, be used on top of X.25 connections 🔥.
APPENDIX E: Theory of Reply Codes 🧠
okay so every reply has three digits and each one has its own job 💅. The first digit tells you if things went well, went badly, or are still in progress. Even a super basic sender-MTP can figure out what to do next (proceed, redo, retrench, etc.) just by looking at that first digit 🫶. If the sender-MTP wants a rough idea of what kind of error happened (like a mail system error or a command syntax error), it MAY look at the second digit. That leaves the third digit for the most detailed info 🔍
There are five possible values for the first digit:
1yzPositive Preliminary reply ⏸️: The command got accepted, but the action is on hold until the info in this reply gets confirmed. The sender-MTP SHOULD send another command saying whether to keep going or abort.2yzPositive Completion reply ✅: All done! The requested action worked. A new request MAY be started.3yzPositive Intermediate reply 🧩: The command got accepted, but the action is on hold until more info shows up. The sender-MTP SHOULD send another command with that info. This reply is used in command sequence groups.4yzTransient Negative Completion reply 🌦️: The command was not accepted and the action didn't happen. BUT the error is temporary, so the action MAY be requested again. The sender SHOULD go back to the beginning of the command sequence (if there is one). Honestly, "transient" is hard to pin down when two sites (the receiver-MTP and the sender-MTP) have to agree on what it means 🙃 Each reply in this group might have a different time value, but the sender-MTP is encouraged to try again. A handy rule of thumb: a reply is 4yz if the request can be repeated without changing the command form or anything about the sender or receiver. (For example, the command gets repeated exactly the same, or the receiver doesn't set up a new implementation.)5yzPermanent Negative Completion reply 🚫: The command was not accepted and the action didn't 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 on. That could be after the spelling gets fixed, or after the user changes their account status 🔧
The second digit sorts replies into specific categories:
x0zSyntax 📝: These replies cover syntax errors, commands that are syntactically correct but don't fit any functional category, and commands that are unimplemented or superfluous.x1zInformation ℹ️: These are replies to requests for info, like status or help.x2zConnections 🔌: These replies are about the transmission channel.x3zUnspecified as yet. 🫥x4zUnspecified as yet. 🫥x5zMail system 📬: These replies show the status of the receiver's mail system in relation to the requested transfer or other mail system action.
The third digit gives a finer level of detail within each category set by the second digit. The list of replies shows 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 a little different from the ones described here. Instead, they should adapt codes that are already defined 💜
For example, a command like NOOP that runs successfully but doesn't give the sender-MTP any new info will return a 200 reply. The response is 502 when the command asks for an unimplemented action that isn't site-specific. A refinement of that is the 504 reply, for a command that is implemented but asks for an unimplemented parameter 🌸
The reply text MAY be longer than one line. In those cases, the complete text MUST be marked so the sender-MTP knows when it can stop reading. This needs a special format to show a multi-line reply ✨
The format for multi-line replies says that every line except the last begins with the reply code, immediately followed by a hyphen, - (also known as minus), and then the text. The last line begins with the reply code, immediately followed by <SP>, then optionally some text, and then <CRLF>.
For example:
123-First line
123-Second line
123-234 text beginning with numbers
123 The last lineThe sender-MTP then just needs to look for the reply code followed by <SP> at the beginning of a line, and ignore all the lines before it 🧚
GLOSSARY 📖
ASCII 🔤
American Standard Code for Information Interchange [6].
command 🎯
A request for a mail service action, sent by the sender-MTP to the receiver-MTP.
host 🖥️
A computer in the internetwork environment where mailboxes or MTP processes live.
line 📏
A line of text ending with a <CRLF>.
mail 💌
A sequence of ASCII characters of any length, which conforms to the standard set in RFC 733 (Standard for the Format of ARPA Network Text Messages [7]).
mailbox 📮
A character string (address) that identifies a user who mail is to be sent to. A mailbox normally consists of the host and user specifications. The standard mailbox naming convention is defined to be "user@host". Additionally, the "container" in which mail is stored.
receiver-MTP process 📥
A process that transfers mail in cooperation with a sender-MTP process. It waits for a connection to be established via the transport service. It receives MTP commands from the sender-MTP, sends replies, and governs the transfer of mail.
reply 💬
A reply is an acknowledgment (positive or negative) sent from the receiver to the sender over the transmission channel in response to an MTP command. The general form of a reply is a completion code (including error codes) followed by a text string. The codes are for use by programs, and the text is usually intended for human users.
sender-MTP process 📤
A process that transfers mail in cooperation with a receiver-MTP process. A local language may be used in the user interface command/reply dialogue. The sender-MTP initiates the transport service connection. It initiates MTP commands, receives replies, and governs the transfer of mail.
transmission channel 🛣️
A full-duplex communication path between a sender-MTP and a receiver-MTP for exchanging commands, replies, and mail text.
transport service 🚚
Any reliable stream-oriented data communication service. For example, NCP, TCP, NITS.
user 🙋
A human being (or a process on behalf of a human being) who wants to obtain mail transfer service. In addition, a recipient of computer mail.
word 🔠
A human being (or a process on behalf of a human being) who wants to obtain mail transfer service. In addition, a recipient of computer mail.
<CRLF> ↩️
The characters carriage return and line feed (in that order).
<SP> ␣
The space character.
REFERENCES 📚
[1] TCP
Postel, J., ed., "DOD Standard Transmission Control Protocol", IEN 129, RFC 761, USC/Information Sciences Institute, NTIS ADA082609, January 1980. Appears in: Computer Communication Review, Special Interest Group on Data Communications, ACM, V.10, N.4, October 1980.
[2] NCP
McKenzie, A., "Host/Host Protocol for the ARPA Network", NIC 8246, January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978.
[3] Initial Connection Protocol
Postel, J., "Official Initial Connection Protocol", NIC 7101, 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978.
[4] NITS
PSS/SG3, "A Network Independent Transport Service", Study Group 3, The Post Office PSS Users Group, February 1980. Available from the DCPU, National Physical Laboratory, Teddington, UK.
[5] X.25
CCITT, "Recommendation X.25 - Interface Between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks," CCITT Orange Book, Vol. VIII.2, International Telephone and Telegraph Consultative Committee, Geneva, 1976.
[6] ASCII
ASCII, "USA Code for Information Interchange", United States of America Standards Institute, X3.4, 1968. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978.
[7] RFC 733
Crocker, D., J. Vittal, K. Pogran, and D. Henderson, "Standard for the Format of ARPA Network Text Messages," RFC 733, NIC 41952, November 1977. Also in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for the Defense Communications Agency by SRI International, Menlo Park, California, Revised January 1978. 🌈
📦 where this page comes from
- ietf: rfc780 1981-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms