Internet Draft: Message Submission R. Gellens Document: draft-gellens-submit-07.txt QUALCOMM Incorporated Expires: 14 November 1998 J. Klensin MCI 14 May 1997 Message Submission 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), ftp.ietf.org (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. Public comments should be sent to the IETF Submit mailing list, . To subscribe, send a message containing SUBSCRIBE to . Private comments can be sent to the authors. This version reflects comments received during Last Call. Copyright Notice Copyright (C) The Internet Society 1998. All Rights Reserved. Table of Contents 1. Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Information . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions of Terms Used in this Memo. . . . . . . . . . . . . 4 2.2. Conventions Used in this Document . . . . . . . . . . . . . . . 4 2.3. Changes from Previous Version . . . . . . . . . . . . . . . . . 5 3. Message Submission Protocol . . . . . . . . . . . . . . . . . . . 5 Gellens & Klensin Expires November 1998 [Page 1] Internet Draft Message Submission May 1998 3.1. Submission Port . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . . . . . 5 3.3. Message Modification. . . . . . . . . . . . . . . . . . . . . . 6 3.4. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. General Submission Rejection Code . . . . . . . . . . . . . . . 7 4.2. Ensure All Domains are Fully-Qualified. . . . . . . . . . . . . 7 4.3. Enforce Address Syntax . . . . . . . . . . . . . . . . . . . . . 8 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Be the Only MSA . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Add 'Change-ID' and 'Change-History'. . . . . . . . . . . . . . 8 5.3. Log Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Optional Actions. . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . . . 9 6.2. Require Authentication. . . . . . . . . . . . . . . . . . . . . 9 6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Check Message Data. . . . . . . . . . . . . . . . . . . . . . . 9 7. Submission Extension Mechanism . . . . . . . . . . . . . . . . . 10 7.1. SUBM Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. SUBM Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Interaction with SMTP Extensions . . . . . . . . . . . . . . . . 11 9. Change-ID and Change-History . . . . . . . . . . . . . . . . . . 12 9.1. Parameters of Change-ID. . . . . . . . . . . . . . . . . . . . 12 9.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1.2. MSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1.3. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1.4. Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Parameters of Change-History . . . . . . . . . . . . . . . . . 13 9.2.1. Element. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2.2. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2.3. Cause. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2.4. Original . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2.5. Result . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.3. ABNF for Change-ID . . . . . . . . . . . . . . . . . . . . . . 14 9.4. ABNF for Change-History. . . . . . . . . . . . . . . . . . . . 15 9.5. Common ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.6. Examples of Change-ID and Change-History . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Registration Procedures . . . . . . . . . . . . . . . . . . . 16 10.1.1. Change-ID and Change-History . . . . . . . . . . . . . . . . 16 10.1.2. Submit. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.2. Change Control . . . . . . . . . . . . . . . . . . . . . . . . 17 10.3. Registration Template . . . . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 21 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 16. Appendix: Message Modifications. . . . . . . . . . . . . . . . 21 16.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . . . . 22 16.2. Add 'Date'. . . . . . . . . . . . . . . . . . . . . . . . . . 22 16.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . . . . 22 Gellens & Klensin Expires November 1998 [Page 2] Internet Draft Message Submission May 1998 16.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . . . 22 16.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . . . 22 16.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . . . 22 16.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . . . 22 16.8. Header Rewriting. . . . . . . . . . . . . . . . . . . . . . . 23 1. Abstract SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA]. 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. Originally, users connected to servers from terminals, and all processing occurred on the server. Now, a split-MUA model is common, with MUA functionality occurring on both the user's own system and the server. Protocols such as POP or IMAP provide one side of the split-MUA architecture. SMTP has been used for the submission side. This memo proposes that the submission protocol defined here be used instead. 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 [MESSAGE-FORMAT], and later requirements. For example, the message may lack proper 'Date' or 'Message-ID' header fields, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be modified in some ways. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality. Separating messages into submissions and transfers allows developers and network administrators to more easily: * Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail * Implement authenticated submission, including off-site submission by authorized users such as travelers Gellens & Klensin Expires November 1998 [Page 3] Internet Draft Message Submission May 1998 * Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission * Provide a migration path to get MTAs out of the dangerous business of modifying mail * Detect configuration problems with a site's mail clients * Provide a basis for adding enhanced submission services in the future This memo proposes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. 2. Document Information 2.1. Definitions of Terms Used in this Memo Fully-Qualified Containing or consisting of a domain which can be globally resolved using the global Domain Name Service; that is, not a local alias or partial specification. Message Submission Agent (MSA) A process which conforms to this specification, which acts as a submission server to accept messages from MUAs, and either delivers them or acts as an SMTP client to relay them to an MTA. Message Transfer Agent (MTA) A process which conforms to [SMTP-MTA], which acts as an SMTP server to accept messages from an MSA or another MTA, and either delivers them or acts as an SMTP client to relay them to another MTA. Message User Agent (MUA) A process which acts (usually on behalf of a user) to compose and submit new messages, and process delivered messages. In the split-MUA model, POP or IMAP is used to access delivered messages. 2.2. Conventions Used in this Document In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only. Gellens & Klensin Expires November 1998 [Page 4] Internet Draft Message Submission May 1998 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS]. 2.3. Changes from Previous Version o Message modifications moved into advisory appendix. o RELAY SMTP extension removed. o SUBM extension mechanism more clearly defined. o Change-ID and Change-History SHOULDs not MUSTs. o Example domains end in ".gork" instead of ".com" o Date-time, domain, and local-part ABNF use RFC 821/822. o Added text making it clear the "X-" convention is not used. o Added text to clearly permit MAIL FROM <>. o SMTP extension table uses SHOULD / MUST NOT / MAY. o "Nickname" changed to "Alias". o "MSA" Change-ID parameter simplified. o Numerous rearrangements and miscellaneous cleanups. o Acknowledgments updated. 3. Message Submission Protocol 3.1. Submission Port Port 587 is reserved for the mail Submit protocol as defined in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with modifications as specified in this document. 3.2. Message Rejection and Bouncing MTAs and MSAs MAY implement message rejection rules that 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 that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, based on IP address, or authenticated identity. When a problem with a message is detected, and the MSA has no rule specifically configured for that problem, the MSA SHOULD reject the message rather than attempt to fix it. NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field. If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA MUST immediately reject the Gellens & Klensin Expires November 1998 [Page 5] Internet Draft Message Submission May 1998 message. A message can be immediately rejected by returning a 5xx code to the MAIL FROM command or after receiving the DATA command. Note that a null return path, that is, MAIL FROM <>, is permitted and MUST be accepted. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.) Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification which instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces the client MUA must maintain a queue of messages it has submitted, and match bounces to them. 3.3. Message Modification For this version of the message submission specification, modification to headers and content of messages received from user agents is a matter for local convention. The Appendix contains a discussion of the types of message modification for which there is already some operational experience. NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element which lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added. 3.4. Reply Codes This memo adds several reply codes to those defined in [SMTP-MTA]. The reply codes used in this document are: 250 Requested action okay, completed. 501 Syntax error in parameters or arguments. 502 Command not implemented. 503 Bad sequence of commands. Gellens & Klensin Expires November 1998 [Page 6] Internet Draft Message Submission May 1998 505 Authentication required. Site policy requires authentication before issuing this command. 554 Transaction Failed. (Various errors in contents of MAIL FROM, RCPT TO, or DATA). 555 Bad domain or address. Invalid or improper domain or address in MAIL FROM, RCPT TO, or DATA. 556 Not a submission. The message appears to have been submitted earlier. 560 Not allowed. The address in MAIL FROM appears to have insufficient submission rights, or is invalid, or is not authorized with the authentication used; the address in a RCPT TO command is inconsistent with the permissions given to the user; the message data is rejected based on the submitting user. 561 Site policy. The message appears to violate site policy in some way. An implementation MAY include a configuration option to generate 554 instead of 560, to avoid revealing information about security-related rejections. 4. Mandatory Actions An MSA MUST do all of the following: 4.1. General Submission Rejection Code Unless covered by a more precise response code, response code 554 MUST be used to reject a MAIL FROM, RCPT TO, or DATA command that contains something improper. 4.2. Ensure All Domains are Fully-Qualified The MSA MUST ensure that all domains in the envelope are fully-qualified. If the MSA examines or alters the message text in way, except to add 'Received', 'Change-ID', and 'Change-History' header fields, it MUST ensure that all domains in the header are fully-qualified. Reply code 555 is to be used to reject a MAIL FROM, RCPT TO, or DATA command which contains improper domains references. Gellens & Klensin Expires November 1998 [Page 7] Internet Draft Message Submission May 1998 NOTE: A frequent local convention is to accept single-level domains (for example, 'sales') and then to expand the reference by adding the remaining portion of the domain name (for example, to 'sales.foo.gork'). It is strongly advised that local conventions that permit single-level domains reject, rather than expand, multi-level domains, since such expansion is particularly risky. 4.3. Enforce Address Syntax An MSA MUST reject messages with illegal syntax in a sender or recipient envelope address. If the MSA examines or alters the message text in way, except to add 'Received', 'Change-ID', and 'Change-History' header fields, it MUST reject messages with illegal address syntax in the header. Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command that contains a detectably improper address. When addresses are resolved after submission of the message body, reply code 555 is to be used after end- of-data, if the message contains invalid addresses in the header. 5. Recommended Actions The MSA SHOULD do all of the following: 5.1. Be the Only MSA An MSA SHOULD reject messages which already contain a 'Change-ID' or 'Change-History' header field, or otherwise appear to have already been through an MSA. Reply code 556 is to be used to reject messages which have already been submitted. 5.2. Add 'Change-ID' and 'Change-History' For sites exercising local conventions involving message header or content changes, the MSA SHOULD note the nature of the changes through use of 'Change-ID' and one or more 'Change-History' header fields. These two fields are defined later in this specification. A transparent encoding change to the envelope or text header, for example, removing extraneous quotes from an envelope recipient, does not need to be noted in a 'Change-History' header field. Gellens & Klensin Expires November 1998 [Page 8] Internet Draft Message Submission May 1998 'Change-ID' and 'Change-History' are not substitutes for appropriate use of 'Received' headers. 5.3. Log Errors The MSA SHOULD log message errors, especially apparent misconfigurations of client software. Note: It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites. 6. Optional Actions The MSA MAY do any of the following: 6.1. Enforce Submission Rights The MSA MAY issue an error response to the MAIL FROM command if the address in MAIL FROM appears to have insufficient submission rights, or is invalid, or is not authorized with the authentication used (if the session has been authenticated). Reply code 560 is used for this purpose. 6.2. Require Authentication The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated. Reply code 503 is used for this purpose. 6.3. Enforce Permissions The MSA MAY issue an error response to the RCPT TO command if inconsistent with the permissions given to the user (if the session has been authenticated). Reply code 560 is used for this purpose. 6.4. Check Message Data The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is Gellens & Klensin Expires November 1998 [Page 9] Internet Draft Message Submission May 1998 syntactically invalid, or seems inconsistent with permissions given to the user (if known), or violated site policy in some way. Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 560 is used to reject based on the submitting user. Reply code 561 is used if the message violates site policy. 7. Submission Extension Mechanism It may be desirable to extend the submission process in the future, using a mechanism which is clearly differentiated from normal SMTP. This specification defines a new verb, SUBM, which is only valid on the submit port. Clients MAY issue SUBM in addition to, or in place of EHLO, that is, after the server has sent the initial greeting and before any transaction. The client MAY send a domain name or literal as a parameter to the SUBM command. SUBM is used to identify the server and any submission-only extensions it supports. SMTP extensions continue to be announced using EHLO. Servers SHOULD support SUBM, even though no submission-only extensions are currently defined. The SUBM command functions like the EHLO and HELO commands; a "250 OK" reply to any of them confirms that both the client and server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared. The response to SUBM is a multiline reply. If any submit-only extensions are supported, each line of the response contains a keyword and, optionally, one or more parameters. The syntax for a positive response is as specified in RFC 1869 [ESMTP]. Clients MUST be prepared for a 5xx error response to SUBM. Submit-only extensions MUST be registered with IANA and MUST be defined in a standards-track or IESG-approved experimental protocol RFC. See "IANA Considerations" for more information. 7.1. SUBM Syntax SUBM = "SUBM" [domain] ; Gellens & Klensin Expires November 1998 [Page 10] Internet Draft Message Submission May 1998 7.2. SUBM Example C: SUBM bar.foo.gork S: 250 submit.foo.gork no extensions supported 8. Interaction with SMTP Extensions The following table lists the current standards-track and Experimental SMTP extensions. Listed are the RFC, name, status, an indication as to the extension's use on the submit port, and a reference: RFC Name Status Submission Reference ---- --------------- ------ ---------- ------------------ 2197 Pipelining DS SHOULD [PIPELINING] 2034 Error Codes PS SHOULD [CODES-EXTENSION] 1985 ETRN PS MUST NOT [ETRN] 1893 Extended Codes PS SHOULD [SMTP-CODES] 1891 DSN PS MAY [DSN] 1870 Size S MAY [SIZE] 1846 521 E MUST NOT [521REPLY] 1845 Checkpoint E MAY [Checkpoint] 1830 Binary E MAY [CHUNKING] 1652 8-bit MIME DS SHOULD [8BITMIME] Future SMTP extensions should explicitly specify if they are valid on the Submission port. Some SMTP extensions are especially useful for message submission: Extended Status Codes [SMTP-CODES], SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections are related to a site's security policy, care should be used not to expose more detail than is needed to correct the problem. [PIPELINING] SHOULD be supported by the MSA. 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. Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING]. Gellens & Klensin Expires November 1998 [Page 11] Internet Draft Message Submission May 1998 9. Change-ID and Change-History These headers are defined to permit MSAs that modify messages to be able to record the nature of those changes. MSA software that performs such modifications SHOULD use the parameters defined here so as to assist in later analysis of possible problems with the message. 'Change-ID' is a structured header field which allows an MSA 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. An MSA MUST NOT add more than one 'Change-ID' header field to a message. 'Change-History' is a structured header field which allows an MSA to list the changes it made. All parameter names and parameter values are case-insensitive, unless otherwise noted. Each 'Change-History' header field contains parameters describing a specific change made by the MSA. 9.1. Parameters of Change-ID The following parameters are defined for the 'Change-ID' header field. Additional parameters may be specified in the future, and MUST be registered with IANA. Optional parameters are registered on a first-come, first-served basis. Required parameters must be specified in a standards-track or IESG-approved Experimental RFC. A registration template is included in this memo. 9.1.1. Date 'Date' is required and contains the time and date at which the change was made. 9.1.2. MSA 'MSA' is a required parameter, which can be in one of two forms: domain or software. The domain form identifies the domain name of the specific MSA that made the changes. The software form is provided for use by sites which don't want to reveal internal host names. This form of the parameter value must be treated as case sensitive; that is, its case must be preserved. Gellens & Klensin Expires November 1998 [Page 12] Internet Draft Message Submission May 1998 The software form is in the style of a message-ID. It first has a string that is sufficient for the postmaster at the contact domain to identify the software that modified the message. The second part is the contact domain which is responsible for the MSA. 9.1.3. Contact 'Contact' is a required parameter. It specifies a fully-qualified email address, which is the contact point for problems detected by the recipient of the message. It is generally not a good idea to use the email address of an individual. Instead, role addresses should be used. For example, 'MSA-Admin' or 'mail-nanny' for the local-part, which could then be aliased to one or more specific people, or even to another role address (such as 'postmaster'). 9.1.4. Port 'Port' is an optional parameter which indicates the TCP port number on which the message was received. 9.2. Parameters of Change-History The following parameters are defined for the 'Change-History' header field. Additional parameters may be defined in the future, and MUST be registered with IANA. Optional parameters are registered on a first-come, first-served basis. Required parameters must be specified in a standards-track or IESG-approved Experimental RFC. A registration template is included in this memo. 9.2.1. Element The 'Element' parameter is required and identifies the header field or envelope item that was changed. If the content body was changed (for example, upgraded to MIME and content-transfer-encoded), 'body' is to be specified. 9.2.2. Action The 'Action' parameter is required and specifies the type of change: * Added * Expanded * Quoted * Unquoted * Changed * Removed Gellens & Klensin Expires November 1998 [Page 13] Internet Draft Message Submission May 1998 9.2.3. Cause The 'Cause' parameter is optional and identifies the justification for the change: * 'Bad-Syntax' indicates the original value was not syntactically valid. * 'Incorrect' means the original value was not correct. * 'Missing' is used when a field or item is added. * 'Alias' indicates the original value was a local DNS alias. * 'Policy' refers to changes required by site policy, as opposed to corrections or additions required for conformance with Internet standards. 9.2.4. Original 'Original' is an optional parameter which contains the value of the field or subfield (individual value of a multi-valued field) before it was changed. 'Original' SHOULD NOT be used if 'Element' is 'body'. 9.2.5. Result 'Result' is an optional parameter which contains the value of the field or subfield after it was changed. 'Result' SHOULD NOT be used if 'Element' is 'body'. 9.3. ABNF for Change-ID This defines the syntax for the 'Change-ID' header field using ABNF as specified in RFC 2234 [ABNF]. Comments and folding white space [MESSAGE-FORMAT] may be inserted wherever a space is specified, and nowhere else. Encoding of date/time and email address information conforms to [MESSAGE-FORMAT] conventions. change-id = "Change-ID" ":" SP id-parameters contact = "Contact" "=" "<" local-part "@" domain ">" date = "Date" "=" date-time date-time = Gellens & Klensin Expires November 1998 [Page 14] Internet Draft Message Submission May 1998 domain = id-parameters = date ";" SP msa [";" SP port] ";" SP contact *(";" SP ext-parameter) local-part = msa = "MSA" "=" [msa-literal "@"] msa-domain msa-domain = domain msa-literal = quoted-string port = "Port" "=" 1*DIGIT 9.4. ABNF for Change-History This defines the syntax for the 'Change-History' header field using [ABNF]. Comments and folding white space [MESSAGE-FORMAT] may be inserted wherever a space is specified, and nowhere else. change-history = "Change-History" ":" SP hist-parameters action = "Action" "=" ("Added" / "Changed" / "Expanded" / "Quoted" / "Removed" / "Unquoted") cause = "Cause" "=" ("Bad-Syntax" / "Incorrect" / "Missing" / "Alias" / "Policy") element = field / envelope envelope = "Envelope" "=" ("MAIL" / "RCPT" / "DATA" / ext-parameter) field = "Field" "=" ("body" / header-field) header-field =
hist-parameters = element ";" SP action [";" SP cause] [";" SP original] [";" SP result] *(";" SP ext-parameter) original = "Original" "=" value result = "Result" "=" value value = simple-value / quoted-string 9.5. Common ABNF Gellens & Klensin Expires November 1998 [Page 15] Internet Draft Message Submission May 1998 The following [ABNF] rules and terminals are referenced above: alphanumeric = ALPHA / DIGIT ext-parameter = [alphanumeric *(alphanumeric / "." / "-")] alphanumeric printable-char = VCHAR / SP quoted-char = printable-char / "\" quoted-specials quoted-specials = DQUOTE / "\" quoted-string = DQUOTE *quoted-char DQUOTE simple-char = %x21 / %x23-3A / %x3C-7E ;ASCII character in the range exclamation ;mark through tilde, except quote and ;semicolon simple-value = 1*simple-char 9.6. Examples of Change-ID and Change-History Change-ID: Date=Fri, 20 March 1997 19:32 +0800; MSA=helpful.qualcomm.gork; Contact= Change-History: Envelope=MAIL; Action=Changed; Cause=Policy Change-History: Envelope=RCPT; Action=Expanded; Cause=Alias; Original=Foo; Result=Foobar Change-History: Field=To; Action=Expanded; Cause=Alias; Original=Foo; Result="Foobar L. Gork" Change-History: Field=To; Action=Quoted; Cause=Bad-Syntax; Original="John Icons Now @$1.99 Doe" Change-ID: Date=Fri, 20 March 1997 19:32 +0800; MSA="xyz99abc"@Qualcomm.Gork; Contact=; Change-History: Field=From; Action=Changed; Cause=Policy 10. IANA Considerations 10.1. Registration Procedures 10.1.1. Change-ID and Change-History 'Change-ID' and 'Change-History' parameters MUST be registered with IANA. Optional parameters are registered on a first-come, first-served basis. Required parameters must be specified in a standards-track or IESG-approved Experimental RFC. (Note that there Gellens & Klensin Expires November 1998 [Page 16] Internet Draft Message Submission May 1998 is no provision for using unregistered experimental parameters, for example "x-". All parameters MUST be registered.) The definition must include the parameter name, the syntax for values, and a definition of its meaning. Registration of a 'Change-ID' or 'Change-History' parameter is done by filling in the template below and sending it in to iana@isi.edu. IANA has the right to reject obviously bogus registrations, but will perform no review of clams made in the registration form. There is no naming convention for 'Change-ID' and 'Change-History' parameters. 10.1.2. Submit Submit extensions MUST be registered with IANA and MUST be defined in a standards-track or IESG-approved Experimental RFC. The definition must include: (1) the textual name of the submit service extension; (2) the SUBM keyword value associated with the extension; (3) the syntax and possible values of parameters associated with the SUBM keyword value; (4) any additional protocol verbs associated with the extension (additional verbs will usually be, but are not required to be, the same as the SUBM keyword value); (5) any new parameters the extension associates with existing verbs; (6) a description of how support for the extension affects the behavior of a server and client; and, (7) the increment, if any, by which the extension is increasing the maximum length of existing commands. There is no naming convention for Submit extensions. (Note that there is no provision for using unregistered experimental parameters, for example "x-". All extensions MUST be registered.) 10.2. Change Control Once a 'Change-ID' or 'Change-History' parameter registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request. Gellens & Klensin Expires November 1998 [Page 17] Internet Draft Message Submission May 1998 The owner of a parameter may pass responsibility for it to another person or agency by informing IANA; this can be done without discussion or review. The IESG may reassign responsibility for a parameter, or make changes to a parameter, including marking it as OBSOLETE. Parameter registrations may not be deleted; those which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such parameters will be clearly marked in the lists published by IANA. The IESG is considered to be the owner of all parameters which are specified in standards track or IESG-approved Experimental RFCs. Since Submit extensions must be published in standards track or IESG-approved Experimental RFCs, normal IETF RFC change control rules apply. 10.3. Registration Template To: iana@isi.edu Subject: Registration of Change-History/Change-ID parameter X Parameter for header (check one): [ ] Change-History [ ] Change-ID Parameter name: Nature (check one): [ ] Optional [ ] Required Note: Required parameters must be specified in a standards-track or IESG-approved Experimental RFC. Security considerations: Published specification: Person & email address to contact for further information: Intended usage (check one): [ ] COMMON [ ]LIMITED [ ] OBSOLETE Author/Change controller: (Any other information that the author deems interesting may be added below this line.) 11. Security Considerations Gellens & Klensin Expires November 1998 [Page 18] Internet Draft Message Submission May 1998 Separation of submission and relay of messages can allow a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. In can do this in a way which is simpler, both technically and administratively. This increases the likelihood that policies will be applied correctly. Separation also can aid in tracking and preventing unsolicited bulk email. 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 and MSA parameters. Sites wanting to prevent disclosure of details of their local network (such as the identities of local servers) should use the software form, while other sites can use the simpler domain form. 12. Acknowledgments This updated draft has been revised in part based on comments and discussions which took place on and off the IETF-Submit mailing list. The help of those who took the time to review the draft and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman. Special thanks to Harald Alvestrand, who got this effort started. 13. References [521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code", September 1995, [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994, [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax Specifications: ABNF", November 1997, [CHECKPOINT] D. Crocker, N. Freed, and A. Cargille, "SMTP Service Extension for Checkpoint/Restart, September 1995, [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", August 1995, Gellens & Klensin Expires November 1998 [Page 19] Internet Draft Message Submission May 1998 [CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996, [DSN] K. Moore, "SMTP Service Extension for Delivery Status Notifications, January 1996, [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995, [ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue Starting", August 1996, [HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076, February 1997, [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, [MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982, ; R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989, [PIPELINING] N. Freed, "SMTP Service Extension for Command Pipelining", September 1997, [SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service Extension for Message Size Declaration, November 1995, [SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, January 1996, [SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982, ; C. Partridge, "Mail Routing and the Domain System", STD 14, RFC 974, January 1986, ; R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989, Gellens & Klensin Expires November 1998 [Page 20] Internet Draft Message Submission May 1998 14. Full Copyright Statement Copyright (C) The Internet Society 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 15. Authors' Addresses Randall Gellens +1 619 651 5115 QUALCOMM Incorporated +1 619 651 5334 (fax) 6455 Lusk Blvd. Randy@Qualcomm.Com San Diego, CA 92121-2779 U.S.A. John C. Klensin +1 617 960 1011 MCI Telecommunications klensin@mci.net 800 Boylston St, 7th floor Boston, MA 02199 USA 16. Appendix: Message Modifications For sites wishing to create local conventions that include modification of messages by an MSA, this appendix describes a number of such modifications that are often considered useful. Gellens & Klensin Expires November 1998 [Page 21] Internet Draft Message Submission May 1998 This appendix is provided as helpful, but not formal, guidance outside of the formal specification in the main part of this document. 16.1. Add 'Sender' The MSA could add or replace the '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. 16.2. Add 'Date' The MSA could add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE-FORMAT] syntax. 16.3. Add 'Message-ID' The MSA could add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). 16.4. Transfer Encode The MSA could apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type. 16.5. Sign the Message The MSA could (digitally) sign or otherwise add authentication information to the message. 16.6. Encrypt the Message The MSA could encrypt the message for transport to reflect organizational policies. 16.7. Resolve Aliases The MSA could resolve aliases (CNAME records) for domain names, in the envelope and optionally in address fields of the header, subject to local policy. Gellens & Klensin Expires November 1998 [Page 22] Internet Draft Message Submission May 1998 Note: unconditionally resolving aliases could be harmful. For example, if www.ab.gork and ftp.ab.gork are both aliases for mail.ab.gork, rewriting them could lose useful information. 16.8. Header Rewriting The MSA MAY rewrite local parts and/or domains, in the envelope and optionally 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.gork' as 'zyx.gork' to hide machine names and make it easier to move users. However, only addresses, local-parts, or domains which match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule which strips the left-most element of the domain if the complete domain matches '*.foo.bar.gork' would be acceptable. Gellens & Klensin Expires November 1998 [Page 23]