WDIFF

draft-gellens-submit-06.txt --> draft-gellens-submit-07.txt

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 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, <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.

Table of Contents

1. SUBMIT Servers. Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. SMTP Extension for Message Relay Assertion . . . 3
2. Document Information . . . . . . . . . 4
3. Actions when RELAY Is Used. . . . . . . . . . . . . . . 4
2.1. Definitions of Terms Used in this Memo. . . . . . . 5

Gellens, Klensin Expires September 1998 [Page 1]
Internet Draft SMTP Message Submission March 1998

4. Actions when the Message Is a Submission . . . . . . 4
2.2. Conventions Used in this Document . . . . . . . 5
4.1. General Rules . . . . . . . . 4
2.3. Changes from Previous Version . . . . . . . . . . . . . . . . . 5
4.1.1. Specific Problems
3. Message Submission Protocol . . . . . . . . . . . . . . . . . . . 5

Gellens & Klensin Expires November 1998 [Page 1]
Internet Draft Message Submission May 1998

3.1. Submission Port . . . . 5
4.1.2. Rejection vs. Damage . . . . . . . . . . . . . . . . . . . . 5
4.2. Things which MAY Be Done
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . . . . . 5
3.3. Message Modification. . . . 6
4.2.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . . 6
4.2.2. Require Authentication
3.4. Reply Codes . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Enforce Permissions . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . 6
4.2.4. Check Message Data . . . . . . . . . 7
4.1. General Submission Rejection Code . . . . . . . . . . . . . 6
4.2.5. Add 'Sender'. . . 7
4.2. Ensure All Domains are Fully-Qualified. . . . . . . . . . . . . 7
4.3. Enforce Address Syntax . . . . . . . . . . 6
4.2.6. Add 'Date' . . . . . . . . . . . 8
5. Recommended Actions . . . . . . . . . . . . . . . 6
4.2.7. Add 'Message-ID'. . . . . . . . . 8
5.1. Be the Only MSA . . . . . . . . . . . . . . 6
4.2.8. Transfer Encode . . . . . . . . . . 8
5.2. Add 'Change-ID' and 'Change-History'. . . . . . . . . . . . . . 7
4.2.9. Resolve Aliases 8
5.3. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.10. Header Rewriting . . . . 9
6. Optional Actions. . . . . . . . . . . . . . . . . . . 7
4.2.11 Sign the Message . . . . . . 9
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . 7
4.2.12 Encrypt the Message . . 9
6.2. Require Authentication. . . . . . . . . . . . . . . . . . . . . 7
4.3. Things which SHOULD Be Done 9
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 7
4.3.1. Be the Only MSA . . . . 9
6.4. Check Message Data. . . . . . . . . . . . . . . . . . . . 7
4.3.2. Log Errors. . . . 9
7. Submission Extension Mechanism . . . . . . . . . . . . . . . . . 10
7.1. SUBM Syntax. . . . . . 8
4.4. Things which MUST NOT Be Done . . . . . . . . . . . . . . . . . 8
4.4.1. Corrupt the Message . . . 10
7.2. SUBM Example . . . . . . . . . . . . . . . . . . 8
4.5. Things which MUST Be Done . . . . . . . 11
8. Interaction with SMTP Extensions . . . . . . . . . . . . 8
4.5.1. Ensure All Domains are Fully-Qualified. . . . . 11
9. Change-ID and Change-History . . . . . . . 8
4.5.2. Enforce Address Syntax . . . . . . . . . . . 12
9.1. Parameters of Change-ID. . . . . . . . . . 9
4.5.3. Use RELAY . . . . . . . . . . 12
9.1.1. Date . . . . . . . . . . . . . . . . 9
4.5.4. Add 'Change-ID' and 'Change-History' . . . . . . . . . . . . 12
9.1.2. MSA. . 9
5. 'Change-ID' and 'Change-History'. . . . . . . . . . . . . . . . . 10
5.1. Parameters of 'Change-ID' . . . . . . . . . . . 12
9.1.3. Contact . . . . . . . . 10
5.1.1. Date . . . . . . . . . . . . . . . . . . . 13
9.1.4. Port . . . . . . . . . 10
5.1.2. MSA . . . . . . . . . . . . . . . . . . . 13
9.2. Parameters of Change-History . . . . . . . . . . 10
5.1.3. Port . . . . . . . 13
9.2.1. Element. . . . . . . . . . . . . . . . . . . . . . 10
5.1.4. Contact . . . . . 13
9.2.2. Action . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Parameters of 'Change-History' . . . . . 13
9.2.3. Cause. . . . . . . . . . . . 10
5.2.1. Element . . . . . . . . . . . . . . . . 14
9.2.4. Original . . . . . . . . . . . 11
5.2.2. Action . . . . . . . . . . . . . . . 14
9.2.5. Result . . . . . . . . . . . . 11
5.2.3. Cause . . . . . . . . . . . . . . . 14
9.3. ABNF for Change-ID . . . . . . . . . . . . . 11
5.2.4. Original . . . . . . . . . 14
9.4. ABNF for Change-History. . . . . . . . . . . . . . . . . . 11
5.2.5. Result . . 15
9.5. Common ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. ABNF for 'Change-ID' . 15
9.6. Examples of Change-ID and Change-History . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . 11
5.4. ABNF for 'Change-History' . . . . . . . . . . . . . 16
10.1. Registration Procedures . . . . . . 13
5.5. Common ABNF. . . . . . . . . . . . . . 16
10.1.1. Change-ID and Change-History . . . . . . . . . . . . 13
5.6. Examples of 'Change-ID' and 'Change-History' . . . . 16
10.1.2. Submit. . . . . . 14
6. Submission Extension Mechanism . . . . . . . . . . . . . . . . . 15
6.1. SUBM Example . . . . 17
10.2. Change Control . . . . . . . . . . . . . . . . . . . . . 15
7. Interaction with Other SMTP Extensions . . . 17
10.3. Registration Template . . . . . . . . . . 15
8. Message Rejection and Bouncing . . . . . . . . . . 18
11. Security Considerations . . . . . . . 16
9. Reply Codes. . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . 19
13. References . . . . . . . . . . . 17
10.1. Registration Procedures . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement. . . . 17
10.2. Change Control . . . . . . . . . . . . . . . . 21
15. Authors' Addresses . . . . . . . . 17
10.3. Registration Template . . . . . . . . . . . . . . . 21
16. Appendix: Message Modifications. . . . . . 18

