RFC 539

RFC 539: Thoughts on the Mail Protocol Proposed in RFC 524 💖

okay bestie, this one is from D. Crocker and J. Postel, both at UCLA-NMC 🦋 It's part of the Network Working Group, filed as Request For Comment #539 (NIC 17644), dated July 9, 1973. It responds to RFC 524, which shows up in the header as References: 524. The header doesn't say it obsoletes or updates anything, so we won't claim it does 🙈

---

Generally, we feel the protocol is extremely rich ✨ We also feel there are some minor and some major problems, so let's go through them 💅

The minor points first 🎀

1. <CA> and <CA2> don't get explained until the formal syntax, which is a lot of waiting. It would be way more convenient if they were explained sooner.
2. The proposed <CA2> is a bad thing, since it's the Telnet Go-Ahead, which should not be used by higher level protocols 🙅‍♀️
3. The default SIGNATURE should be the sign-on or ident of the author(s) 🖊️
4. The Disposition INTERRUPT would be more useful if it had author/clerk-assigned "levels". Right now mail is either urgent or not. With levels (say 1 to 10), the sender could rate how urgent it is 🔥

There would be no precisely defined meaning for any of these levels, just the chance for the sender to make a subjective call. The receiver (process or person) can do whatever they want with that info 🫶

A user could then tell their receiving process to notify them right away about Priority 5 or higher Short mail, or any Priority 10 mail, but to hold off on notifying for any other mail. (Length is discussed later in this note.) 🌸

5. Also, we'd like the word "INTERRUPT" changed to URGENT or PRIORITY 💜
6. Continuing the whole "rate your mail" vibe, we'd like to let the sender warn the receiver about the size of the mail. This could be a byte count and/or an imprecise SHORT/MEDIUM/LONG. Again, the receiver can use this info however it sees fit 📦
7. The ID command seems confusing 😵‍💫

Imagine I'm a clerk sending to someone on another host, and that host asks me to "prove" my identity by using an ID. How can the Sigma-7 at UCLA-NMC know WHITE's id? He doesn't have one on the Sigma, but he should totally be able to send mail to us there 🥺

8. How do ACK's, Progress Reports, or Replies work when there's no Reference Serial number? 🤔
9. Please include the distinction between Static and Dynamic attributes as part of the formal syntax 📝
10. Hosts must be allowed to require a login before they accept mail, but we'd love for the Protocol document to show a negative attitude toward that requirement 🙃
11. When describing defaults, cryptic phrases like "Author to the Clerk" are sometimes used. Please be a bit clearer 🙏
12. The sender is required to send Static, then Dynamic, and then Optional parameters.

This forces receiving hosts to buffer the contents before passing them on to the right recipient. (Actually, before they even find out whether they can/will accept the mail.) 😩

The order should be: Dynamic, Optional, Static ✨

If the sending host transmits the dynamic and optional attributes first, the receiving host can also reroute mail based on its Priority and Length 🦋

---

The hairier problems 😭

1. We'd love to make a strong statement in favor of the unified-access approach (one selector process with one listening socket). However, since it doesn't exist yet:

The Mail Protocol should NOT be a subsystem of FTP. The Mail Protocol uses the File Transfer Protocol, the same way RJE uses FTP. So we suggest using the RJE model 🌈

This unfortunately opens up the issue of logging in to send mail. The advantage of FTP having a MAIL command is that it defines a class of data transfer that many hosts will allow for free, while still keeping control over other, "normal" file transfer 👑

The solution should be the same as the one RJE currently uses ⭐

2. The FORWARD function lets a site receive and hold mail during and/or until a transfer request comes in from the "recipient" at another host 📬

This action happens AFTER the mail is received, so we'd like to suggest a command for "Rerouting" mail just PRIOR to its receipt 🧚

That lets a receiving host refuse a given piece of mail but suggest an alternate receiver. This would be useful if the recipient were using another host for a while, or if they didn't want to rack up storage charges at the first site 💀

Three variations can occur, one of which will require a special MP reply code:

• Automatic forwarding: Accept the mail, then automatically transfer it to the user's alternate mailbox.

This could be classed as a user "feature" and wouldn't be part of the protocol. It would still be quite useful 🍓

• Automatic forwarding with copy held: The same as the first case, but the transferring server keeps a copy of the mail.
• Rerouting without accepting: The mail is never accepted from the sender. The sender is, however, informed of an alternate mailbox.

The Rerouting information would come in reply to a RECIPIENT command. The reply looks like this:

476 <recipient> IS AT <pathname>

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 10/99 ]