WDIFF

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

Message Submission

Status of this Memo:

This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."

To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).

A version of this draft document will be submitted to the RFC editor
as a Proposed Standard Best Current Practice 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. Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Document Information . . . . . . . . . . . . . . . . . . . . . . . 4 3
2.1. Definitions of Terms Used in this Memo. . . . . . . . . . . . . 4 3
2.2. Conventions Used in this Document . . . . . . . . . . . . . . . 4
2.3. Changes from Previous Version . . . . . . . . . . . . . . . . . 5
3. Message Submission Protocol . Submission. . . . . . . . . . . . . . . . . . . 5

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

3.1. Submission Port . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . . . . . 5 4
3.2. Message Rejection and Bouncing Bouncing. . . . . . . . . . . . . . . . . 4
3.3 Authorized Submission . 5
3.3. Message Modification. . . . . . . . . . . . . . . . . . . . . . 6 5

Gellens & Klensin Expires December 1998 [Page 1]
Internet Draft Message Submission June 1998

3.4. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . . . 7 6
4.1. General Submission Rejection Code . . . . . . . . . . . . . . . 7 6
4.2. Ensure All Domains are Fully-Qualified. . . . . . . . . . . . . 7
4.3. Enforce Address Syntax . . . . . . . . Fully-Qualified . . . . . . . . . . . . . 8 7
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . . . 8 7
5.1. Be the Only MSA . . . Enforce Address Syntax . . . . . . . . . . . . . . . . . . . . . 8 7
5.2. Add 'Change-ID' and 'Change-History'. . . . . . . . . . . . . . 8
5.3. Log Errors Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7
6. Optional Actions. Actions . . . . . . . . . . . . . . . . . . . . . . . . 9 . 8
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . . . 9 8
6.2. Require Authentication. Authentication . . . . . . . . . . . . . . . . . . . . 9 . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . . . . . 9 8
6.4. Check Message Data. . . . . . . . . . . . . . . Data . . . . . . . . 9
7. Submission Extension Mechanism . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions. . . 10
7.1. SUBM Syntax. . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . 10
7.2. SUBM Example . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . 11
8. Interaction with SMTP Extensions . . . . . . . . . . . 10
8.2. Add 'Date' . . . . . 11
9. Change-ID and Change-History . . . . . . . . . . . . . . . . . . 12
9.1. Parameters of Change-ID. . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . 12
9.1.1. Date . . . . . . . 10
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . 12
9.1.2. MSA. . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . 12
9.1.3. Contact . . . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases. . . . . . . . 13
9.1.4. Port . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . 13
9.2. Parameters of Change-History . . . . . . . . . . . 11
9. Security Considerations. . . . . . . 13
9.2.1. Element. . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . 13
9.2.2. Action . . . . . . . . . . . . 11
11. References. . . . . . . . . . . . . . . . 13
9.2.3. Cause. . . . . . . . . . . . 12
12. Full Copyright Statement . . . . . . . . . . . . . . . . 14
9.2.4. Original . . . . 13
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 14
9.2.5. Result . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.3. ABNF for Change-ID . . . . . . . . . . . . . . . . . . . . . . 14
9.4. ABNF for Change-History. . . . . . . . . . . . . . . . . . . . 15
9.5. Common ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.6. Examples of Change-ID and Change-History . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Registration Procedures . . . . . . . . . . . . . . . . . . . 16
10.1.1. Change-ID and Change-History . . . . . . . . . . . . . . . . 16
10.1.2. Submit. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Change Control . . . . . . . . . . . . . . . . . . . . . . . . 17
10.3. Registration Template . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 21
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
16. Appendix: Message Modifications. . . . . . . . . . . . . . . . 21
16.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.2. Add 'Date'. . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . . . . 22

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

16.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . . . 22
16.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . . . 22
16.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . . . 22
16.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . . . 22
16.8. Header Rewriting. . . . . . . . . . . . . . . . . . . . . . . 23

1. Abstract

SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver finished (complete) messages.
Message Transfer Agents (MTAs) are not supposed to alter the message
text, except to add 'Received', 'Return-Path', and other header
fields as required by [SMTP-MTA].

However, SMTP is now also widely used as a message *submission*
protocol, that is, a means for message user agents (MUAs) to
introduce new messages into the MTA routing network. Regardless of
whether this is good or bad, it is far too late to change.

Originally, users connected to servers from terminals, and all
processing occurred on the server. Now, a split-MUA model is
common, with MUA functionality occurring on both the user's own
system and the server. Protocols such as POP or IMAP provide one
side of the split-MUA architecture. SMTP has been used for the
submission side. This memo proposes that the submission protocol
defined here be used instead.

Messages being submitted are in some cases finished (complete)
messages, and in other cases are unfinished (incomplete) in some
aspect or other. Unfinished messages need to be completed to ensure
they conform to [MESSAGE-FORMAT], and later requirements. For
example, the message may lack proper 'Date' or 'Message-ID' header
fields, and domains might not be fully qualified. In some cases,
the MUA may be unable to generate finished messages (for example, it
might not know its time zone). Even when submitted messages are
complete, local site policy may dictate that the message text be
modified in some ways. Such completions or modifications have been
shown to cause harm when performed by downstream MTAs -- that is,
MTAs after the first-hop submission MTA -- and are in general
considered to be outside the province of standardized MTA
functionality.