Gellens, Klensin Expires September 1998 [Page 2]
Internet Draft SMTP Message Submission March 1998

11. Security Considerations . . . . . . . . . . 21
16.1. Add 'Sender' . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . 22
16.2. Add 'Date'. . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . 22
16.3. Add 'Message-ID' . . . . . . . . . . . 19
14. Full Copyright Statement. . . . . . . . . . . . . 22

Gellens & Klensin Expires November 1998 [Page 2]
Internet Draft Message Submission May 1998

16.4. Transfer Encode . . . . . . . 20
15. Authors' Addresses . . . . . . . . . . . . . . . . 22
16.5. Sign the Message . . . . . . . 21

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, . . . . . . . . . . . . . . . . 22
16.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . . . 22
16.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . . . 22
16.8. Header Rewriting. . . . . . . . . . . . . . . . . . . . . . . 23

1. Abstract

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.
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, MTAs -- that is,
MTAs after the first-hop submission MTA -- 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]
Internet Draft SMTP Message Submission March 1998

Separation of standardized MTA
functionality.

Separating messages into submissions and transfers can have many
benefits for Internet mail in the short allows developers
and long term. These
benefits include allowing sites network administrators to more easily implement easily:

* Implement security policies and guard against unauthorized mail
relaying (and or injection of unsolicited bulk email), making it easier to detect
configuration problems with a site's mail clients, providing

* 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, and providing mail

* Detect configuration problems with a site's mail clients

* Provide a basis for adding additional
functionality enhanced submission services in the future.

Definitions of Terms Used in this Memo

Fully-Qualified
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
DNS; the global Domain Name Service; that is, not a local alias. 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 accepts messages acts as an SMTP server, server
to accept messages from an MSA or another MTA, and either delivers them,
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].

1. SUBMIT Servers

To distinguish transfer SMTP

2.3. Changes from submission, port 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
as for the MAIL SUBMIT port. 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 memo.

The process which acts as 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 server will be referred to
as or a Message Submission Agent (MSA) relay.

For example, some sites might configure their MTA to distinguish it 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 an MTA,
which acts as a transfer agent.

Gellens, Klensin Expires September 1998 [Page 4]
Internet Draft SMTP Message Submission March 1998

2. SMTP Extension for Message Relay Assertion

In addition to providing for SMTP submission
authorized users, based on IP address, or authenticated identity.

When a separate port
from transfer, to aid in migration this memo extends SMTP [ESMTP]
to enable assertion that problem with 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 detected, and the MAIL FROM verb:
RELAY.

If RELAY is used with MSA has no rule
specifically configured for that problem, the MAIL FROM command, MSA SHOULD reject the
message rather than attempt to fix it.

NOTE: It is better to be
treated as reject a relay; message than to risk sending one
that is, the MTA is being informed damaged. This is especially true for problems that it are
correctable by the MUA, for example, an invalid 'From' field.

If an MSA is not able to determine a return path to the originating or submitting MTA.

