diff options
Diffstat (limited to 'doc/rfc/rfc539.txt')
| -rw-r--r-- | doc/rfc/rfc539.txt | 171 |
1 files changed, 171 insertions, 0 deletions
diff --git a/doc/rfc/rfc539.txt b/doc/rfc/rfc539.txt new file mode 100644 index 0000000..50caf19 --- /dev/null +++ b/doc/rfc/rfc539.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group D. Crocker (UCLA-NMC) +Request For Comment: #539 J. Postel (UCLA-NMC) +NIC 17644 July 9, 1973 +References: 524 + + + Thoughts on the Mail Protocol Proposed in RFC 524 + + +Generally, we feel that the protocol is extremely rich. We also feel +that there are some minor and some major problems. + +The minor points first: + + 1. <CA> and <CA2> are not explained until the formal syntax. It + would be more convenient, if they were explained sooner. + + 2. The Proposed <CA2> is a bad thing, since it is 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". Currently mail would be either + urgent or not. With levels (say 1 to 10), the sender could rate the + degree of urgency. + + There would be no precise defined meaning to any of these + levels, merely the opportunity for a subjective evaluation by + the sender. The receiver (process or person) may do whatever + they wish with the information. + + A user could thereby direct a receiving process to notify him + immediately of Priority 5 or higher Short mail or any Priority + 10 mail immediately, but defer notification of any other mail. + (Length is discussed later in this note.) + + 5. Also, we would like the word, "INTERRUPT", to be changed to + URGENT or PRIORITY + + 6. In keeping with offering the sender the opportunity to 'rate' his + mail, we would like to allow him the chance to warn the receiver of + the size of the mail. This could be a byte count and/or an + imprecise SHORT/MEDIUM/LONG. Again, the receiver may use this + information as he/it sees fit. + + + + + +D. Crocker & Postel [Page 1] + +RFC 539 Thoughts on the RFC 524 Mail Protocol July 1973 + + + 7. The ID command seems confusing. + + If I am a clerk and sending to someone on another host, that + host may ask me to 'prove' my identity by using an ID. How can + the Sigma-7 at UCLA-NMC know WHITE's id? He does not have one on + the Sigma, but certainly should be able to send mail to us + there. + + 8. How do ACK's, Progress Reports, or Replies work when there is no + Reference Serial number? + + 9. Please include the distinction between Static and Dynamic + attributes as part of the formal syntax. + + 10. Though hosts must be allowed to require a login, before they + will accept mail, would like the Protocol document to reflect a + negative attitude towards such a requirement. + + 11. In describing defaults, relatively cryptic phrases such as + "Author to the Clerk" are sometimes used. Please be a bit more + clear. + + 12. The sender is required to send Static, Dynamic, and then + Optional parameters. + + This requires receiving hosts to buffer the contents before + passing them on to the appropriate recipient. (In fact, before + finding out whether it can/will accept the mail.) + + The order should be: Dynamic, Optional, Static. + + By requiring the sending host to transmit the dynamic and + optional attributes first, the receiving host can also reroute + mail based upon its Priority and Length. + +Now for the hairier problems: + + 1. We would like to make a strong statement in favor of the + unified-access (one selector process with one listening socket) + approach. However, since it does not exist, yet: + + The Mail Protocol should NOT be a subsystem of FTP. The Mail + Protocol USES the File Transfer Protocol, the same as RJE uses + FTP. We therefore suggest the use of the RJE model. + + This unfortunately opens up the issue of logging in, to send + mail. The advantage of having FTP have a MAIL command is that it + defines a class of data transfer which many hosts will allow for + + + +D. Crocker & Postel [Page 2] + +RFC 539 Thoughts on the RFC 524 Mail Protocol July 1973 + + + free, while maintaining control over other, 'normal' file + transfer. + + The solution should be the same as that currently used by RJE. + + 2. The FORWARD function allows a site to receive and hold mail + during and/or, until a transfer request is received from the + 'recipient' at another host. + + This action takes place AFTER receipt of the mail, so we would + like to suggest a command for "Rerouting" mail just PRIOR to its + receipt. + + This allows a receiving host to 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 the + recipient didn't want to rack up storage charges at the first + site. + + Three variation can occur, one of which will require a special + MP reply code: + + Automatic forwarding: Accept the mail and then + automatically transfer it to the user's alternate mailbox. + + This could be classed as a user "feature" and would + not be part of the protocol. However, it would 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 be in reply to a + RECIPIENT command. + + 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 ] + + + + + +D. Crocker & Postel [Page 3] + |