Separating messages into submissions and transfers allows developers
and network administrators to more easily:

* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail

* Implement authenticated submission, including off-site
submission by authorized users such as travelers

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

* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for
different programs for relay and submission

* Provide a migration path to get MTAs out of the dangerous
business of modifying mail

* Detect configuration problems with a site's mail clients

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

This memo proposes a low cost, deterministic means for messages to
be identified as submissions, and specifies what actions are to be
taken by a submission server.

2. Document Information

2.1. Definitions of Terms Used in this Memo

Fully-Qualified

Containing or consisting of a domain which can be globally resolved
using the global Domain Name Service; that is, not a local alias or
partial specification.

Message Submission Agent (MSA)

A process which conforms to this specification, which acts as a
submission server to accept messages from MUAs, and either delivers
them or acts as an SMTP client to relay them to an MTA.

Message Transfer Agent (MTA)

A process which conforms to [SMTP-MTA], which acts as an SMTP server
to accept messages from an MSA or another MTA, and either delivers
them or acts as an SMTP client to relay them to another MTA.

Message User Agent (MUA)

A process which acts (usually on behalf of a user) to compose and
submit new messages, and process delivered messages. In the
split-MUA model, POP or IMAP is used to access delivered messages.

2.2. Conventions Used in this Document

In examples, "C:" is used to indicate lines sent by the client, and
"S:" indicates those sent by the server. Line breaks within a
command example are for editorial purposes only.

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

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS].

2.3. Changes from Previous Version

o Message modifications moved into advisory appendix.
o RELAY SMTP extension removed.
o SUBM extension mechanism more clearly defined.
o Change-ID and Change-History SHOULDs not MUSTs.
o Example domains end in ".gork" instead of ".com"
o Date-time, domain, and local-part ABNF use RFC 821/822.
o Added text making it clear the "X-" convention is not used.
o Added text to clearly permit MAIL FROM <>.
o SMTP extension table uses SHOULD / MUST NOT / MAY.
o "Nickname" changed to "Alias".
o "MSA" Change-ID parameter simplified.
o Numerous rearrangements and miscellaneous cleanups.
o Acknowledgments updated.

3. Message Submission Protocol

3.1. Submission Port

Port 587 is reserved for the mail Submit protocol as defined in this
document. Messages received on this port are defined to be
submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
modifications as specified in this document.

3.2. Message Rejection and Bouncing

MTAs and MSAs MAY implement message rejection rules that rely in
part on whether the message is a submission or a relay.

For example, some sites might configure their MTA to reject all RCPT
TOs for messages that do not reference local users, and configure
their MSA to reject all message submissions that do not come from
authorized users, based on IP address, or authenticated identity.

When a problem with a message is detected, and the MSA has no rule
specifically configured for that problem, the MSA SHOULD reject the
message rather than attempt to fix it.

NOTE: It is better to reject a message than to risk sending one
that is damaged. This is especially true for problems that are
correctable by the MUA, for example, an invalid 'From' field.

If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA MUST immediately reject the

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

message. A message can be immediately rejected by returning a 5xx
code to the MAIL FROM command or after receiving the DATA command.

Note that a null return path, that is, MAIL FROM <>, is permitted
and MUST be accepted. (MUAs need to generate null return-path
messages for a variety of reasons, including disposition
notifications.)

Except in the case where the MSA is unable to determine a valid
return path for the message being submitted, text in this
specification which instructs an MSA to issue a rejection code MAY
be complied with by accepting the message and subsequently
generating a bounce message.

NOTE: In the normal case of message submission, immediately
rejecting the message is preferred, as it gives the user and MUA
direct feedback. To properly handle delayed bounces the client MUA
must maintain a queue of messages it has submitted, and match
bounces to them.

3.3. Message Modification

For this version of the message submission specification,
modification to headers and content of messages received from user
agents is a matter for local convention. The Appendix contains a
discussion of the types of message modification for which there is
already some operational experience.

NOTE: As a matter of guidance for local decisions to implement
message modification, a paramount rule is to limit such actions to
remedies for specific problems that have clear solutions. This is
especially true with address elements. For example,
indiscriminately appending a domain to an address or element which
lacks one typically results in more broken addresses. An
unqualified address must be verified to be a valid local part in the
domain before the domain can be safely added.

3.4. Reply Codes

This memo adds several reply codes to those defined in [SMTP-MTA].
The reply codes used in this document are:

250 Requested action okay, completed.

501 Syntax error in parameters or arguments.

502 Command not implemented.

503 Bad sequence of commands.

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

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

554 Transaction Failed. (Various errors in contents of
MAIL FROM, RCPT TO, or DATA).

555 Bad domain or address. Invalid or improper domain or address
in MAIL FROM, RCPT TO, or DATA.

556 Not a submission. The message appears to have been submitted
earlier.

560 Not allowed. The address in MAIL FROM appears to have
insufficient submission rights, or is invalid, or is not
authorized with the authentication used; the address in a
RCPT TO command is inconsistent with the permissions given
to the user; the message data is rejected based on the
submitting user.

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

An implementation MAY include a configuration option to generate 554
instead of 560, to avoid revealing information about
security-related rejections.

4. Mandatory Actions

An MSA MUST do all of the following:

4.1. General Submission Rejection Code

Unless covered by a more precise response code, response code 554
MUST be used to reject

1. Abstract