RELAY is only for use on the SMTP port. If RELAY appears in
user, from a valid MAIL
FROM FROM, a valid source IP address, or based on the SUBMIT port,
authenticated identity, then the MSA MUST immediately reject the command with 504.

3. Actions when RELAY Is Used

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 has the RELAY parameter, or after receiving the MTA is being
informed DATA command.

Note that this message a null return path, that is, MAIL FROM <>, is being relayed, permitted
and therefore the MTA MUST NOT alter the text, except as specified be accepted. (MUAs need to generate null return-path
messages for a variety of reasons, including disposition
notifications.)

Except in [SMTP-MTA].

4. Actions when the Message Is a Submission

4.1. General Rules

4.1.1. Specific Problems

Even though various modifications case where the MSA is unable to header fields are authorized determine a valid
return path for the message being submitted, text in this memo,
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 that elements of structured
header fields may only be modified when to limit such actions to
remedies for specific problems are
recognized which that have clear solutions. This is
especially true with address elements. For example,
indiscriminately appending
'@foo.com' a domain to an address or element which
lacks an '@' 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.

4.1.2. 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.

3.4. Reply Codes

This is especially true of problems which are
correctable by the MUA (for example, an invalid 'From' field).
Response code 554 should be used memo adds several reply codes to reject a MAIL FROM, RCPT 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

Gellens, Klensin arguments.

502 Command not implemented.

503 Bad sequence of commands.

Gellens & Klensin Expires September November 1998 [Page 5] 6]
Internet Draft SMTP Message Submission March May 1998

DATA command which contains something improper.

4.2. Things which MAY Be Done

The MSA MAY do any

505 Authentication required. Site policy requires
authentication before issuing this command.

554 Transaction Failed. (Various errors in contents of the following:

4.2.1. Enforce Submission Rights

The MSA MAY refuse the
MAIL FROM command if the 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 is not believed appears to have
insufficient 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.

4.2.2. Require Authentication

The MSA MAY refuse the MAIL FROM command with code 503 if the
client has not authenticated.

4.2.3. Enforce Permissions

The MSA MAY refuse used; the MAIL FROM, or address in a
RCPT TO command if is inconsistent with the permissions given
to the user (if known).
Failure code 560 should be used.

4.2.4. Check Message Data

The MSA MAY refuse the DATA command or send a failure result after
end-of-data if user; 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 rejected based on the
submitting user.

4.2.5. Add 'Sender'

561 Site policy. The MSA message appears to violate site policy in
some way.

An implementation MAY add or replace the 'Sender' field, if the identity 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 sender is known and this is not given in the 'From' field. 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 any address it places in a 'Sender' field is all domains in fact a valid mail address.

4.2.6. Add 'Date'

The MSA MAY add a 'Date' field to the submitted message, if it
lacks it, envelope are
fully-qualified.

If the MSA examines or correct alters the 'Date' field if message text in way, except to add
'Received', 'Change-ID', and 'Change-History' header fields, it does not conform MUST
ensure that all domains in the header are fully-qualified.

Reply code 555 is to
[MESSAGE-FORMAT] syntax.

Gellens, be used to reject a MAIL FROM, RCPT TO, or DATA
command which contains improper domains references.

Gellens & Klensin Expires September November 1998 [Page 6] 7]
Internet Draft SMTP Message Submission March May 1998

4.2.7. Add 'Message-ID'

The MSA MAY add or replace the 'Message-ID' field, if it lacks it,
or it

NOTE: A frequent local convention is not valid syntax (as defined by [MESSAGE-FORMAT]).

4.2.8. Transfer Encode

The MSA MAY apply transfer encoding to the message according to
MIME conventions, if needed accept single-level domains
(for example, 'sales') and not harmful then to expand the MIME type.

4.2.9. Resolve Aliases

The MSA MAY resolve aliases (CNAME records) for domain names, in reference by adding
the envelope and optionally in address fields remaining portion of the header,
subject domain name (for example, to
'sales.foo.gork'). It is strongly advised that 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.

4.2.10. Header Rewriting

The MSA MAY rewrite local parts and/or 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 the a sender or
recipient envelope and
optionally in address fields of address.

If the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as
'J.Random.User' MSA examines or alters the message text in order to hide logon names, and/or to rewrite
'squeeky.sales.xyz.com' as 'zyx.com' way, except to hide machine names add
'Received', 'Change-ID', and make 'Change-History' header fields, 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
reject messages with illegal address syntax in the first element of header.

Reply code 501 is to be used to reject a domain name. So, for example, MAIL FROM or RCPT TO
command that contains a
rule which strips the left-most element detectably improper address.

When addresses are resolved after submission of the domain if the
complete domain matches '*.foo.bar.com' would be permitted.

4.2.11 Sign the Message

The MSA MAY (digitally) sign or otherwise add authentication
information message body,
reply code 555 is to the message.

4.2.12 Encrypt the Message

The MSA MAY encrypt be used after end- of-data, if the message for transport to reflect
organizational policies.

4.3. Things which SHOULD Be Done
contains invalid addresses in the header.

5. Recommended Actions

The MSA SHOULD do all of the following:

Gellens, Klensin Expires September 1998 [Page 7]
Internet Draft SMTP Message Submission March 1998

4.3.1.

5.1. Be the Only MSA

The

An MSA MAY SHOULD 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

Reply code 556 should 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 this.

4.3.2. 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 may might be interested in local configuration problems,
but not in client problems at other sites.

4.4. Things which MUST NOT Be Done

6. Optional Actions

The MSA MUST NOT MAY do any of the following:

4.4.1. Corrupt the Message

6.1. Enforce Submission Rights

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 issue an error response to contain proprietary information)

4.5. Things which MUST Be Done

The MSA MUST do all of the following:

4.5.1. Ensure All Domains are Fully-Qualified

The MSA MUST ensure that all domains in MAIL FROM command if the envelope are
fully-qualified. Single-level domains (for example, 'sales') MAY
be expanded based on local configuration (for example,
address in MAIL FROM appears to
'sales.foo.com'). Multi-level domains which are not
fully-qualified (for example, 'sales.foo') MUST be rejected, have insufficient submission rights,
or is invalid, or is not
expanded. Response authorized with the authentication used (if
the session has been authenticated).

Reply code 555 should be 560 is used for this purpose.

6.2. Require Authentication

The MSA MAY issue an error response to reject a the MAIL FROM
or RCPT TO command which contains improper domains.

If if the
session has not been authenticated.

Reply code 503 is used for this purpose.

6.3. Enforce Permissions

The MSA examines or alters MAY issue an error response to the message text in way, except RCPT TO command if
inconsistent with the permissions given 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 user (if the preceding paragraph
apply. Response session
has been authenticated).

Reply code 555 should be 560 is used for this purpose.

6.4. Check Message Data

The MSA MAY issue an error response to reject a the DATA command
which contains improper domains.

Gellens, or send a
failure result after end-of-data if the submitted message is

Gellens & Klensin Expires September November 1998 [Page 8] 9]
Internet Draft SMTP Message Submission March May 1998

4.5.2. Enforce Address Syntax

The MSA MUST reject messages

syntactically invalid, or seems inconsistent with detectably illegal syntax in a
sender permissions given
to the user (if known), or recipient address. This applies after any address
transformations have been done. Response violated site policy in some way.

Reply code 554 is used for syntactic problems in the data. Reply
code 501 should be is used if the command itself is not syntactically valid.
Reply code 560 is used to reject a MAIL FROM or RCPT TO command which contains an improper
address. 555 may be based on the submitting user.
Reply code 561 is used after end-of-data if the message contains
invalid addresses in the header.

4.5.3. Use RELAY

The MSA MUST use the RELAY parameter violates site policy.

7. Submission Extension Mechanism

It may be desirable to extend the MAIL FROM command when
relaying the message, if the server MTA understands ESMTP and
supports submission process in the RELAY extension.

This requirement applies to "pure" MSAs, future,
using a mechanism which accept message
submissions and relay them via is clearly differentiated from normal SMTP. In certain cases,

This specification defines a site may
need special configurations, in new verb, SUBM, which MSAs and/or MTAs is only valid on
the submit
messages to an MSA for additional policy validation. These MSAs port. Clients MAY issue SUBM in addition to, or
MTAs are considered gateways, because they do not follow in place
of EHLO, that is, after the normal
model.

4.5.4. Add 'Change-ID' server has sent the initial greeting and 'Change-History'
before any transaction.

The MSA MUST Document all modifications to the envelope or text by
adding client MAY send a 'Change-ID' and one domain name or more 'Change-History' header
fields. A transparent encoding change literal as a parameter to the envelope or text
header, for example, removing extraneous quotes from an envelope
recipient, does not need
SUBM command.

SUBM is used to identify the server and any submission-only
extensions it supports. SMTP extensions continue to be noted in a Change-History header
field. announced
using EHLO.

Servers SHOULD support SUBM, even though no submission-only
extensions are currently defined.

The MSA MUST add 'Change-ID' SUBM command functions like the EHLO and 'Change-History' in addition to HELO commands; a
'Received' header; 'Change-ID' "250
OK" reply to any of them confirms that both the client and 'Change-History' server
are not
substitutes for 'Received'.

'Change-ID' in the initial state, that is, there is a structured header field which allows an MSA to
provide trace no transaction in
progress and contact information should problems with its
changes be detected. All parameter names all state tables and parameter values buffers are
case-insensitive, unless otherwise noted. Exactly 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 'Change-ID'
header field or more parameters. The syntax for a
positive response is <ehlo-ok-rsp> as specified in RFC 1869 [ESMTP].

