Internet Draft: SMTP Message Submission. Expires: 12 September 1998 MCI 12 March SMTP Message Submission. Status of this Memo:

Transcription

1 HTTP/ OK Date: Tue, 09 Apr :04:29 GMT Server: Apache/ (Unix) Last-Modified: Mon, 27 Apr :29:00 GMT ETag: "2e9a07-b c" Accept-Ranges: bytes Content-Length: Connection: close Content-Type: text/plain Internet Draft: SMTP Message Submission Document: draft-gellens-submit-06.txt Expires: 12 September 1998 R. Gellens QUALCOMM, Incorporated J. Klensin MCI 12 March 1997 SMTP 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), 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. Public comments should be sent to the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments can be sent to the authors. This version reflects comments received during Last Call. Copyright Notice Copyright (C) The Internet Society All Rights Reserved. Table of Contents 1. SUBMIT Servers SMTP Extension for Message Relay Assertion Actions when RELAY Is Used Gellens, Klensin Expires September 1998 [Page 1]

2 4. Actions when the Message Is a Submission General Rules Specific Problems Rejection vs. Damage Things which MAY Be Done Enforce Submission Rights Require Authentication Enforce Permissions Check Message Data Add Sender Add Date Add Message-ID Transfer Encode Resolve Aliases Header Rewriting Sign the Message Encrypt the Message Things which SHOULD Be Done Be the Only MSA Log Errors Things which MUST NOT Be Done Corrupt the Message Things which MUST Be Done Ensure All Domains are Fully-Qualified Enforce Address Syntax Use RELAY Add Change-ID and Change-History Change-ID and Change-History Parameters of Change-ID Date MSA Port Contact Parameters of Change-History Element Action Cause Original Result ABNF for Change-ID ABNF for Change-History Common ABNF Examples of Change-ID and Change-History Submission Extension Mechanism SUBM Example Interaction with Other SMTP Extensions Message Rejection and Bouncing Reply Codes IANA Considerations Registration Procedures Change Control Registration Template Gellens, Klensin Expires September 1998 [Page 2]

3 11. Security Considerations Acknowledgments References Full Copyright Statement Authors Addresses Introduction 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 other. 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, and are in general considered to be outside the province of MTAs. 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. Gellens, Klensin Expires September 1998 [Page 3]

4 Separation of messages into submissions and transfers 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 injection of unsolicited bulk ), making it easier to detect configuration problems with a site s mail clients, providing a migration path to get MTAs out of the dangerous business of modifying mail, and providing a basis for adding additional functionality in the future. Definitions of Terms Used in this Memo Fully-Qualified Containing or consisting of a domain which can be resolved using DNS; not a local alias. Message Transfer Agent (MTA) A process which conforms to [SMTP-MTA], which accepts messages as an SMTP server, 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. 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. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS]. 1. SUBMIT Servers To distinguish transfer SMTP from submission, port 587 is reserved as the MAIL SUBMIT port. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with modifications as specified in this memo. 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 transfer agent. Gellens, Klensin Expires September 1998 [Page 4]

5 2. SMTP Extension for Message Relay Assertion In addition to providing for SMTP submission on a separate port from transfer, 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. If RELAY is used with the MAIL FROM command, the message is to be treated as a relay; that is, the MTA is being informed that it is not the originating or submitting MTA. RELAY is only for use on the SMTP port. If RELAY appears in MAIL FROM on the SUBMIT port, the MSA MUST reject the command with 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 MTA MUST NOT alter the text, except as specified in [SMTP-MTA]. 4. Actions when the Message Is a Submission 4.1. General Rules Specific Problems 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 to an address or element which lacks 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 added Rejection vs. Damage 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). Response code 554 should be used to reject a MAIL FROM, RCPT TO, or Gellens, Klensin Expires September 1998 [Page 5]

6 DATA command which contains something improper Things which MAY Be Done The MSA MAY do any of the following: Enforce Submission Rights The MSA MAY refuse the MAIL FROM command if the address in MAIL FROM is not believed to have submission rights, or is invalid, or is not authorized with the authentication used (if the session has been authenticated). Failure code 560 should be used for this purpose Require Authentication The MSA MAY refuse the MAIL FROM command with code 503 if the client has not authenticated Enforce Permissions The MSA MAY refuse the MAIL FROM, or a RCPT TO command if inconsistent with the permissions given to the user (if known). Failure code 560 should be used Check Message Data The MSA MAY 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 for syntactic problems in the data (500 or 501 is used if the command itself is not syntactically valid). 560 should be used to reject based on the submitting user Add Sender The MSA MAY 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 Add Date The MSA MAY 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. Gellens, Klensin Expires September 1998 [Page 6]