SMTP was defined as a MAIL FROM, RCPT TO, or DATA command that
contains something improper.

4.2. Ensure All Domains are Fully-Qualified

The MSA MUST ensure that all domains in the envelope are
fully-qualified.

If the MSA examines or alters the message text in way, except to add
'Received', 'Change-ID', and 'Change-History' header fields, it MUST
ensure *transfer* protocol, that all domains in the header are fully-qualified.

Reply code 555 is to be used to reject is, a MAIL FROM, RCPT TO, or DATA
command which contains improper domains references.

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

NOTE: A frequent local convention is means
to accept single-level domains
(for example, 'sales') route (if needed) and then to expand the reference by adding
the remaining portion of the domain name (for example, to
'sales.foo.gork'). It is strongly advised that local conventions
that permit single-level domains reject, rather than expand,
multi-level domains, since such expansion is particularly risky.

4.3. Enforce Address Syntax

An MSA MUST reject messages with illegal syntax in a sender or
recipient envelope address.

If the MSA examines or alters deliver finished (complete) messages.
Message Transfer Agents (MTAs) are not supposed to alter the message text in way,
text, except to add 'Received', 'Change-ID', 'Return-Path', and 'Change-History' other header fields, it MUST
reject messages with illegal address syntax in the header.

Reply code 501
fields as required by [SMTP-MTA].

However, SMTP is to be now also widely used to reject as a MAIL FROM or RCPT TO
command message *submission*
protocol, that contains is, a detectably improper address.

When addresses are resolved after submission of the means for message body,
reply code 555 is user agents (MUAs) to be used after end- of-data, if the message
contains invalid addresses in
introduce new messages into the header.

5. Recommended Actions MTA routing network. The MSA SHOULD do all of the following:

5.1. Be the Only MSA

An MSA SHOULD reject messages process
which already contain accepts message submissions from MUAs is termed a 'Change-ID' or
'Change-History' header field, Message
Submission Agent (MSA).

Messages being submitted are in some cases finished (complete)
messages, and in other cases are unfinished (incomplete) in some
aspect or otherwise appear to have already
been through an MSA.

Reply code 556 is other. Unfinished messages need to be used completed to reject messages which have already
been submitted.

5.2. Add 'Change-ID' ensure
they conform to [MESSAGE-FORMAT], and 'Change-History' later requirements. For sites exercising local conventions involving message header or
content changes, the MSA SHOULD note the nature of
example, the changes
through use of 'Change-ID' and one message may lack proper 'Date' or more 'Change-History' 'Message-ID' header
fields. These two fields are defined later in this specification.

A transparent encoding change to
fields, and domains might not be fully qualified. In some cases,
the envelope or text header, for MUA may be unable to generate finished messages (for example, removing extraneous quotes from an envelope recipient, does it
might not need to know its time zone). Even when submitted messages are
complete, local site policy may dictate that the message text be noted in a 'Change-History' header field.

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

'Change-ID' and 'Change-History' are not substitutes for appropriate
use of 'Received' headers.

5.3. Log Errors

The MSA SHOULD log message errors, especially apparent
misconfigurations of client software.

Note: It can be very helpful

examined or modified in some way. Such completions or modifications
have been shown to notify the administrator cause harm when
problems are detected with local mail clients. This is another
advantage of distinguishing performed by downstream MTAs --
that is, MTAs after the first-hop submission from relay: system
administrators might be interested in local configuration problems,
but not MTA -- and are in client problems at other sites.

6. Optional Actions

The MSA MAY do any of the following:

6.1. Enforce Submission Rights

The MSA MAY issue an error response
general considered to be outside the MAIL FROM command if the
address in MAIL FROM appears province of standardized MTA
functionality.

Separating messages into submissions and transfers allows developers
and network administrators to have insufficient submission rights,
or is invalid, more easily:

* Implement security policies and guard against unauthorized mail
relaying or is not authorized with the authentication used (if
the session has been authenticated).

Reply code 560 is used for this purpose.

6.2. Require Authentication

The MSA MAY issue an error response to the MAIL FROM command if the
session has not been authenticated.

Reply code 503 is used for this purpose.

6.3. Enforce Permissions

The MSA MAY issue an error response to injection of unsolicited bulk mail

* Implement authenticated submission, including off-site
submission by authorized users such as travelers

* Separate the RCPT TO command if
inconsistent relevant software code differences, thereby making
each code base more straightforward and allowing for
different programs for relay and submission

* Detect configuration problems with a site's mail clients

* Provide a basis for adding enhanced submission services in the permissions given to the user (if the session
has been authenticated).

Reply code 560 is used
future

This memo describes a low cost, deterministic means for this purpose.

6.4. Check Message Data

The MSA MAY issue an error response messages to the DATA command
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 send consisting of a
failure result after end-of-data if domain which can be globally resolved
using the submitted message is

Gellens & Klensin Expires November 1998 [Page 9]
Internet Draft global Domain Name Service; that is, not a local alias or
partial specification.

Message Submission May 1998

syntactically invalid, or seems inconsistent with permissions given Agent (MSA)

A process which conforms to the user (if known), or violated site policy in some way.

Reply code 554 is used for syntactic problems in the data. Reply
code 501 is used if the command itself is not syntactically valid.
Reply code 560 is used this specification, which acts as a
submission server to reject based on the submitting user.
Reply code 561 is used if the message violates site policy.