Clients MUST be added.

'Change-History' is prepared for a structured header field which allows an MSA 5xx error response to list the changes it made. All parameter names SUBM.

Submit-only extensions MUST be registered with IANA and parameter
values are case-insensitive, unless otherwise noted.

Each 'Change-History' header field contains parameters describing MUST be
defined in a
specific change made by the MSA.

Gellens, standards-track or IESG-approved experimental protocol
RFC. See "IANA Considerations" for more information.

7.1. SUBM Syntax

SUBM = "SUBM" [domain] ; <domain defined in RFC 821>

Gellens & Klensin Expires September November 1998 [Page 9] 10]
Internet Draft SMTP Message Submission March May 1998

5. 'Change-ID' and 'Change-History'

5.1. Parameters of 'Change-ID'

7.2. SUBM Example

C: SUBM bar.foo.gork
S: 250 submit.foo.gork no extensions supported

8. Interaction with SMTP Extensions

The following parameters are defined for the 'Change-ID' header
field. Additional parameters may be specified in table lists 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 current standards-track or IESG-approved Experimental RFC.

A registration template is included in this memo.

5.1.1. Date

'Date' is required and contains the time and date at which the
change was made.

5.1.2. 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
Experimental SMTP extensions. Listed are the parameter value must be
treated RFC, name, status, an
indication as case sensitive; that is, its case must be preserved. The
domain form identifies the domain name or IP address of the MSA.

5.1.3. Port

'Port' is a required parameter which indicates to the TCP port extension's use on
which the message was received.

5.1.4. Contact

'Contact' is submit port, and a required parameter. It specifies a fully-qualified
email address, which is
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 contact point Submission port.

Some SMTP extensions are especially useful for problems detected by
the recipient of message submission:

Extended Status Codes [SMTP-CODES], SHOULD be supported and used
according to [CODES-EXTENSION]. This permits the message. It is generally not a good idea MSA to
use notify the email address
client of an individual. Instead, role addresses
should be used. For example, 'MSA-Admin' specific configuration or 'mail-nanny' for other problems in more detail
than the
local-part, which could then response codes listed in this memo. Because some
rejections are related to a site's security policy, care should be aliased
used not to one or expose more specific
people, or even detail than is needed to another role address (such as 'postmaster').

5.2. Parameters of 'Change-History'

The following parameters are defined for correct the 'Change-History'
header field. Additional parameters may
problem.

[PIPELINING] SHOULD be defined in supported by 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]
Internet Draft MSA.

Methods have been proposed which would allow for SMTP Message Submission March 1998

parameters must be specified in a standards-track or IESG-approved
Experimental RFC.

A registration template is included in this memo.

5.2.1. Element

The 'Element' parameter is required
authentication. These extensions, if supported and identifies which header
field or envelope item was changed. If used, would
allow the body was changed (for
example, upgraded MSA to MIME and content-transfer-encoded), 'body'
should be specified.

5.2.2. Action

The 'Action' parameter is required validate the authority and specifies determine the type identity
of
change: 'Added', 'Expanded', 'Quoted', 'Unquoted', 'Changed', or
'Removed'.

5.2.3. 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 submitting user.

Any references to changes required by site policy, as opposed the DATA command in this memo also refer to
corrections or additions required any
substitutes for conformance with Internet
standards.

5.2.4. Original

'Original' is an optional parameter which contains the value of DATA, such as the
field or subfield (individual value of a multi-valued field) before
it was changed. 'Original' SHOULD NOT be BDAT command used if 'Element' is
'body'.

5.2.5. Result

'Result' is an optional parameter which contains the value of the
field or subfield after it was changed.

5.3. ABNF for 'Change-ID'

Gellens, with [CHUNKING].

Gellens & Klensin Expires September November 1998 [Page 11]
Internet Draft SMTP Message Submission March May 1998

This defines

9. Change-ID and Change-History

These headers are defined to permit MSAs that modify messages to be
able to record the syntax for nature of those changes. MSA software that
performs such modifications SHOULD use the 'Change-ID' header field using ABNF parameters defined here
so as specified to assist in RFC 2234 [ABNF]. Comments later analysis of possible problems with the
message.

'Change-ID' is a structured header field which allows an MSA to
provide trace and folding white space
[RFC-822] may contact information should problems with its
changes be inserted wherever 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 space message.

'Change-History' is specified, a structured header field which allows an MSA to
list the changes it made. All parameter names and
nowhere else.

change-id ::= "Change-ID" ":" SP id-parameters

contact ::= "Contact" "=" "<" local-part "@" (domain /
IP) ">"

date ::= "Date" "=" [weekday "," SP] day SP month SP
year SP hour ":" minute [":" second] SP
time-zone

day ::= 2DIGIT

domain ::= sub-domain 1*("." sub-domain)

dot-string ::= 1*(atext ["." atext])

hour ::= 1*2DIGIT

id-parameters ::= date ";" SP msa ";" SP port ";" SP contact
*(";" SP ext-parameter)

IP ::= "[" (IPv4-literal / IPv6-literal) "]"

IPv4-literal ::= snum 3("." snum)

IPv6-literal ::= simple-char *(simple-char / SP)

ldh-str ::= *(alphanumeric / "-") alphanumeric

local-part ::= dot-string | quoted-string

minute ::= 2DIGIT

month ::= 2DIGIT

msa ::= "MSA" "=" (msa-domain / msa-literal)

msa-domain ::= domain / IP

msa-literal ::= quoted-string

port ::= "Port" "=" 1*DIGIT

second ::= 2DIGIT

sub-domain ::= alphanumeric *(ldh-str)

time-zone ::= ("+" / "-") 4DIGIT

Gellens, Klensin Expires September 1998 [Page 12]
Internet Draft SMTP Message Submission March 1998

weekday ::= "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"

year ::= 4DIGIT

5.4. ABNF for parameter values
are case-insensitive, unless otherwise noted.

Each 'Change-History'

This defines header field contains parameters describing a
specific change made by the syntax MSA.

9.1. Parameters of Change-ID

The following parameters are defined for the 'Change-History' 'Change-ID' header field using
[ABNF]. Comments and folding white space [RFC-822]
field. Additional parameters may be inserted
wherever specified in the future, and
MUST be registered with IANA. Optional parameters are registered on
a space first-come, first-served basis. Required parameters must be
specified in a standards-track or IESG-approved Experimental RFC.

A registration template is specified, included in this memo.

9.1.1. Date

'Date' is required and nowhere else.

action ::= "Action" "=" ("Added" / "Changed"
/ "Expanded" / "Quoted" / "Removed"
/ "Unquoted")

cause ::= "Cause" "=" ("Bad-Syntax" / "Incorrect"
/ "Missing" / "Nickname" / "Policy")

change-history ::= "Change-History" ":" SP hist-parameters

element ::= field / envelope

envelope ::= "Envelope" "=" ("MAIL" / "RCPT" / "DATA" /
ext-parameter)

field ::= "Field" "=" ("body" / header-field)

header-field ::= <header field as specified contains the time and date at which the
change was made.

9.1.2. MSA

'MSA' is a required parameter, which can be in [HEADERS]>

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

5.5. Common ABNF one of two forms:
domain or software.

The following [ABNF] rules and terminals are referenced above:
alphanumeric ::= ALPHA / DIGIT

atext ::= alphanumeric /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /

Gellens, 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 September November 1998 [Page 13] 12]
Internet Draft SMTP Message Submission March May 1998

"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"

ext-parameter ::= [alphanumeric *(alphanumeric / "." / "-")]
alphanumeric

ldh-str ::= *(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

The software form is in the range exclamation
;mark through tilde, except quote and
;semicolon

simple-value ::= 1*simple-char

snum ::= 1*3DIGIT ;range 0 through 255

5.6. Examples style of 'Change-ID' and 'Change-History'

Change-ID: Date="Fri, 20 March 1997 19:32 +0800";
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 Now @$1.99 Doe"

Change-ID: Date="Fri, 20 March 1997 19:32 +0800";
MSA="xyz99abc";
Contact=<admin+msa@Shy.Qualcomm.Com>;
Change-History: Field=From; Action=Changed; Cause=Policy

Gellens, Klensin Expires September 1998 [Page 14]
Internet Draft SMTP Message Submission March 1998

6. Submission Extension Mechanism a message-ID. It may be desirable first has a
string that is sufficient for the postmaster at the contact domain
to extend identify the submission process in software that modified the future,
using a mechanism message. The second part
is the contact domain which is clearly differentiated from normal SMTP.

This specification defines responsible for the MSA.

9.1.3. Contact

'Contact' is a new verb, SUBM, required parameter. It specifies a fully-qualified
email address, which is only valid on the submit port. Clients may send SUBM at any time after contact point for problems detected by
the
server has sent recipient of the initial greeting. Until such time as
submission extensions are defined, servers SHOULD send message. It is generally not a 250
response. Clients MUST good idea to
use the email address of an individual. Instead, role addresses
should be prepared used. For example, 'MSA-Admin' or 'mail-nanny' for a 502 (command not
implemented) response.

6.1. 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,
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
indication if optional parameter which indicates the extension is valid TCP port number
on which the submit port, and a
reference:

RFC Name Status Submission Reference
---- --------------- ------ ---------- ------------------
2197 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]
1846 521 E No [521REPLY]
1845 Checkpoint E Yes [Checkpoint]
1830 Binary E Yes [CHUNKING]
1652 8-bit MIME DS Yes [8BITMIME] message was received.

