RFC 491

What Is Free 🎀

Okay bestie, so this is RFC 491, and the title block has the tea ☕:

• RFC number: 491 💖
• Title: What Is Free ✨
• Network Working Group 🌸
• Author: M. A. Padlipsky, MIT-Multics 👑
• NIC number: 15356
• Date: 12 April 1973 🦋
• Category, obsoletes and updates: not listed in this document 🫶

Padlipsky is a legend, and this one is about mail and login. 💅

In at least three RFCs about mail and the File Transfer Protocol (RFC 454, 475, 479), people keep saying something like Network mail should be free; i.e., no login or USER command should be required. 😭 The "i.e" (=that is) is misleading, ngl. It does not follow that the only way mail can be free is to skip login. An explicit login on a free account would work just fine too 🧚. Depending on each Host's quirks in its Logger, Answering Service, and process creation setup, an explicit login might honestly be way more natural than an implicit one. Even where implicit login is easy, explicit login is just easy 💜.

Yes, logging in to a free account means users have to remember the free account's name. But that's not a huge ask if there's a reason to prefer explicit login and the free account has the same name on every Host. So, based on the idea that Network protocols shouldn't sneakily force "unnatural" setups on participating Hosts when that can be easily avoided, Padlipsky proposes this formulation:

   Network mail should be free.  Network mail should not require
   users to remember the name of the free account on a given system.
   I.e., it should either be "loginless" or it should take the same
   login everywhere.  But some systems need/want/prefer a login.
   Therefore, USER NETML / PASS NETML should be made to work
   everywhere for free mail.

Note: NETML is fewer than six characters and is upper case, so it should fit in the least common denominator category of user identifiers. It's also long enough not to conflict with anybody's initials (probably) 🙈

Now, this might sound like special pleading because of the implementation stuff, but the "incorrect" formulation has another problem that makes explicit login look even better for mail 🔥. The "loginless" view causes trouble for both the authentication and accounting parts of login, because it basically assumes the only point of login is to start accounting. RFC 475 runs into this when it notes that some systems let you put access control on mailboxes, then says the FTP USER command is wrong for access control because you'd be on the free account, and a new FTP FROM command would be right. (Presumably FROM would be followed by PASS.) 💀

Padlipsky is pretty familiar with one of the systems that does allow mailbox access control, so here's how it works. Permissible "principal identifiers" go on the mailbox's "access control list". When a process references the mailbox, the process's principal identifier has to match an entry on that list, either directly or as a member of a class. If it doesn't match, access is forbidden. The principal identifier is attached to the process at login. So yeah, it's probably a valid objection that accounting should be separated from authentication, but in practice it often isn't. So why invent a redundant mechanism based on the assumption that it is? 🤷‍♀️

Another point on authentication via login: someone has argued that FTP mail ought to be so cheap that it "can be buried in overhead". But by that same logic, if it's so cheap that it shouldn't bother anybody, then logging in on your own account to prove the mail is really from you shouldn't bother anybody either 🙃.

To be scrupulous, Padlipsky admits NETML might be repugnant to some Hosts. If that's the case, he proposes a new FTP FREE command so Servers don't have to treat MAIL as an implicit login. He gives at least two reasons 👀. First, when the "subcommands" to MAIL get worked out, some of them will have to come before MAIL (or users will get awfully tired of typing their names, etc.). So the list of commands that imply a login keeps growing, and Server FTPs will have to keep changing and changing 😩. Second, if MAIL implies a login, it'll be hard in some environments to pass the arguments to the process created for the mailer. And it's a really bad idea to assume the mailing can be handled by the process listening on socket 3 🚫. Even adding a new mechanism (see RFC 451 for his strong feelings against that kind of step in general) through FREE seems better than making all the assumptions the loginless option does 💅.

There's also an alternative to this whole line of reasoning: the FTP is internally inconsistent. In the definition of the USER command it acknowledges that some systems may require USER / PASS, but then in the discussion of mail it (mis)states that they may not. If that abstract point is more satisfying to some readers than the pragmatic argument above, well and good 🌈.

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie, 12/1999]