7. Submission Extension Mechanism

It may be desirable accept messages from MUAs, and either delivers
them or acts as an SMTP client to extend the submission relay them to an MTA.

Message Transfer Agent (MTA)

A process in the future,
using a mechanism which is clearly differentiated from normal SMTP.

This specification defines a new verb, SUBM, conforms to [SMTP-MTA], which is only valid on
the submit port. Clients MAY issue SUBM in addition to, or in place
of EHLO, that is, after the acts as an SMTP server has sent the initial greeting
to accept messages from an MSA or another MTA, and
before any transaction.

The client MAY send a domain name either delivers
them or literal acts as an SMTP client to relay them to another MTA.

Gellens & Klensin Expires December 1998 [Page 3]
Internet Draft Message Submission June 1998

Message User Agent (MUA)

A process which acts (usually on behalf of a parameter user) to compose and
submit new messages, and process delivered messages. In the
SUBM command.

SUBM
split-MUA model, POP or IMAP is used to identify the server and any submission-only
extensions it supports. SMTP extensions continue access delivered messages.

2.2. Conventions Used in this Document

In examples, "C:" is used to be announced
using EHLO.

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

The SUBM command functions like indicate lines sent by the EHLO client, and HELO commands; a "250
OK" reply to any of them confirms that both
"S:" indicates those sent by the client and server server. Line breaks within a
command example are in for editorial purposes only.

All example domains use "gork" as the initial state, that is, there is no transaction in
progress and all state tables top-level domain.

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and buffers "MAY"
in this document are cleared.

The response to SUBM be interpreted as defined in [KEYWORDS].

3. Message Submission

3.1. Submission Identification

Port 587 is a multiline reply. If any submit-only
extensions are supported, each line of the response contains a
keyword and, optionally, one or more parameters. The syntax reserved for a
positive response is <ehlo-ok-rsp> email message submission as specified in RFC 1869 [ESMTP].

Clients MUST be prepared for a 5xx error response
this document. Messages received on this port are defined to SUBM.

Submit-only extensions MUST be registered
submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with IANA
additional restrictions as specified here.

While most email clients and MUST servers can be
defined in a standards-track configured to use port
587 instead of 25, there are cases where this is not possible or IESG-approved experimental protocol
RFC. See "IANA Considerations"
convenient. A site MAY choose to use port 25 for more information.

7.1. SUBM Syntax

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

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

7.2. SUBM Example

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

8. Interaction with SMTP Extensions

The following table lists the current standards-track message
submission, by designating some hosts to be MUAs and
Experimental SMTP extensions. Listed are the RFC, name, status, an
indication as others to the extension's use on the submit port, be
MTAs.

3.2. Message Rejection and a
reference:

RFC Name Status Submission Reference
---- --------------- ------ ---------- ------------------
2197 Pipelining DS SHOULD [PIPELINING]
2034 Error Codes PS SHOULD [CODES-EXTENSION]
1985 ETRN PS MUST NOT [ETRN]
1893 Extended Codes PS SHOULD [SMTP-CODES]
1891 DSN PS MAY [DSN]
1870 Size S MAY [SIZE]
1846 521 E MUST NOT [521REPLY]
1845 Checkpoint E MAY [Checkpoint]
1830 Binary E Bouncing

MTAs and MSAs MAY [CHUNKING]
1652 8-bit MIME DS SHOULD [8BITMIME]

Future SMTP extensions should explicitly specify if they are valid implement message rejection rules that rely in
part on whether the Submission port.

Some SMTP extensions are especially useful for message submission:

Extended Status Codes [SMTP-CODES], SHOULD be supported is a submission or a relay.

For example, some sites might configure their MTA to reject all RCPT
TOs for messages that do not reference local users, and used
according to [CODES-EXTENSION]. This permits the configure
their MSA to notify the
client of specific configuration reject all message submissions that do not come from
authorized users, based on IP address, or other problems in more detail
than the response codes listed in this memo. Because some
rejections are related to authenticated identity.

When a site's security policy, care should be
used not to expose more detail than problem with a message 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 detected, and used, would
allow the MSA to validate the authority and determine has no rule
specifically configured for that problem, the identity
of MSA SHOULD reject the submitting user.

Any references
message rather than attempt to the DATA command in this memo also refer fix it.

NOTE: It is better to any
substitutes reject a message than to risk sending one
that is damaged. This is especially true for DATA, such as problems that are
correctable by the BDAT command used with [CHUNKING]. MUA, for example, an invalid 'From' field.

Gellens & Klensin Expires November December 1998 [Page 11] 4]
Internet Draft Message Submission May June 1998

9. Change-ID and Change-History

These headers are defined

If an MSA is not able to permit MSAs that modify messages determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD 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 command.

Note that a null return path, that is, MAIL FROM <>, is permitted
and MUST be
able accepted. (MUAs need to record the nature generate null return-path
messages for a variety of those changes. MSA software that
performs such modifications SHOULD use the parameters defined here
so as to assist reasons, including disposition
notifications.)

Except in later analysis of possible problems with the
message.

'Change-ID' case where the MSA is unable to determine a structured header field valid
return path for the message being submitted, text in this
specification which allows instructs an MSA to
provide trace and contact information should problems with its
changes issue a rejection code MAY
be detected. All parameter names complied with by accepting the message and parameter values are
case-insensitive, unless otherwise noted. An MSA MUST NOT add more
than one 'Change-ID' header field to subsequently
generating a bounce message.