9.2. Parameters of Change-History

The MSA advertises support following parameters are defined for specific extensions in the EHLO
response, as usual.

Future extensions 'Change-History' header
field. Additional parameters may be defined which are intended for use only in the future, and MUST
be registered with SMTP transfer, IANA. Optional parameters are registered on a
first-come, first-served basis. Required parameters must be
specified in a standards-track or only with IESG-approved Experimental RFC.

A registration template is included in this memo.

9.2.1. Element

The 'Element' parameter is required and identifies the submission service. Future
extensions should explicitly specify if they are valid with SMTP,
Submission, header field
or both.

Some SMTP extensions are especially useful for message submission:

Gellens, 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 September November 1998 [Page 15] 13]
Internet Draft SMTP Message Submission March May 1998

Extended Status Codes [SMTP-CODES], SHOULD be supported

9.2.3. Cause

The 'Cause' parameter is optional and used
according to [CODES-EXTENSION]. This permits identifies the MSA to notify justification
for the
client of specific configuration or other problems in more detail
than change:

* 'Bad-Syntax' indicates the response codes listed in this memo. Because some
rejections are related to a site's security policy, care should be
used original value was 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 syntactically
valid.
* 'Incorrect' means the identity
of original value was not correct.
* 'Missing' is used when a field or item is added.
* 'Alias' indicates the submitting user.

Any references original value was a local DNS alias.
* 'Policy' refers to the DATA command in this memo also refer changes required by site policy, as opposed
to any
substitutes corrections or additions required for DATA, such as the BDAT command used conformance with
[CHUNKING].

8. Message Rejection and Bouncing

MTAs and MSAs MAY choose to implement message rejection rules
Internet standards.

9.2.4. Original

'Original' is an optional parameter which
rely in part on whether contains the message is a submission value of the
field or subfield (individual value of 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 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 do not
come from local users (based on IP address and/or authenticated
identity).

If contains the MSA is not able to determine a return path to value of the submitting
user (from a valid MAIL FROM,
field or based on authenticated identify), subfield after it MUST immediately reject the message. A message can was changed.

'Result' SHOULD NOT 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 used if 'Element' is unable to determine a valid
return path 'body'.

9.3. ABNF for Change-ID

This defines the message being submitted, text in this memo
which instructs an MSA to issue a rejection code MAY be complied
with by accepting syntax for the message 'Change-ID' header field using ABNF
as specified in RFC 2234 [ABNF]. Comments and subsequently generating folding white space
[MESSAGE-FORMAT] may be inserted wherever a bounce
message. Note that in the normal case of message submission,
immediately rejecting the message space is preferred, as it gives the
user specified, and MUA direct feedback. To properly handle delayed bounces,
the client must maintain a queue
nowhere else. Encoding of messages it has submitted, date/time and
match bounces email address information
conforms to them. In the case of batch submission, the client
is requesting the delayed bounce behavior.

9. Reply Codes

Gellens, [MESSAGE-FORMAT] conventions.

change-id = "Change-ID" ":" SP id-parameters

contact = "Contact" "=" "<" local-part "@" domain ">"

date = "Date" "=" date-time

date-time = <date-time as specified in [MESSAGE-FORMAT],
specifically RFC 821 section 5.1, as modified
by RFC-1123 section 5.2.14, except that
4-digit years MUST be used>

Gellens & Klensin Expires September November 1998 [Page 16] 14]
Internet Draft SMTP Message Submission March May 1998

This memo adds several reply codes to those

domain = <domain as 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 [SMTP-MTA]>

id-parameters = date ";" SP msa [";" SP port] ";" SP contact
*(";" SP ext-parameter)

local-part = <defined in contents of MAIL FROM,
RCPT TO, or DATA).
555 Bad domain. Invalid or improper [SMTP-MTA]>

msa = "MSA" "=" [msa-literal "@"] msa-domain

msa-domain = 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

msa-literal = quoted-string

port = "Port" "=" 1*DIGIT

9.4. ABNF for Change-History

This defines the authentication used; syntax for the address in 'Change-History' header field using
[ABNF]. Comments and folding white space [MESSAGE-FORMAT] may be
inserted wherever a
RCPT TO command is inconsistent with the permissions given to the
user; the message data space is rejected based on 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 = <header field as specified in [HEADERS]>

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 submitting user.

An implementation MAY include a configuration option to generate
554 instead range exclamation
;mark through tilde, except quote and
;semicolon

simple-value = 1*simple-char

9.6. Examples of 560, to avoid revealing information about
security-related rejections. Change-ID and Change-History

Change-ID: Date=Fri, 20 March 1997 19:32 +0800;
MSA=helpful.qualcomm.gork;
Contact=<Postmaster@Qualcomm.Gork>
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=<admin+msa@Shy.Qualcomm.Gork>;
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' and 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,

Gellens & Klensin Expires September November 1998 [Page 17]
Internet Draft SMTP Message Submission March 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 more secure policies. 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 or 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

Gellens, Klensin Expires September 1998 [Page 18]
Internet Draft SMTP Message Submission March 1998 total email security policy.

The 'Change-History' Change-History header field allows for problem tracking and
reporting, through use of the 'Contact' Contact and 'MSA' MSA parameters. Sites
wanting to prevent disclosure of details of their local network
(such as the identities of local servers) should use the token software
form, while other 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 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, <ftp://ftp.isi.edu/in-notes/rfc1846.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>

[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", November 1997,
<ftp://ftp.isi.edu/in-notes/rfc2234.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>

[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

<ftp://ftp.isi.edu/in-notes/rfc1830.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>

[DSN] K. Moore, "SMTP Service Extension for Delivery Status
Notifications, January 1996,
<ftp://ftp.isi.edu/in-notes/rfc1891.txt>

[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>

[ETRN] J. De Winter, "SMTP Service Extension for Remote Message
Queue Starting", August 1996,
<ftp://ftp.isi.edu/in-notes/rfc1985.txt>

[HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076,
February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>

[KEYWORDS] S. Bradner, "Key words for use in RFCs to Harald Alvestrand, who started this effort and
wrote Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>

[MESSAGE-FORMAT] D. Crocker, "Standard for the original version format of the draft.

13. References

[ESMTP] 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>

[PIPELINING] N. Freed, "SMTP Service Extension for Command
Pipelining", September 1997,
<ftp://ftp.isi.edu/in-notes/rfc2197.txt>

[SIZE] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
Crocker, K. Moore, "SMTP Service Extensions", STD 10, RFC 1869,
Extension for Message Size Declaration, November 1995, <ftp://ftp.isi.edu/in-notes/rfc1869.txt>
<ftp://ftp.isi.edu/in-notes/rfc1870.txt>

[SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC
1893, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1893.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 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>

Gellens & Klensin Expires November 1998 [Page 20]
Internet Draft Message Submission May 1998

14. Full Copyright Statement

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 Hosts -- Application and
Support", STD 3, RFC 1123, October 1989,
<ftp://ftp.isi.edu/in-notes/rfc1123.txt>

[MESSAGE-FORMAT] D. Crocker, "Standard Society or other
Internet organizations, except as needed for the format purpose of ARPA
Internet text messages", STD 11, RFC 822, August 1982,
<ftp://ds.internic.net/rfc/rfc822.txt>; R. Braden, Editor,
"Requirements for
developing Internet Hosts -- Application and Support", STD
3, RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>

[KEYWORDS] S. Bradner, "Key words standards in which case the procedures for use
copyrights defined in RFCs the Internet Standards process must be
followed, or as required 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, 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 September November 1998 [Page 19] 21]
Internet Draft SMTP Message Submission March May 1998

[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

This appendix is provided as helpful, but not formal, guidance
outside 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, 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 D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July
1994, <ftp://ftp.isi.edu/in-notes/rfc1652.txt>

14. Full Copyright Statement

The MSA MUST ensure that any address it places in a 'Sender' field
is in fact a valid mail address.

16.2. Add 'Date'

This document and translations of MSA could add a 'Date' field to the submitted message, if it may be copied and furnished
lacks it, or correct the 'Date' field if it does not conform to
others, and derivative works that comment on
[MESSAGE-FORMAT] syntax.

16.3. Add 'Message-ID'

The MSA could add or otherwise explain replace the 'Message-ID' field, if it lacks it,
or assist in its implementation may be prepared, copied,
published 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 distributed, in whole 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 part, without restriction
the envelope and optionally in address fields of any kind, provided that the above copyright notice 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 this
paragraph ftp.ab.gork are included on all such copies 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 derivative works.
make it easier to move users.

However, this document itself may not only addresses, local-parts, or domains which match
specific local MSA configuration settings should be modified in any way, such
as by removing altered. It
would be very dangerous for the copyright notice or references MSA to the Internet
Society or other Internet organizations, except apply data-independent
rewriting rules, such as needed for always deleting the
purpose first element of developing Internet standards in which case the

Gellens, Klensin Expires September 1998 [Page 20]
Internet Draft SMTP Message Submission March 1998

procedures a
domain name. So, for copyrights defined in example, a rule which strips 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 left-most
element of the Internet Society or its successors or assigns.

This document and domain if 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 complete domain matches
'*.foo.bar.gork' would be acceptable.

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

Gellens, & Klensin Expires September November 1998 [Page 21] 23]

----