I remember reading some early RFC's that suggested pre-SMTP, remote "email" was "sent" using FTP. Perhaps it was something like a PUT command to append to a us

I remember reading some early RFC's that suggested pre-SMTP, remote "email" was "sent" using FTP. Perhaps it was something like a PUT command to append to a user's "mail" file on the recipient computer? This seems to suggest email was always envisioned as something to be "received" rather that voluntarily "retrieved". In retrospect, knowing what happened to email, the later idea (e.g., djb's proposal) makes more sense. The funny part is that even though the "receive" idea is still the core part of the email process, that is not what email users do in practice. Users "retrieve" their mail from some third party who receives it for them. First there was "POP" then there was "webmail". Back in the Stone Age when email was "invented" computers were too expensive for the users to own. Each user shared the computer with other users. Each had an email account, usually administered by the organization that owned the expensive computer. Today computers are inexpensive and seemingly all users own one but they still do not have control of their email accounts. Some organization is still receiving all their mail before they do. And keeping a copy of course. :) Then, in more recent history, the domain name "business" (a monopoly run by an organization that derives its "authority" from nowhere), fueled by the popularity of the "www", became the gatekeeper to email. When was the last time you sent an email to user@[ipaddr]? Originally if my memory of the old RFC's is correct that was how it worked. No domain name needed. Today, if there is no purchased, monopoly-blessed "domain name", then according to the people who control users' email there is no "valid" email address. No pay, no play. Even if port 25 is open. Assuming a user who has paid for access to the "internet" wants control of their own email (seems reasonable), then "email" is still an addtional fee.