'Change-History'

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 structured header field which queue of messages it has submitted, and match
bounces to them.

3.3 Authorized Submission

Numerous methods have been used to ensure that only authorized users
are able to submit messages. These methods include authenticated
SMTP, IP address restrictions, secure IP, and prior POP
authentication.

Authenticated SMTP [SMTP-AUTH] SHOULD be supported if possible. It
allows an the MSA to
list determine an authorization identity for the changes it made. All parameter names and parameter values
message submission, which is not tied to other protocols.

IP address restrictions are case-insensitive, unless otherwise noted.

Each 'Change-History' header field contains parameters describing very widely implemented, but do not
allow for travellers and similar situations, and can be spoofed.

Secure IP [IPSEC] is a
specific change made by useful method for some situations.

Requiring a POP [POP3] authentication (from the MSA.

9.1. Parameters same IP address)
within some amount of Change-ID

The following parameters are defined for time (for example, 20 minutes) prior to the 'Change-ID' header
field. Additional parameters
start of a message submission session has also been used, but this
does impose restrictions on clients as well as servers which may be specified in
cause difficulties. Specifically, the future, and
MUST be registered with IANA. Optional parameters are registered on
a first-come, first-served basis. Required parameters client must be
specified in do a standards-track or IESG-approved Experimental RFC.

A registration template is included in this memo.

9.1.1. Date

'Date' is required POP
authentication before an SMTP submission session, and contains the time not all
clients are capable and date at which configured for this. Also, the
change was made.

9.1.2. MSA

'MSA' must
coordinate with the POP server, which may be difficult. There is
also a required parameter, window during which an unauthorized user can submit messages
and appear to be a prior authorized user.

Gellens & Klensin Expires December 1998 [Page 5]
Internet Draft Message Submission June 1998

3.4. Reply Codes

This memo adds several reply codes to those defined in one [SMTP-MTA].
The reply codes used in this document are:

250 Requested action okay, completed.

501 Syntax error in parameters or arguments.

502 Command not implemented.

503 Bad sequence of two forms: 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 or software.

The address. Invalid or improper domain form identifies or address
in MAIL FROM, RCPT TO, or DATA.

556 Not a submission. The message appears to have been submitted
earlier.

560 Not allowed. The address in MAIL FROM appears to have
insufficient submission rights, or is invalid, or is not
authorized with the domain name authentication used; the address in a
RCPT TO command is inconsistent with the permissions given
to the user; the message data is rejected based on the
submitting user.

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

An implementation MAY include a configuration option to generate 554
instead of the specific MSA that
made the changes.

The software form is provided for use by sites which don't want 560, to
reveal internal host names. This form avoid revealing information about
security-related rejections.

4. Mandatory Actions

An MSA MUST do all of the parameter value must following:

4.1. General Submission Rejection Code

Unless covered by a more precise response code, response code 554
MUST be treated as case sensitive; used to reject a MAIL FROM, RCPT TO, or DATA command that is, its case must be preserved.
contains something improper.

Gellens & Klensin Expires November December 1998 [Page 12] 6]
Internet Draft Message Submission May June 1998

4.2. Ensure All Domains are Fully-Qualified

The software form is MSA MUST ensure that all domains in the style of a message-ID. It first has a
string that is sufficient for envelope are
fully-qualified.

If the postmaster at MSA examines or alters the contact domain message text in way, except to identify the software add
'Received' header fields, it MUST ensure that modified the message. The second part
is the contact domain which is responsible for the MSA.

9.1.3. Contact

'Contact' all domains in address
header fields are fully-qualified.

Reply code 555 is to be used to reject a required parameter. It specifies a fully-qualified
email address, MAIL FROM, RCPT TO, or DATA
command which contains improper domains references.

NOTE: A frequent local convention is to accept single-level domains
(for example, 'sales') and then to expand the contact point for problems detected reference by adding
the recipient remaining portion of the message. domain name (for example, to
'sales.foo.gork'). It is generally not a good idea to
use the email address strongly advised that local conventions
that permit single-level domains reject, rather than expand,
multi-level domains, since such expansion is particularly risky.

5. Recommended Actions

The MSA SHOULD do all of an individual. Instead, role addresses
should be used. For example, 'MSA-Admin' the following:

5.1. Enforce Address Syntax

An MSA SHOULD reject messages with illegal syntax in a sender or 'mail-nanny' for
recipient envelope address.

If the
local-part, which could then be aliased to one or more specific
people, MSA examines or even to another role address (such as 'postmaster').

9.1.4. Port

'Port' is an optional parameter which indicates the TCP port number
on which alters the message was received.

9.2. Parameters of Change-History

The following parameters are defined for the 'Change-History' header
field. Additional parameters may be defined text in the future, and MUST
be registered way, except to add
'Received' header fields, it SHOULD reject messages 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 illegal
address syntax in this memo.

9.2.1. Element

The 'Element' parameter is required and identifies the address header field fields.

Reply code 501 is to be used to reject a MAIL FROM or envelope item RCPT TO
command that was changed. If contains a detectably improper address.

When addresses are resolved after submission of the content body was changed
(for example, upgraded to MIME and content-transfer-encoded), 'body' message body,
reply code 555 is to be specified.

