The RFC Archive
 The RFC Archive   RFC 539   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 539

Thoughts on the mail protocol proposed in RFC 524

Last modified on Thursday, March 9th, 2000

Permanent link to RFC 539
Search GitHub Wiki for RFC 539
Show other RFCs mentioning RFC 539







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 top


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 top

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 top

Thoughts on the mail protocol proposed in RFC 524 RFC TOTAL SIZE: 6213 bytes PUBLICATION DATE: Thursday, March 9th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 539: The IETF Trust, Thursday, March 9th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement