Browse Prior Art Database

Responses to critiques of the proposed mail protocol (RFC0555)

IP.com Disclosure Number: IPCOM000004935D
Original Publication Date: 1973-Jul-27
Included in the Prior Art Database: 2001-Jul-12
Document File: 12 page(s) / 22K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.E. White: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 17% of the total text.

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).

I. QUESTIONS

HOW DOES THE SERVER VERIFY AN ID?

References:

(DHC JBP RFC 539 17644,3g:gy)

Discussion:

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

Example:

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 '.

UCLA-NMC's server then connects to the NIC's server, invokes the User Verification function there, specifying 'REQUESTOR roberts usc-isi ' and 'ID arpawheel '. 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...