9.2.2. Action used after end- of-data, if the message
contains invalid addresses in the header.

5.2. Log Errors

The 'Action' parameter is required and specifies MSA SHOULD log message errors, especially apparent
misconfigurations of client software.

Note: It can be very helpful to notify the type administrator when
problems are detected with local mail clients. This is another
advantage of change:

* Added
* Expanded
* Quoted
* Unquoted
* Changed
* Removed distinguishing submission from relay: system
administrators might be interested in local configuration problems,

Gellens & Klensin Expires November December 1998 [Page 13] 7]
Internet Draft Message Submission May June 1998

9.2.3. Cause

but not in client problems at other sites.

6. Optional Actions

The MSA MAY do any of the following:

6.1. Enforce Submission Rights

The 'Cause' parameter MSA MAY issue an error response to the MAIL FROM command if the
address in MAIL FROM appears to have insufficient submission rights,
or is optional and identifies invalid, or is not authorized with the justification
for authentication used (if
the change:

* 'Bad-Syntax' indicates session has been authenticated).

Reply code 560 is used for this purpose.

6.2. Require Authentication

The MSA MAY issue an error response to the original value was not syntactically
valid.
* 'Incorrect' means MAIL FROM command if the original value was
session has not correct.
* 'Missing' been authenticated.

Section 3.3 discusses authentication mechanisms.

Reply code 503 is used when a field or item is added.
* 'Alias' indicates the original value was a local DNS alias.
* 'Policy' refers to changes required by site policy, as opposed
to corrections or additions required for conformance with
Internet standards.

9.2.4. Original

'Original' is this purpose.

6.3. Enforce Permissions

The MSA MAY issue an optional parameter which contains the value of error response to the
field or subfield (individual value of a multi-valued field) before
it was changed.

'Original' SHOULD NOT be used RCPT TO command if 'Element' is 'body'.

9.2.5. Result

'Result'
inconsistent with the permissions given to the user (if the session
has been authenticated).

Reply code 560 is used for this purpose.

6.4. Check Message Data

The MSA MAY issue an optional parameter which contains the value of error response to the
field DATA command or subfield send a
failure result after it was changed.

'Result' SHOULD NOT be used end-of-data if 'Element' is 'body'.

9.3. ABNF for Change-ID

This defines the syntax for the 'Change-ID' header field using ABNF
as specified in RFC 2234 [ABNF]. Comments and folding white space
[MESSAGE-FORMAT] may be inserted wherever a space submitted message is specified, and
nowhere else. Encoding of date/time and email address information
conforms
syntactically invalid, or seems inconsistent with permissions given
to [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 November 1998 [Page 14]
Internet Draft Message Submission May 1998

domain = <domain as defined the user (if known), or violates site policy in [SMTP-MTA]>

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

local-part = <defined in [SMTP-MTA]>

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

msa-domain = domain

msa-literal = quoted-string

port = "Port" "=" 1*DIGIT

9.4. ABNF some way.

Reply code 554 is used for Change-History

This defines syntactic problems in the syntax for data. Reply
code 501 is used if the 'Change-History' header field using
[ABNF]. Comments and folding white space [MESSAGE-FORMAT] may be
inserted wherever a space command itself is specified, and nowhere else.

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

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

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

element = field / envelope

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

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

header-field = <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 not syntactically valid.
Reply code 560 is used to reject based on the submitting user.
Reply code 561 is used if the message violates site policy.

7. Interaction with SMTP Extensions

Gellens & Klensin Expires November December 1998 [Page 15] 8]
Internet Draft Message Submission May June 1998

The following [ABNF] rules and terminals are referenced above:

alphanumeric = ALPHA / DIGIT

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

printable-char = VCHAR / SP

quoted-char = printable-char / "\" quoted-specials

quoted-specials = DQUOTE / "\"

quoted-string = DQUOTE *quoted-char DQUOTE

simple-char = %x21 / %x23-3A / %x3C-7E
;ASCII character in the range exclamation
;mark through tilde, except quote and
;semicolon

simple-value = 1*simple-char

9.6. Examples of Change-ID and Change-History

Change-ID: Date=Fri, 20 March 1997 19:32 +0800;
MSA=helpful.qualcomm.gork;
Contact=<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 table lists the current standards-track or IESG-approved and
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 SMTP extensions. Listed are the parameter RFC, name, status, an
indication as to the syntax for
values, and a definition of its meaning.

Registration of a 'Change-ID' or 'Change-History' parameter is done
by filling in extension's use on the template below submit port, 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 a
reference:

Future SMTP extensions should explicitly specify if they are valid
on the registration form.

There is no naming convention for 'Change-ID' and 'Change-History'
parameters.

10.1.2. Submit

Submit Submission port.

Some SMTP extensions MUST are especially useful for message submission:

Extended Status Codes [SMTP-CODES], SHOULD be registered with IANA supported 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 used
according to [CODES-EXTENSION]. This permits the extension;

(3) MSA to notify the syntax and possible values
client of parameters associated with the
SUBM keyword value;

(4) any additional protocol verbs associated with specific configuration or other problems in more detail
than the extension
(additional verbs will usually be, but response codes listed in this memo. Because some
rejections are related to a site's security policy, care should be
used not required to be, the
same as expose more detail than is needed to correct the SUBM keyword value);

(5) any new parameters
problem.

[PIPELINING] SHOULD be supported by the extension associates with existing verbs;