7 Add Message-ID The MSA MAY add or replace the Message-ID field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]) Transfer Encode The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type Resolve Aliases The MSA MAY resolve aliases (CNAME records) for domain names, in the envelope and optionally in address fields of the header, subject to local policy. For example, if and ftp.ab.com are both aliases for mail.ab.com, rewriting them could lose useful information 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.com as zyx.com 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 may be altered. The MSA MUST NOT 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.com would be permitted Sign the Message The MSA MAY (digitally) sign or otherwise add authentication information to the message Encrypt the Message The MSA MAY encrypt the message for transport to reflect organizational policies Things which SHOULD Be Done The MSA SHOULD do all of the following: Gellens, Klensin Expires September 1998 [Page 7]

8 Be the Only MSA The MSA MAY reject messages which already contain a Change-ID or Change-History header field, or otherwise appear to have already been through an MSA. Generally, the MSA SHOULD do this unless it knows it is a gateway receiving messages from downstream MSAs. Response code 556 should be used for this Log Errors The MSA SHOULD log message errors, especially apparent misconfigurations of client software. 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 may be interested in local configuration problems, but not in client problems at other sites Things which MUST NOT Be Done The MSA MUST NOT do any of the following: Corrupt the Message The MSA MUST NOT 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) 4.5. Things which MUST Be Done The MSA MUST do all of the following: Ensure All Domains are Fully-Qualified The MSA MUST ensure that all domains in the envelope 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 555 should be used to reject a MAIL FROM or RCPT TO command which contains improper domains. 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 text are fully-qualified. The rules for single and multi-level domains in the preceding paragraph apply. Response code 555 should be used to reject a DATA command which contains improper domains. Gellens, Klensin Expires September 1998 [Page 8]

9 Enforce Address Syntax The MSA MUST reject messages with detectably illegal syntax in a sender or recipient address. This applies after any address transformations have been done. Response code 501 should be used to reject a MAIL FROM or RCPT TO command which contains an improper address. 555 may be used after end-of-data if the message contains invalid addresses in the header Use RELAY The MSA MUST use the RELAY parameter to the MAIL FROM command when relaying the message, if the server MTA understands ESMTP and supports the RELAY extension. This requirement applies to "pure" MSAs, which accept message submissions and relay them via SMTP. In certain cases, a site may need special configurations, in which MSAs and/or MTAs submit messages to an MSA for additional policy validation. These MSAs or MTAs are considered gateways, because they do not follow the normal model Add Change-ID and Change-History The MSA MUST Document all modifications to the envelope or text by adding a Change-ID and one or more Change-History header fields. 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. The MSA MUST add Change-ID and Change-History in addition to a Received header; Change-ID and Change-History are not substitutes for Received. 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. Exactly one Change-ID header field MUST be added. 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. Gellens, Klensin Expires September 1998 [Page 9]

10 5. Change-ID and Change-History 5.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 Date Date is required and contains the time and date at which the change was made MSA MSA is a required parameter, which can be in one of two forms. The token form is a quoted string which is sufficient for the postmaster at the contact domain to identify the software which modified the message. This form of the parameter value must be treated as case sensitive; that is, its case must be preserved. The domain form identifies the domain name or IP address of the MSA Port Port is a required parameter which indicates the TCP port on which the message was received Contact Contact is a required parameter. It specifies a fully-qualified 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 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 ) 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. Optional parameters are registered on a first-come, first-served basis. Required Gellens, Klensin Expires September 1998 [Page 10]

11 parameters must be specified in a standards-track or IESG-approved Experimental RFC. A registration template is included in this memo Element 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 Action The Action parameter is required and specifies the type of change: Added, Expanded, Quoted, Unquoted, Changed, or Removed Cause The Cause parameter optionally identifies the justification for the change: Bad-Syntax, Incorrect, Missing, Nickname, or Policy. 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 has been added. Nickname 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 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 Result Result is an optional parameter which contains the value of the field or subfield after it was changed ABNF for Change-ID Gellens, Klensin Expires September 1998 [Page 11]

