Internet Draft H. Alvestrand and R. Gellens, Authors Expires 28 February 1997 R. Gellens, Editor 28 August, 1996 draft-gellens-smtp-submit-01.txt SMTP Extension for Message Submission/Relay Status of this Memo: This draft document is being circulated for comment. Please send comments to the IETF SMTP mailing list, . To subscribe, send a message containing SUBSCRIBE IETF-SMTP to . The following text is required by the Internet-draft rules: This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet Drafts shadow directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The file name of this version is draft-gellens-smtp-submit-01.txt 1. Introduction SMTP was defined as a message *relay* protocol, that is, a means for message transfer agents (MTAs) to route finished (complete) messages. SMTP forbids MTAs from altering the message text, except Alvestrand, Gellens Expires February 1997 [Page 1] Internet Draft Submit SMTP August 1996 to add Received headers. However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. Regardless of whether this is good or bad, it is far too late to change. Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished (incomplete) messages need to be completed to ensure they conform to [RFC-822], [RFC-1123], and later requirements. For example, the message may lack proper Date or Message-ID headers, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished (complete) messages (for example, it might not know its time zone). Even when submitted messages are finished (complete), local site policy may dictate that the message text be modified in some ways. Such completions or modifications violate the letter and spirit of SMTP when used as a relay protocol. This memo proposes a low cost, deterministic means for an MTA to be informed how SMTP is being used (submission or relay mode). 2. SMTP Extension for Message Submission or Relay The name of this extension [ESMTP] is "Message Mode". The EHLO keyword is MODE. One new parameter is defined for the MAIL FROM verb: MODE. It has a required value, which must be either SUBMIT or RELAY. If SUBMIT is used with the MAIL FROM command, the message is to be treated as a submission. If RELAY is used, the message is to be treated as a relay. In addition to supporting the MODE extension, an MTA MAY choose to receive messages on an additional port, port X. If so, all messages received using port X are to be treated as submissions. This is for the benefit of clients which do not use EMSTP but which can be easily configured to use a port other than 25. If neither SUBMIT nor RELAY is used, and the message was received on the standard SMTP port (port 25), the MTA may either unconditionally treat the message as a relay, or use the guidelines in section 6 to determine if the message is a submission or a relay. Alvestrand, Gellens Expires February 1997 [Page 2] Internet Draft Submit SMTP August 1996 3. Actions when RELAY Is Used If the MAIL FROM line has the RELAY parameter, the MTA is being informed that this message is being relayed, and therefore the letter and spirit of SMTP MUST be followed. The MTA MUST not alter the text, except to add a Received header. The MTA MAY choose to implement message rejection rules which rely in part on whether the message is a submission or a relay. For example, some sites might configure their MTA to reject all RCPT TOs for messages being relayed which do not reference local users. 4. Actions when the Message Is a Submission The following things MUST be done by an MTA if the message is a submission: (1) Ensure all domains (in the envelope as well as the text) are fully-qualified. The following things MAY be done by an MTA if the message is a submission: (1) Refuse the MAIL FROM command if the address in MAIL FROM is not believed to have submission right at this MTA, or is invalid. (2) Refuse the DATA command if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known). (3) Add a 'Sender' field to the submitted message, if it knows the identity of the sender and this is not given in the 'From' field. (4) Add a 'Date' field to the submitted message, if it lacks it. (5) Correct the 'Date' field if it does not conform to [RFC-822] syntax (as modified by [RFC-1123]). (6) Add a 'Message-ID' field to the submitted message, if it lacks it. (7) Transfer encode the message according to MIME conventions, if desirable and needed (8) Resolve aliases (CNAME records) for domain names, in the envelope as well as the text, subject to local policy. For Alvestrand, Gellens Expires February 1997 [Page 3] Internet Draft Submit SMTP August 1996 example, if www.ab.com and ftp.ab.com are both aliases for mail.ab.com, rewriting them could lose useful information. (9) Rewrite local parts, according to local policy. For example, a site may prefer to rewrite JRU as J.Random.User in order to hide logon names. (10) Add a 'Content-MD5' field to the submitted message, if it lacks it. If an MTA treats a message as a submission (see also section 6) and modifies its text in any way as a result, it SHOULD document all such alterations by one or more of the following: (1) Add a comment to each added or altered field, of the form "(added/corrected by MTA )". (2) Add a 'Comments' field which lists what alterations were made, the reason why each was done, and the domain name of the MTA. 5. Interaction with Other SMTP Extensions The SMTP [AUTH] extension, if supported and used, may allow the MTA to determine the identity of the submitting user. 6. Possible Other Cases for Treating Messages as Submissions For backwards compatibility with older mailers and MTAs, the MTA MAY consider the message a submission, and treat it as above, under some combinations of the following circumstances: (1) The message lacks any 'Received' fields. (2) The message comes from a host known to the MTA as being a "pure client", such as a PC. (3) The message lacks a 'Date' field. (4) The MTA knows that all of its messages are submissions. For example, an MTA and all clients might be configured so that all submissions go through the MTA, and only submissions go through that MTA. Alvestrand, Gellens Expires February 1997 [Page 4] Internet Draft Submit SMTP August 1996 6. Security Considerations Security issues are not considered in this memo. 7. Acknowledgements This updated draft has been revised in part based on comments and discussions which took place on the IETF-SMTP mailing list. 8. References [AUTH] J. Myers, "Internet Draft: SMTP Authentication", Carnegie Mellon, draft-myers-smtp-auth-02.txt, January 1996, work in progress. [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1869, STD 10, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, November 1995 [RFC-822] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, STD 11, University of Delaware, 08/13/1982 [RFC-1123] R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989 [SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10, Information Sciences Institute, 08/01/1982 8. Authors' Addresses Harald Tveit Alvestrand +47 73 59 70 94 UNINETT Harald.T.Alvestrand@uninett.no P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY Randall Gellens +1.714.380.6350 Alvestrand, Gellens Expires February 1997 [Page 5] Internet Draft Submit SMTP August 1996 Unisys Corporation +1.714.380.5912 (fax) 25725 Jeronimo Road Randy.Gellens@MV.Unisys.Com Mail Stop 237 Mission Viejo, CA 92651 U.S.A. Alvestrand, Gellens Expires February 1997 [Page 6]