(6) a description of how support for MSA.

[SMTP-AUTH] SHOULD be supported is possible. It allows the extension affects MSA to
validate the
behavior of a server authority and client; and,

(7) the increment, if any, by which the extension is increasing determine the
maximum length identity of existing commands.

There is no naming convention for Submit extensions. (Note that
there is no provision for using unregistered experimental
parameters, for example "x-". All extensions MUST be registered.)

10.2. Change Control

Once a 'Change-ID' or 'Change-History' parameter registration has
been published by IANA, the author may request a change submitting
user.

Any references to its
definition. The change request follows the same procedure DATA command in this memo also refer to any
substitutes for DATA, such as the
registration request.

Gellens & Klensin Expires November 1998 [Page 17]
Internet Draft BDAT command used with [CHUNKING].

8. Message Submission May 1998

The owner of a parameter may pass responsibility for it to another
person or agency by informing IANA; this can be done without
discussion or review.

The IESG may reassign responsibility for a parameter, or make
changes Modifications

Sites MAY modify submissions to ensure compliance with standards,
and/or site policy. This section describes 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; number of such parameters will be
clearly marked in the lists published by IANA.

The IESG is
modifications that are often considered to be the owner useful.

NOTE: As a matter 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 guidance for header (check one): [ ] Change-History [ ] Change-ID

Parameter name:

Nature (check one): [ ] Optional [ ] Required

Note: Required parameters must be specified in local decisions to implement
message modification, a standards-track or
IESG-approved Experimental RFC.

Security considerations:

Published specification:

Person & email address paramount rule is to limit such actions to contact
remedies for further information:

Intended usage (check one): [ ] COMMON [ ]LIMITED [ ] OBSOLETE

Author/Change controller:

(Any other information specific problems that the author deems interesting may be
added below this line.)

11. Security Considerations have clear solutions. This is

Gellens & Klensin Expires November December 1998 [Page 18] 9]
Internet Draft Message Submission May June 1998

Separation of submission and relay of messages can allow

especially true with address elements. For example,
indiscriminately appending a site domain to
implement different policies for the two types of services,
including requiring use of additional security mechanisms for one an address or
both. In can do this in a way element which is simpler, both technically
and administratively. This increases the likelihood that policies
will be applied correctly.

Separation also can aid
lacks one typically results in tracking and preventing unsolicited bulk
email.

For example, a site could configure its MSA more broken addresses. An
unqualified address must be verified to require
authentication before accepting be a message, and could configure its
MTA to reject all RCPT TOs for non-local users. This valid local part in the
domain before the domain can be an
important element in a site's total email security policy. safely added.

8.1. Add 'Sender'

The Change-History header field allows for problem tracking and
reporting, through use MSA could add or replace the 'Sender' field, if the identity of
the Contact sender is known and this is not given in the 'From' field.

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

8.2. Add 'Date'

The MSA could add a 'Date' field to prevent disclosure of details of their local network
(such as the identities of local servers) should use the software
form, while other sites can use the simpler domain form.

12. Acknowledgments

This updated draft has been revised in part based on comments and
discussions which took place on and off submitted message, if it
lacks it, or correct the IETF-Submit mailing
list. 'Date' field if it does not conform to
[MESSAGE-FORMAT] syntax.

8.3. Add 'Message-ID'

The help of those who took MSA could add or replace the time 'Message-ID' field, if it lacks it,
or it is not valid syntax (as defined by [MESSAGE-FORMAT]).

8.4. Transfer Encode

The MSA could apply transfer encoding 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 message according 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,
MIME conventions, if needed and A. Cargille, "SMTP Service
Extension not harmful to the MIME type.

8.5. Sign the Message

The MSA could (digitally) sign or otherwise add authentication
information to the message.

8.6. Encrypt the Message

The MSA could encrypt the message for Checkpoint/Restart, September 1995,
<ftp://ftp.isi.edu/in-notes/rfc1845.txt>

[CHUNKING] G. Vaudreuil, "SMTP Service Extensions transport to reflect
organizational policies.

8.7. Resolve Aliases

The MSA could resolve aliases (CNAME records) for Transmission
of Large domain names, in
the envelope and Binary MIME Messages", August 1995, optionally in address fields of the header, subject
to local policy.

Gellens & Klensin Expires November December 1998 [Page 19] 10]
Internet Draft Message Submission May June 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

Note: unconditionally resolving aliases could be harmful. For
example, if www.ab.gork and ftp.ab.gork are both aliases for Delivery Status
Notifications, January 1996,
<ftp://ftp.isi.edu/in-notes/rfc1891.txt>

[ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud,
mail.ab.gork, rewriting them could lose useful information.

8.8. Header Rewriting

The MSA MAY rewrite local parts and/or domains, in the envelope 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
optionally in address fields of the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as
'J.Random.User' in order to hide logon names, and/or to rewrite
'squeeky.sales.xyz.gork' as 'zyx.gork' to hide machine names and
make it easier to move users.

However, only addresses, local-parts, or domains which match
specific local MSA configuration settings should be altered. It
would be very dangerous for 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 the MSA to apply data-independent
rewriting rules, such as always deleting the first element of a
domain name. So, for use in RFCs example, a rule which strips the left-most
element of the domain if the complete domain matches
'*.foo.bar.gork' would be acceptable.

9. Security Considerations

Separation of submission and relay of messages can allow a site to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>

[MESSAGE-FORMAT] D. Crocker, "Standard
implement different policies for the format two types of ARPA
Internet text messages", STD 11, RFC 822, August 1982,
<ftp://ds.internic.net/rfc/rfc822.txt>; R. Braden, Editor,
"Requirements services,
including requiring use of additional security mechanisms for Internet Hosts -- Application one or
both. It can do this in a way which is simpler, both technically
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, administratively. This increases the likelihood that policies
will be applied correctly.

Separation also can aid in tracking and K. Moore, "SMTP Service
Extension 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 Message Size Declaration, November 1995,
<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 non-local users. This can be an
important element in a site's total email security policy.

If a site fails to require any form of authorization for message
submissions (as discussed in 3.3 ), it is allowing open use of its
resources and name, since unsolicited bulk email can be injected
using its facilities.

10. Acknowledgments

This updated draft has been revised in part based on comments and
discussions which took place on and off the Domain System", STD 14, RFC 974,
January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden,
Editor, "Requirements for Internet Hosts -- Application IETF-Submit mailing
list. The help of those who took the time to review the draft and
Support", STD 3, RFC 1123, October 1989,
<ftp://ftp.isi.edu/in-notes/rfc1123.txt>

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

14. Full Copyright Statement

This document and translations

make suggestions is appreciated, especially that of it may be copied Dave Crocker,
Ned Freed, Keith Moore, John Myers, and furnished Chris Newman.

Special thanks to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published Harald Alvestrand, who got this effort started.

11. References

[521REPLY] A. Durand, and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice 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 this paragraph
are included on all such copies 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 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 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 the purpose Transmission
of
developing Internet standards in which case the procedures Large and Binary MIME Messages", August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1830.txt>

[CODES-EXTENSION] N. Freed, "SMTP Service Extension 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 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 will not be
revoked by the 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 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 Headers", RFC 2076,
February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>

[IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 1825, August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1825.txt>

[KEYWORDS] S. Bradner, "Key words for use in RFCs 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. Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,

Gellens & Klensin Expires November December 1998 [Page 21] 12]
Internet Draft Message Submission May June 1998

This appendix is provided as helpful, but not formal, guidance
outside of the formal specification in the main part of this
document.

16.1. Add 'Sender'

The MSA could add or replace the 'Sender' field, if

<ftp://ftp.isi.edu/in-notes/rfc2119.txt>

[MESSAGE-FORMAT] D. Crocker, "Standard for the identity format of
the sender is known 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 this is not given in the 'From' field.

The MSA MUST ensure that any address it places in a 'Sender' field
is Support", STD 3,
RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>

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

[POP3] J. Myers, M. Rose, "Post Office Protocol -- Version 3", STD
53, RFC 1939, May 1996, <ftp://ftp.isi.edu/in-notes/rfc1939.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>

[SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication",
work in fact a valid mail address.

16.2. Add 'Date'

The MSA could add a 'Date' field to the submitted message, if it
lacks it, or correct the 'Date' field if it does not conform to
[MESSAGE-FORMAT] syntax.

16.3. Add 'Message-ID'

The MSA could add or replace the 'Message-ID' field, if it lacks it,
or it is not valid syntax (as defined by [MESSAGE-FORMAT]).

16.4. progress,
<ftp://ftp.ietf.org/internet-drafts/draft-myers-smtp-auth-11.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 Encode

The MSA could apply transfer encoding to the message according to
MIME conventions, if needed Protocol", STD 10, RFC
821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.
Partridge, "Mail Routing and not harmful to the MIME type.

16.5. Sign the Message

The MSA could (digitally) sign or otherwise add authentication
information to the message.

16.6. Encrypt the Message

The MSA could encrypt the message Domain System", STD 14, RFC 974,
January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden,
Editor, "Requirements for transport to reflect
organizational policies.

16.7. Resolve Aliases Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989,
<ftp://ftp.isi.edu/in-notes/rfc1123.txt>

12. Full Copyright Statement

This document and optionally in address fields translations of the header, subject
to local policy.

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

Note: unconditionally resolving aliases could it may be harmful. For
example, if www.ab.gork copied and ftp.ab.gork are both aliases for
mail.ab.gork, rewriting them could lose useful information.

16.8. Header Rewriting

The MSA MAY rewrite local parts and/or domains, furnished to
others, and derivative works that comment on or otherwise explain it
or assist in the envelope its implementation may be prepared, copied, published
and
optionally distributed, in address fields whole or in part, without restriction of any
kind, provided that 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 above copyright notice and this paragraph
are included on all such copies and
make it easier to move users. derivative works. However, only addresses, local-parts, or domains which match
specific local MSA configuration settings should be altered. It
would this
document itself may not be very dangerous for the MSA to apply data-independent
rewriting rules, modified in any way, such as always deleting by removing
the first element of a
domain name. So, copyright notice or references to the Internet Society or other
Internet organizations, except as needed for example, a rule which strips the left-most
element purpose of
developing Internet standards in which case the domain if procedures for
copyrights defined in the complete domain matches
'*.foo.bar.gork' would Internet Standards process must be acceptable.
followed, or as required to translate it into languages other than
English.

Gellens & Klensin Expires November December 1998 [Page 13]
Internet Draft Message Submission June 1998

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

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

Gellens & Klensin Expires December 1998 [Page 23] 14]

----