12 This defines the syntax for the Change-ID header field using ABNF as specified in RFC 2234 [ABNF]. Comments and folding white space [RFC-822] may be inserted wherever a space is specified, and nowhere else. change-id ::= "Change-ID" ":" SP id-parameters contact ::= "Contact" "=" "<" local-part "@" (domain / IP) ">" date day domain dot-string hour id-parameters ::= "Date" "=" [weekday "," SP] day SP month SP year SP hour ":" minute [":" second] SP time-zone ::= 2DIGIT ::= sub-domain 1*("." sub-domain) ::= 1*(atext ["." atext]) ::= 1*2DIGIT ::= date ";" SP msa ";" SP port ";" SP contact *(";" SP ext-parameter) IP ::= "[" (IPv4-literal / IPv6-literal) "]" IPv4-literal IPv6-literal ldh-str local-part minute month msa msa-domain msa-literal port second sub-domain time-zone ::= snum 3("." snum) ::= simple-char *(simple-char / SP) ::= *(alphanumeric / "-") alphanumeric ::= dot-string quoted-string ::= 2DIGIT ::= 2DIGIT ::= "MSA" "=" (msa-domain / msa-literal) ::= domain / IP ::= quoted-string ::= "Port" "=" 1*DIGIT ::= 2DIGIT ::= alphanumeric *(ldh-str) ::= ("+" / "-") 4DIGIT Gellens, Klensin Expires September 1998 [Page 12]

13 weekday ::= "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun" year ::= 4DIGIT 5.4. ABNF for Change-History This defines the syntax for the Change-History header field using [ABNF]. Comments and folding white space [RFC-822] may be inserted wherever a space is specified, and nowhere else. action cause change-history element ::= "Action" "=" ("Added" / "Changed" / "Expanded" / "Quoted" / "Removed" / "Unquoted") ::= "Cause" "=" ("Bad-Syntax" / "Incorrect" / "Missing" / "Nickname" / "Policy") ::= "Change-History" ":" SP hist-parameters ::= field / envelope envelope ::= "Envelope" "=" ("MAIL" / "RCPT" / "DATA" / ext-parameter) field header-field hist-parameters original result ::= "Field" "=" ("body" / header-field) ::= <header field as specified in [HEADERS]> ::= element ";" SP action [";" SP cause] [";" SP original] [";" SP result] *(";" SP ext-parameter) ::= "Original" "=" value ::= "Result" "=" value value ::= simple-value / quoted-string 5.5. Common ABNF The following [ABNF] rules and terminals are referenced above: alphanumeric ::= ALPHA / DIGIT atext ::= alphanumeric / "!" / "#" / "$" / "%" / "&" / " " / "*" / "+" / Gellens, Klensin Expires September 1998 [Page 13]

14 "-" / "/" / "=" / "?" / "^" / "_" / " " / "{" / " " / "}" / " " ext-parameter ::= [alphanumeric *(alphanumeric / "." / "-")] alphanumeric ldh-str printable-char quoted-char ::= *(alphanumeric / "-") alphanumeric ::= VCHAR / SP ::= printable-char / "\" quoted-specials quoted-specials ::= DQUOTE / "\" quoted-string simple-char simple-value ::= DQUOTE *quoted-char DQUOTE ::= %x21 / %x23-3a / %x3c-7e ;ASCII character in the range exclamation ;mark through tilde, except quote and ;semicolon ::= 1*simple-char snum ::= 1*3DIGIT ;range 0 through Examples of Change-ID and Change-History Change-ID: Date="Fri, 20 March : "; MSA=helpful.qualcomm.com; Contact=<Postmaster@Qualcomm.Com> Change-History: Envelope=MAIL; Action=Changed; Cause=Policy Change-History: Envelope=RCPT; Action=Expanded; Cause=Nickname; Original=Foo; Result=Foobar Change-History: Field=To; Action=Expanded; Cause=Nickname; Original=Foo; Result="Foobar L. Gork" Change-History: Field=To; Action=Quoted; Cause=Bad-Syntax; Original="John Icons Doe" Change-ID: Date="Fri, 20 March : "; MSA="xyz99abc"; Contact=<admin+msa@Shy.Qualcomm.Com>; Change-History: Field=From; Action=Changed; Cause=Policy Gellens, Klensin Expires September 1998 [Page 14]

