Responses to critiques of the proposed mail protocol (RFC0555)
Original Publication Date: 1973-Jul-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
Network Working Group James E. White (JEW) Request for Comments: 555 SRI-ARC NIC: 17993 July 27, 1973
Response to Critiques of the Proposed Mail Protocol
A number of people have responded to my proposal for a Mail Protocol (JEW RFC 524 -- 17140,2:y). In the current RFC, I’ve attempted to collect and respond to the questions, complaints, and suggestions that various individuals in the Network community have offered. I intend to critique myself in a forthcoming RFC.
I hope that dialog on the protocol proposal will continue, and that others will join in the discussion. I will respond via RFC to any additional critiques I receive (I hope there’ll be many).
HOW DOES THE SERVER VERIFY AN ID?
(DHC JBP RFC 539 -- 17644,3g:gy)
One postulates the existence of AT LEAST ONE host whose Mail server process implements the User Verification Function (JEW RFC 524 -- 17140,5f7:gy). Any process can contact that server, give him the name of any Individual in the Net and a test Id, and the server will determine whether or not the Individual and Id agree.
The NIC, for one, will without question provide this service.
With such support available to it, ANY FTP server process can then require (of any or all user processes that contact it) an ID command wherever it wishes within the user-server interchange (within the constraints of the Protocol). The server simply prompts for the Id, gets it, opens a connection to the User Verification Agent, presents to it the Individual’s name and purported Id, receives a positive or negative response, and deals with the original user process accordingly.
White [Page 1]
RFC 555 Response to Critiques of Proposed Mail Protocol July 1973
Suppose a user process opens a connection to UCLA-NMC’s server process, invokes the Delivery function, and in the course of the interchange identifies the Author as Roberts at USC-ISI.
The implementors at UCLA-NMC’s server process chose to require proof, in all Delivery transactions, that the Author is who he claims he is. It therefore prompts for an Id in response to the AUTHOR command from the user process, and receives in return the command ’ID arpawheel <CA>’.
UCLA-NMC’s server then connects to the NIC’s server, invokes the User Verification function there, specifying ’REQUESTOR roberts @ usc-isi <CA>’ and ’ID arpawheel <CA>’. The NIC informs UCLA-NMS that the Id is incorrect.
UCLA-NMC then rejects the original ID command.
Of course, the Protocol does not require that a server demand Ids from users that contact it. Servers who choose not to require proof of identity simply never prompt for ID commands, and treat any they receive as NOPs. For such implementations (which represent the current, FTP mail protocol situation), no third-part interchanges are ever required.
Each user in the Net has a single Id that he uses throughout the Net for purposes of sending and receiving mail. That Id need not (but may, either coincidentally or by design) have any othe...