Internet Draft H. Alvestrand and R. Gellens, Authors Expires 22 May 1997 R. Gellens, Editor 22 November, 1996 draft-gellens-submit-02.txt SMTP Message Submission and 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-submit-02.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 to add Received headers. Alvestrand, Gellens Expires May 1997 [Page 1] Internet Draft SMTP Submission November 1996 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 messages to be identified as submissions or relays. 2. SUBMIT Servers To distinguish relay SMTP from submission, port XXXX is reserved as the SMTP SUBMIT port. Messages received on this port are assumed to be submissions, even though the protocol used is otherwise SMTP. However, in lieu of using this port, it may in certain cases be preferred to use the standard SMTP port (port 25) on a system dedicated for and known to be a SUBMIT server. When this is done, the SUBMIT server MUST NOT be listed as an MX record for any domain. Additionally, the SUBMIT server SHOULD verify that it is not configured as a normal SMTP server; when the MTA receives a mail message with a RCPT TO, it SHOULD query the DNS to verify that its IP address is not listed in any MX record for the domain specified in the RCPT TO command. If there are no MX records for that domain, the MTA SHOULD verify that its IP address is not listed in any A records for that domain. If either verification fails, the RCPT TO SHOULD be rejected, unless the local-part is "Postmaster" (case insensitive) and it knows where to forward postmaster mail. 3. SMTP Extension for Message Relay The name of this extension [ESMTP] is "Relay". The EHLO keyword is RELAY. One new optional parameter is defined for the MAIL FROM verb: RELAY. If RELAY is used with the MAIL FROM command, the message is to be treated as a relay. If RELAY appears in MAIL FROM for a message received on the SUBMIT port, the message MUST NOT be treated as a Alvestrand, Gellens Expires May 1997 [Page 2] Internet Draft SMTP Submission November 1996 submission; the MTA can either treat it as a relay or reject the MAIL FROM command with 504. (Although 504 is not listed in RFC 821 as a valid failure response to MAIL FROM, it seems to make the most sense, although cases can be made for 521 and 554). If RELAY was not used, and the message was received on the standard SMTP port (port 25), the MTA may either treat the message as a relay, or use the guidelines in section 8 to determine if the message is a submission or a relay. 4. 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. 5. Actions when the Message Is a Submission The following things MUST be done by the 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 the 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 rights, or is invalid. Failure code 554 should be used for this purpose. (2) Refuse the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known). Result code 554 should be used. (3) Add a 'Sender' field to the submitted message, if the identity of the sender is known 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. Alvestrand, Gellens Expires May 1997 [Page 3] Internet Draft SMTP Submission November 1996 (8) Resolve aliases (CNAME records) for domain names, in the envelope as well as the text, subject to local policy. For 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 and/or domains, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide logon names, and/or to rewrite 'squeeky.sales.xyz.com' as 'zyx'com' to hide machine names and make it easier to move users. If the MTA treats a message as a submission (see also section 8) 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. 6. 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. 7. Message Rejection 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, and/or to reject all message submissions which do not come from local users (based on IP address and/or authenticated identity). The MTA may be unable to comply with the requirements for relaying a submitted message. For example, the domain names in the message headers and/or envelope might be unqualified and either unknown or ambiguous, preventing the MTA from qualifying them. If the MTA is able to determine a return path to the submitting user (from a valid MAIL FROM, or based on authenticated identify), the MTA may either reject the message immediately, or accept it and issue a bounce. If the MTA is not able to determine a return path to the submitting user, it MUST immediately reject messages which it is unable to relay. A message can be immediately rejected by returning 554 to the MAIL FROM command or after receiving the final period. Alvestrand, Gellens Expires May 1997 [Page 4] Internet Draft SMTP Submission November 1996 8. 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 that MTA, and only submissions go through that MTA. 9. Security Considerations Security issues are not considered in this memo. 10. Acknowledgements This updated draft has been revised in part based on comments and discussions which took place on and off the IETF-SMTP mailing list. 11. References [AUTH] J. Myers, "Internet Draft: SMTP Authentication", Carnegie Mellon, draft-myers-smtp-auth-04.txt, November 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 Alvestrand, Gellens Expires May 1997 [Page 5] Internet Draft SMTP Submission November 1996 Institute, October 1989 [SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10, Information Sciences Institute, 08/01/1982 12. 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.619.651.5115 Qualcomm, Inc. +1.619.658.1560 (fax) 6455 Lusk Blvd. Randy@Qualcomm.Com San Diego, CA 92121 U.S.A. Alvestrand, Gellens Expires May 1997 [Page 6]