15 6. 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 send SUBM at any time after the server has sent the initial greeting. Until such time as submission extensions are defined, servers SHOULD send a 250 response. Clients MUST be prepared for a 502 (command not implemented) response SUBM Example C: SUBM S: 250 No extensions supported 7. Interaction with Other SMTP Extensions The following table lists the current standards-track and Experimental SMTP extensions. Listed are the RFC, name, status, an indication if the extension is valid on the submit port, and a reference: RFC Name Status Submission Reference Pipelining DS Yes [PIPELINING] 2034 Error Codes PS Yes [CODES-EXTENSION] 1985 ETRN PS No [ETRN] 1893 Extended Codes PS Yes [SMTP-CODES] 1891 DSN PS Yes [DSN] 1870 Size S Yes [SIZE] E No [521REPLY] 1845 Checkpoint E Yes [Checkpoint] 1830 Binary E Yes [CHUNKING] bit MIME DS Yes [8BITMIME] The MSA advertises support for specific extensions in the EHLO response, as usual. Future extensions may be defined which are intended for use only with SMTP transfer, or only with the submission service. Future extensions should explicitly specify if they are valid with SMTP, Submission, or both. Some SMTP extensions are especially useful for message submission: Gellens, Klensin Expires September 1998 [Page 15]

16 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]. 8. Message Rejection and Bouncing MTAs and MSAs 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 which do not reference local users, and configure their MSA to reject all message submissions which do not come from local users (based on IP address and/or authenticated identity). 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 a 5xx code to the MAIL FROM command or after receiving the data. Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this memo which instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. Note that 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 must maintain a queue of messages it has submitted, and match bounces to them. In the case of batch submission, the client is requesting the delayed bounce behavior. 9. Reply Codes Gellens, Klensin Expires September 1998 [Page 16]

17 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. 502 Command not implemented. 503 Bad sequence of commands. 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. Invalid or improper domain 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 is not believed to have 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. An implementation MAY include a configuration option to generate 554 instead of 560, to avoid revealing information about security-related rejections. 10. IANA Considerations Registration Procedures 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. 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 Change Control Once a Change-ID and 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 September 1998 [Page 17]

18 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 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 & 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 Separation of submission and relay of messages can allow a site to implement more secure policies. This can aid in tracking or preventing unsolicited bulk . 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 Gellens, Klensin Expires September 1998 [Page 18]

19 total 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 token form, while sites without these concerns 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. Special thanks to Harald Alvestrand, who started this effort and wrote the original version of the draft. 13. References [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995, <ftp://ftp.isi.edu/in-notes/rfc1869.txt> [SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C. Partridge, "Mail Routing and the Domain System", STD 14, RFC 974, January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt> [MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982, <ftp://ds.internic.net/rfc/rfc822.txt>; R. Braden, Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt> [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119.txt> [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax Specifications: ABNF", November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt> [CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996, <ftp://ftp.isi.edu/in-notes/rfc2034.txt> Gellens, Klensin Expires September 1998 [Page 19]

20 [SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 1893, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1893.txt> [HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076, February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt> [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", August 1995, <ftp://ftp.isi.edu/in-notes/rfc1830.txt> [PIPELINING] N. Freed, "SMTP Service Extension for Command Pipelining", September 1997, <ftp://ftp.isi.edu/in-notes/rfc2197.txt> [ETRN] J. De Winter, "SMTP Service Extension for Remote Message Queue Starting", August 1996, <ftp://ftp.isi.edu/in-notes/rfc1985.txt> [DSN] K. Moore, "SMTP Service Extension for Delivery Status Notifications, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1891.txt> [SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service Extension for Message Size Declaration, November 1995, <ftp://ftp.isi.edu/in-notes/rfc1870.txt> [521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code", September 1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt> [Checkpoint] D. Crocker, N. Freed, and A. Cargille, "SMTP Service Extension for Checkpoint/Restart, September 1995, <ftp://ftp.isi.edu/in-notes/rfc1845.txt> [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994, <ftp://ftp.isi.edu/in-notes/rfc1652.txt> 14. Full Copyright Statement Copyright (C) The Internet Society 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 Gellens, Klensin Expires September 1998 [Page 20]

21 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 QUALCOMM, Incorporated (fax) 6455 Lusk Blvd. Randy@Qualcomm.Com San Diego, CA U.S.A. John C. Klensin MCI Telecommunications klensin@mci.net 800 Boylston St, 7th floor Boston, MA USA Gellens, Klensin Expires September 1998 [Page 21]