HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:04:27 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 08 May 1997 10:56:00 GMT ETag: "2e9a06-5ba2-3371b140" Accept-Ranges: bytes Content-Length: 23458 Connection: close Content-Type: text/plain Internet Draft: Message Submission and Relay R. Gellens Document: draft-gellens-submit-05.txt Qualcomm Expires: 8 November 1997 H. Alvestrand UNINETT 8 May, 1997 Message Submission and Relay Status of this Memo: 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). A version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Please send comments to the IETF Submit mailing list, . To subscribe, send a message containing SUBSCRIBE to . This document will expire before December 1997. Distribution of this draft is unlimited. The file name of this version is draft-gellens-submit-05.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' header fields. Gellens, Alvestrand Expires November 1997 [Page 1] Internet Draft Message Submission and Relay May 1997 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 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. This memo proposes a low cost, deterministic means for messages to be identified as submissions or relays, and specifies what actions are to be taken by a submission server. Separation of messages into submissions and relays can have many benefits for Internet mail in the short and long term. These benefits include allowing sites to more easily implement security policies and guard against unauthorized mail relaying (and spam injection), making it easier to detect configuration problems with a site's mail clients, providing a migration path to get relays out of the dangerous business of modifying mail, and providing a basis for adding additional functionality in the future. 2. SUBMIT Servers To distinguish relay SMTP from submission, port 587 is reserved as the MAIL SUBMIT port. Messages received on this port are assumed to be submissions, even though the protocol used is otherwise SMTP. The process which acts as a submission server will be referred to as a Message Submission Agent (MSA) to distinguish it from an MTA, which acts as a relay agent. 3. SMTP Extension for Message Relay Assertion In addition to providing for SMTP submission on a separate port from relay, to aid in migration this memo extends SMTP [ESMTP] to enable assertion that a message on port 25 is not a submission. The name of this extension is "Relay". The EHLO keyword is RELAY. One new optional parameter is defined for the MAIL FROM verb: RELAY. Gellens, Alvestrand Expires November 1997 [Page 2] Internet Draft Message Submission and Relay May 1997 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 submission; the MSA may either treat it as a relay or reject the MAIL FROM command with 504. If RELAY is not used, and the message is received on the relay 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 command 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 field. 5. Actions when the Message Is a Submission 5.1. General Rules 5.1.1. Even though various modifications to header fields are authorized in this memo, a paramount rule is that elements of structured header fields may only be modified when specific problems are recognized which have clear solutions. This is especially true with address elements. For example, indiscriminately appending '@foo.com' to an address or element which lacks an '@' results in more broken addresses. If an address lacks an '@', it must be verified to be a valid local part in the domain before the domain can be added. 5.1.2. It is better to reject than to risk damage. When a problem with a message is detected, and there is no specifically configured rule for the problem, it is better to reject the message than to attempt to fix it. This is especially true of problems which are correctable by the MUA (for example, an invalid 'From' field). In these situations, the MSA may either accept the message and subsequently issue a bounce, or use response code 554 to reject a MAIL FROM, RCPT TO, or DATA command which contains something improper. 5.2. Things which MAY Be Done by the MSA if the Message Is a Submission 5.2.1. Refuse the MAIL FROM command if the address in MAIL FROM is not Gellens, Alvestrand Expires November 1997 [Page 3] Internet Draft Message Submission and Relay May 1997 believed to have submission rights, or is invalid. Failure code 554 should be used for this purpose. 5.2.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. The MSA MAY instead accept the message and subsequently issue a bounce. 5.2.3. Add or replace a 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field. The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address. 5.2.4. Add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [RFC-822] syntax (as modified by [RFC-1123]). If the MSA adds or changes the 'Date' field, it SHOULD add a comment to the field indicating this. This is because an altered or MSA-created 'Date' field is likely to be misleading to the recipient. 5.2.5. Add a 'Message-ID' field to the submitted message, if it lacks it. 5.2.6. Transfer encode the message according to MIME conventions, if needed and not harmful to the MIME type. 5.2.7. Resolve aliases (CNAME records) for domain names, in the envelope as well as in address fields of the header, 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. 5.2.8. Rewrite local parts and/or domains, in the envelope as well as in address fields of the header, 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. However, only addresses which match specific local MSA configuration settings may be altered. The MSA MUST NOT apply data-independent rewriting rules, such as always deleting the first element of a domain name. 5.3. Things which MUST Be Done by the MSA if the Message Is a Submission Gellens, Alvestrand Expires November 1997 [Page 4] Internet Draft Message Submission and Relay May 1997 5.3.1. Ensure all domains (in the envelope as well as the text) are fully-qualified. Single-level domains (for example, 'sales') MAY be expanded based on local configuration (for example, to 'sales.foo.com'). Multi-level domains which are not fully-qualified (for example, 'sales.foo') MUST be rejected, not expanded. Response code 554 should be used to reject a MAIL FROM, RCPT TO, or DATA command which contains improper domains. The MSA MAY instead accept the command and subsequently issue a bounce. 5.3.2. Reject messages with detectably illegal syntax in a sender or recipient address. This applies after any address transformations have been done. Response code 554 should be used to reject a MAIL FROM, RCPT TO, or DATA command which contains improper domains. The MSA MAY instead accept the message and subsequently issue a bounce. 5.3.3. Use the RELAY parameter to the MAIL FROM command when relaying the message, if the server MTA understands ESMTP and supports the RELAY extension. 5.4. Things which MUST NOT Be Done by the MSA if the Message Is a Submission 5.4.1. Alter already valid headers or text in ways not authorized by this memo. However, the MSA MAY reject or bounce messages which violate site policy in some way. (For example, messages which appear to contain proprietary information) 5.5. Things which SHOULD Be Done by the MSA if the Message Is a Submission 5.5.1. Log message errors, especially apparent misconfigurations of client software. It can be very helpful to notify the local postmaster when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: local postmasters are likely to be interested in local configuration problems, but not in client problems at other sites. 5.5.2. If the MSA treats a message as a submission (see also section 8) and as a result modifies the contents of any structured header fields or makes other significant changes, it SHOULD document all such alterations by adding one or more 'Change-History' header fields. 'Change-History' is a structured header field which allows an MSA to Gellens, Alvestrand Expires November 1997 [Page 5] Internet Draft Message Submission and Relay May 1997 list the changes it made, and to provide trace and contact information should problems with its changes be detected. All parameter names and parameter values are case-insensitive, unless otherwise noted. 5.5.3. Parameters of 'Change-History' The following parameters are defined for the 'Change-History' header field. Additional parameters may be defined in the future, and will be registered with IANA. Names beginning with 'X' or 'x' are reserved for non-standard parameters. Other names are reserved for standard parameters. 5.5.3.1. The 'Contact-Domain' parameter 'Contact-Domain' is a required parameter. It specifies a FQDN, the postmaster of which is the contact point for problems detected by the recipient of the message. 5.5.3.2. The 'MSA' parameter While 'MSA' is an optional parameter, either it or 'MSA-Identity-Token' is required. 'MSA' lists the FQDN of the MSA. 5.5.3.3. The 'MSA-Identity-Token' parameter While 'MSA-Identity-Token' is an optional parameter, either it or 'MSA' is required. 'MSA-Identity-Token' is any string which is sufficient for the postmaster at the contact domain to identify the software which modified the message. This parameter value must be treated as case sensitive; that is, its case must be preserved. This allows the generating site to use values which are either case sensitive or insensitive. 5.5.3.4. The 'Date' parameter 'Date' is required and contains the time and date at which the change was made, using syntax as in [RFC-822] and [RFC-1123]. 5.5.3.5. The 'Element' parameter The 'Element' parameter is required and identifies which header field or envelope item was changed. If the body was changed (for example, upgraded to MIME and content-transfer-encoded), 'body' should be specified. If a multi-valued field or item (such as an address field) was changed, the specific element MAY be indicated by appending a dot and an integer. For example, the first address in Gellens, Alvestrand Expires November 1997 [Page 6] Internet Draft Message Submission and Relay May 1997 'To' would be 'To.1', and the first RCPT TO would be 'RCPT.1'. 5.5.3.6. The 'Action' parameter The 'Action' parameter is required and specifies the type of change: 'Added', 'Expanded', 'Quoted', 'Unquoted', 'Changed', or 'Removed'. 5.5.3.7. The 'Cause' parameter The 'Cause' parameter optionally identifies the justification for the change: 'Bad-Syntax', 'Incorrect', 'Missing', 'Nickname', or 'Policy'. 5.5.3.8. The 'Original' parameter 'Original' is an optional parameter which contains the value of the field before any changes were made. 5.5.4. ABNF for 'Change-History' This defines the syntax for the 'Change-History' header field using terminals as specified in RFC 2045 [MIME-IMB]: change-history ::= "Change-History:" parameter *(";" parameter) parameter ::= action / contact-domain / cause / date / element / msa / msa-identity-token / original action ::= "Action" "=" ("Added" / "Changed" / "Expanded" / "Quoted" / "Removed" / "Unquoted") contact-domain ::= "Contact-Domain" "=" cause ::= "Cause" "=" ("Bad-Syntax" / "Incorrect" / "Missing" / "Nickname" / "Policy") date ::= "Date" "=" element ::= field / envelope envelope ::= "Envelope" "=" ("MAIL" / "RCPT") field ::= "Field" "=" ("body" /
) msa ::= "MSA" "=" Gellens, Alvestrand Expires November 1997 [Page 7] Internet Draft Message Submission and Relay May 1997 msa-identity-token ::= "MSA-Identity-Token" "=" value original ::= "Original" "=" value 5.5.11. Examples of 'Change-History' Change-History: Date="Fri, 20 March 1997 19:32 +0800"; MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Envelope=MAIL; Action=Changed; Cause=Policy Change-History: Date="Fri, 20 March 1997 19:32 +0800"; MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Envelope=RCPT.1; Action=Expanded; Cause=Nickname; Original=Foo Change-History: Date="Fri, 20 March 1997 19:32 +0800"; MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=To.1; Action=Expanded; Cause=Nickname; Original=Foo Change-History: Date="Fri, 20 March 1997 19:32 +0800"; MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=From; Action=Changed; Cause=Policy 6. Interaction with Other SMTP Extensions Extended Status Codes [SMTP-CODES], if supported and used according to [CODES-EXTENSION], permits the MSA to notify the client of specific configuration or other problems. In particular, when result code 554 is used to reject a MAIL FROM, RCPT TO, or DATA command, or if 504 is used to reject a MAIL FROM command, the codes defined in [SMTP-CODES] will be helpful. Methods have been proposed which would allow for SMTP authentication. These extensions, if supported and used, would allow the MSA to validate the authority and 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 and MSA 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 MSA may be unable to comply with the requirements for relaying a submitted message. For example, the domain names in the message Gellens, Alvestrand Expires November 1997 [Page 8] Internet Draft Message Submission and Relay May 1997 headers and/or envelope might be unqualified and either unknown or ambiguous, preventing the MSA from qualifying them. If the MSA is able to produce a valid message, it may either reject the message immediately, or accept it and issue a bounce. If the MSA is not able to determine a return path to the submitting user (from a valid MAIL FROM, or based on authenticated identify), it MUST immediately reject the message. A message can be immediately rejected by returning 554 to the MAIL FROM command or after receiving the final period. 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: 8.1. The message lacks any 'Received' fields. 8.2. The message comes from a host known to the MTA as being a "pure client", such as a PC. 8.3. The message lacks a 'Date' field. 8.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 Separation of submission and relay of messages can allow a site to implement more secure policies. This can aid in tracking spam, and can allow a site to ensure that it is not used as a spam injection point by outsiders. For example, a site could configure its MSA to require authentication before accepting a message, and could configure its MTA to reject all RCPT TOs for non-local users. This can be an important element in a site's total email security policy. The 'Change-History' header field allows for problem tracking and reporting, through use of the 'Contact-Domain' parameter with either the 'MSA' or the 'MSA-Identity-Token' parameter. Sites wanting to prevent disclosing details of their local network (such as the identities of local servers) should use 'MSA-Identity-Token', while sites without these concerns can use the simpler 'MSA' parameter. 10. Acknowledgments This updated draft has been revised in part based on comments and Gellens, Alvestrand Expires November 1997 [Page 9] Internet Draft Message Submission and Relay May 1997 discussions which took place on and off the IETF-Submit mailing list. 11. References [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, [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, Innosoft, October 1996, [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octel Network Services, January 1996, [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996, [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, Stockholm University/KTH, February 1997, 12. Authors' Addresses Randall Gellens +1.619.651.5115 Qualcomm, Inc. +1.619.651.5334 (fax) 6455 Lusk Blvd. Randy@Qualcomm.Com San Diego, CA 92121-2779 U.S.A. Harald Tveit Alvestrand +47 73 59 70 94 Gellens, Alvestrand Expires November 1997 [Page 10] Internet Draft Message Submission and Relay May 1997 UNINETT Harald.T.Alvestrand@uninett.no P.O.Box 6883 Elgeseter N-7002 TRONDHEIM NORWAY Gellens, Alvestrand Expires November 1997 [Page 11]