view Side-By-Side changes
SMTP Message Submission and Relay
Status of this Memo:
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
A version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested. Please send 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 document will expire before December 1997. Distribution of
this draft is unlimited. version reflects comments received during Last Call.
Copyright Notice
Copyright (C) The file name Internet Society 1998. All Rights Reserved.
Table of this version is draft-gellens-submit-05.txt Contents
1. SUBMIT Servers. . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. SMTP Extension for Message Relay Assertion . . . . . . . . . . . . 4
3. Actions when RELAY Is Used. . . . . . . . . . . . . . . . . . . . 5
Gellens, Klensin Expires September 1998 [Page 1]
Internet Draft SMTP Message Submission March 1998
4. Actions when the Message Is a Submission . . . . . . . . . . . . . 5
4.1. General Rules . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Specific Problems . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Rejection vs. Damage . . . . . . . . . . . . . . . . . . . . 5
4.2. Things which MAY Be Done . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . . 6
4.2.2. Require Authentication . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Enforce Permissions . . . . . . . . . . . . . . . . . . . . . 6
4.2.4. Check Message Data . . . . . . . . . . . . . . . . . . . . . . 6
4.2.5. Add 'Sender'. . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.6. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.7. Add 'Message-ID'. . . . . . . . . . . . . . . . . . . . . . . 6
4.2.8. Transfer Encode . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.9. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.10. Header Rewriting . . . . . . . . . . . . . . . . . . . . . . 7
4.2.11 Sign the Message . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.12 Encrypt the Message . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Things which SHOULD Be Done . . . . . . . . . . . . . . . . . . 7
4.3.1. Be the Only MSA . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Log Errors. . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Things which MUST NOT Be Done . . . . . . . . . . . . . . . . . 8
4.4.1. Corrupt the Message . . . . . . . . . . . . . . . . . . . . . 8
4.5. Things which MUST Be Done . . . . . . . . . . . . . . . . . . . 8
4.5.1. Ensure All Domains are Fully-Qualified. . . . . . . . . . . . 8
4.5.2. Enforce Address Syntax . . . . . . . . . . . . . . . . . . . . 9
4.5.3. Use RELAY . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.4. Add 'Change-ID' and 'Change-History' . . . . . . . . . . . . . 9
5. 'Change-ID' and 'Change-History'. . . . . . . . . . . . . . . . . 10
5.1. Parameters of 'Change-ID' . . . . . . . . . . . . . . . . . . . 10
5.1.1. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. MSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.3. Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.4. Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Parameters of 'Change-History' . . . . . . . . . . . . . . . . 10
5.2.1. Element . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.3. Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.4. Original . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.5. Result . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. ABNF for 'Change-ID' . . . . . . . . . . . . . . . . . . . . . 11
5.4. ABNF for 'Change-History' . . . . . . . . . . . . . . . . . . . 13
5.5. Common ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.6. Examples of 'Change-ID' and 'Change-History' . . . . . . . . . 14
6. Submission Extension Mechanism . . . . . . . . . . . . . . . . . 15
6.1. SUBM Example . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Interaction with Other SMTP Extensions . . . . . . . . . . . . . 15
8. Message Rejection and Bouncing . . . . . . . . . . . . . . . . . 16
9. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Registration Procedures . . . . . . . . . . . . . . . . . . . 17
10.2. Change Control . . . . . . . . . . . . . . . . . . . . . . . . 17
10.3. Registration Template . . . . . . . . . . . . . . . . . . . . 18
Gellens, Klensin Expires September 1998 [Page 2]
Internet Draft SMTP Message Submission March 1998
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 20
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Introduction
SMTP was defined as a message *relay* *transfer* protocol, that is, a means for
message transfer agents (MTAs)
to route (if needed) and deliver finished (complete) messages. SMTP forbids MTAs from altering
Message Transfer Agents (MTAs) are not supposed to alter the
message text, except to add 'Received' header fields.
Gellens, Alvestrand Expires November 1997 [Page 1]
Internet Draft Message Submission 'Received', 'Return-Path', and Relay May 1997 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.
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
Originally, users connected to servers from terminals, and all
processing occurred on the server. Now, a split-MUA model is
common, with MUA functionality occurring on both the user's own
system and the server. Protocols such as POP or IMAP provide one
side of the split-MUA architecture. SMTP has been used for the
other. This memo proposes that the submission protocol defined
here be used instead.
Messages being submitted are in some cases finished (complete)
messages, and in other cases are unfinished (incomplete) in some
aspect or other. Unfinished messages need to be completed to
ensure they conform to [RFC-822], [RFC-1123], [MESSAGE-FORMAT], and later requirements.
For example, the message may lack proper Date 'Date' or Message-ID headers, 'Message-ID'
header fields, and domains might not be fully qualified. In some
cases, the MUA may be unable to generate finished (complete) messages (for
example, it might not know its time zone). Even when submitted
messages are
finished (complete), complete, local site policy may dictate that the
message text be modified in some ways. Such completions or
modifications
violate the letter have been shown to cause harm when performed by
downstream MTAs, and spirit are in general considered to be outside the
province of SMTP. MTAs.
This memo proposes a low cost, deterministic means for messages to
be identified as submissions or relays, 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 messages into submissions and relays transfers can have many
benefits for Internet mail in the short and long term. These
benefits include allowing sites to more easily implement security
policies and guard against unauthorized mail relaying (and spam
injection),
injection of unsolicited bulk email), making it easier to detect
configuration problems with a site's mail clients, providing a
migration path to get relays MTAs out of the dangerous business of
modifying mail, and providing a basis for adding additional
functionality in the future.
2.
Definitions of Terms Used in this Memo
Fully-Qualified
Containing or consisting of a domain which can be resolved using
DNS; not a local alias.
Message Transfer Agent (MTA)
A process which conforms to [SMTP-MTA], which accepts messages as
an SMTP server, and either delivers them, or acts as an SMTP client
to relay them to another MTA.
Message User Agent (MUA)
A process which acts (usually on behalf of a user) to compose and
submit new messages, and process delivered messages. In the
split-MUA model, POP or IMAP is used to access delivered messages.
Conventions Used in this Document
In examples, "C:" is used to indicate lines sent by the client, and
"S:" indicates those sent by the server. Line breaks within a
command example are for editorial purposes only.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS].
1. SUBMIT Servers
To distinguish relay transfer SMTP from submission, port 587 is reserved
as the MAIL SUBMIT port. Messages received on this port are assumed
defined to be submissions, even though the submissions. The protocol used is otherwise SMTP. ESMTP [SMTP-MTA,
ESMTP], with modifications as specified in this memo.
The process which acts as a submission server will be referred to
as a Message Submission Agent (MSA) to distinguish it from an MTA,
which acts as a relay transfer agent.
3.
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 on a separate port
from
relay, transfer, to aid in migration this memo extends SMTP [ESMTP]
to enable assertion that a message on port 25 is not a submission.
The name of this extension is "Relay".
The EHLO keyword is RELAY.
One new optional parameter is defined for the MAIL FROM verb:
RELAY.
Gellens, Alvestrand Expires November 1997 [Page 2]
Internet Draft Message Submission and Relay May 1997
If RELAY is used with the MAIL FROM command, the message is to be
treated as a relay. If RELAY appears in MAIL FROM for a message
received on the SUBMIT port, the message MUST NOT be treated as a
submission; relay; that is, the MSA may either treat MTA is being informed that it as a relay or reject the
MAIL FROM command with 504.
If RELAY is
not used, and the message originating or submitting MTA.
RELAY is received only for use on the relay SMTP port (port 25), the MTA may either treat port. If RELAY appears in MAIL
FROM on the message as a
relay, or use SUBMIT port, the guidelines in section 8 to determine if MSA MUST reject the
message is a submission or a relay.
4. command with 504.
3. Actions when RELAY Is Used
If the MAIL FROM command has the RELAY parameter, the MTA is being
informed that this message is being relayed, and therefore the
letter and spirit of SMTP MUST be followed. The MTA
MUST NOT alter the text, except to add a 'Received' header field.
5. as specified in [SMTP-MTA].
4. Actions when the Message Is a Submission
5.1.
4.1. General Rules
5.1.1.
4.1.1. Specific Problems
Even though various modifications to header fields are authorized
in this memo, a paramount rule is that elements of structured
header fields may only be modified when specific problems are
recognized which have clear solutions. This is especially true
with address elements. For example, indiscriminately appending
'@foo.com' to an address or element which lacks an '@' results in
more broken addresses. If an An unqualified address lacks an '@', it must be verified to
be a valid local part in the domain before the domain can be added.
5.1.2.
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. This is especially true of problems which are
correctable by the MUA (for example, an invalid 'From' field). In
these situations, the MSA may either accept the message and
subsequently issue a bounce, or use response
Response code 554 should be used to reject a MAIL FROM, RCPT TO, or
Gellens, Klensin Expires September 1998 [Page 5]
Internet Draft SMTP Message Submission March 1998
DATA command which contains something improper.
5.2.
4.2. Things which MAY Be Done by the
The MSA if MAY do any of the Message Is a following:
4.2.1. Enforce Submission
5.2.1. Refuse Rights
The MSA MAY refuse the MAIL FROM command if the address in MAIL
FROM is not
Gellens, Alvestrand Expires November 1997 [Page 3]
Internet Draft Message Submission and Relay May 1997 believed to have submission rights, or is invalid. invalid, or
is not authorized with the authentication used (if the session has
been authenticated). Failure code 554 560 should be used for this
purpose.
5.2.2. Refuse
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 the MAIL FROM, or a RCPT TO command if
inconsistent with the permissions given to the user (if known).
Failure code 560 should be used.
4.2.4. Check Message Data
The MSA MAY refuse the DATA command or send a failure result after
end-of-data if the submitted message is syntactically invalid, or
seems inconsistent with permissions given to the user (if known).
Result code 554 should be used. The MSA MAY instead accept used for syntactic problems in the
message and subsequently issue a bounce.
5.2.3. Add data
(500 or replace a 'Sender' field, 501 is used if the command itself is not syntactically
valid). 560 should be used to reject based on the submitting user.
4.2.5. Add 'Sender'
The MSA MAY add or replace the 'Sender' field, if the identity of
the sender is known and this is not given in the 'From' field. The
MSA MUST ensure that any address it places in a 'Sender' field is
in fact a valid mail address.
5.2.4.
4.2.6. Add 'Date'
The MSA MAY add a 'Date' field to the submitted message, if it
lacks it, or correct the 'Date' field if it does not conform to [RFC-822] syntax
(as modified by [RFC-1123]). If the
[MESSAGE-FORMAT] syntax.
Gellens, Klensin Expires September 1998 [Page 6]
Internet Draft SMTP Message Submission March 1998
4.2.7. Add 'Message-ID'
The MSA adds or changes the 'Date'
field, it SHOULD MAY add a comment to the field indicating this. This
is because an altered or MSA-created 'Date' field is likely to be
misleading to replace the recipient.
5.2.5. Add a 'Message-ID' field to the submitted message, field, if it lacks
it.
5.2.6. it,
or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
4.2.8. Transfer encode Encode
The MSA MAY apply transfer encoding to the message according to
MIME conventions, if needed and not harmful to the MIME type.
5.2.7.
4.2.9. Resolve Aliases
The MSA MAY resolve aliases (CNAME records) for domain names, in
the envelope as well as and optionally in address fields of the header,
subject to local policy. For example, if www.ab.com and ftp.ab.com
are both aliases for mail.ab.com, rewriting them could lose useful
information.
5.2.8. Rewrite
4.2.10. Header Rewriting
The MSA MAY rewrite local parts and/or domains, in the envelope as well as and
optionally in address fields of the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as
'J.Random.User' in order to hide logon names, and/or to rewrite
'squeeky.sales.xyz.com' as 'zyx.com' to hide machine names and make
it easier to move users.
However, only addresses addresses, local-parts, or domains which match
specific local MSA configuration settings may be altered. The MSA
MUST NOT apply data-independent rewriting rules, such as always
deleting the first element of a domain name.
5.3. So, for example, a
rule which strips the left-most element of the domain if the
complete domain matches '*.foo.bar.com' would be permitted.
4.2.11 Sign the Message
The MSA MAY (digitally) sign or otherwise add authentication
information to the message.
4.2.12 Encrypt the Message
The MSA MAY encrypt the message for transport to reflect
organizational policies.
4.3. Things which MUST SHOULD Be Done by the
The MSA if SHOULD do all of the Message Is a
Submission following:
Gellens, Alvestrand Klensin Expires November 1997 September 1998 [Page 4] 7]
Internet Draft SMTP Message Submission and Relay May 1997
5.3.1. Ensure all domains (in the envelope as well as March 1998
4.3.1. Be the text) are
fully-qualified. Single-level domains (for example, 'sales') Only MSA
The MSA MAY be
expanded based on local configuration (for example, to
'sales.foo.com'). Multi-level domains which are not fully-qualified
(for example, 'sales.foo') MUST be rejected, not expanded. Response
code 554 should be used to reject messages which already contain a MAIL FROM, RCPT TO, 'Change-ID' or DATA
command which contains improper domains. The MSA MAY instead accept
the command and subsequently issue a bounce.
5.3.2. Reject messages with detectably illegal syntax in a sender
'Change-History' header field, or
recipient address. This applies after any address transformations otherwise appear to have already
been done. through an MSA. Generally, the MSA SHOULD do this unless it
knows it is a gateway receiving messages from downstream MSAs.
Response code 554 556 should be used to reject a MAIL
FROM, RCPT TO, or DATA command which contains improper domains. for this.
4.3.2. Log Errors
The MSA MAY instead accept the SHOULD log message and subsequently issue a bounce.
5.3.3. Use the RELAY parameter errors, especially apparent
misconfigurations of client software. It can be very helpful to
notify the MAIL FROM command administrator when relaying
the message, if the server MTA understands ESMTP and supports the
RELAY extension.
5.4. problems are detected with local mail
clients. This is another advantage of distinguishing submission
from relay: system administrators may be interested in local
configuration problems, but not in client problems at other sites.
4.4. Things which MUST NOT Be Done by the
The MSA if MUST NOT do any of the following:
4.4.1. Corrupt the Message Is a
Submission
5.4.1. Alter
The MSA MUST NOT alter already valid headers or text in ways not
authorized by this memo. However, the MSA MAY reject or bounce
messages which violate site policy in some way. (For example,
messages which appear to contain proprietary information)
5.5.
4.5. Things which SHOULD MUST Be Done by the
The MSA if the Message Is a
Submission
5.5.1. Log message errors, especially apparent misconfigurations MUST do all of
client software. It can be very helpful to notify the local
postmaster when problems following:
4.5.1. Ensure All Domains are detected with local mail clients. This
is another advantage of distinguishing submission from relay: local
postmasters Fully-Qualified
The MSA MUST ensure that all domains in the envelope are likely to
fully-qualified. Single-level domains (for example, 'sales') MAY
be interested in expanded based on local configuration
problems, but (for example, to
'sales.foo.com'). Multi-level domains which are not in client problems at other sites.
5.5.2. If the MSA treats a message as a submission (see also section 8)
and as
fully-qualified (for example, 'sales.foo') MUST be rejected, not
expanded. Response code 555 should be used to reject a result modifies MAIL FROM
or RCPT TO command which contains improper domains.
If the contents of any structured header
fields MSA examines or makes other significant changes, alters the message text in way, except to
add 'Received', 'Change-ID', and 'Change-History' header fields, it SHOULD document
MUST ensure that all
such alterations domains in the text are fully-qualified. The
rules for single and multi-level domains in the preceding paragraph
apply. Response code 555 should be used to reject a DATA command
which contains improper domains.
Gellens, Klensin Expires September 1998 [Page 8]
Internet Draft SMTP Message Submission March 1998
4.5.2. Enforce Address Syntax
The MSA MUST reject messages with detectably illegal syntax in a
sender or recipient address. This applies after any address
transformations have been done. Response code 501 should be used
to reject a MAIL FROM or RCPT TO command which contains an improper
address. 555 may be used after end-of-data if the message contains
invalid addresses in the header.
4.5.3. Use RELAY
The MSA MUST use the RELAY parameter to the MAIL FROM command when
relaying the message, if the server MTA understands ESMTP and
supports the RELAY extension.
This requirement applies to "pure" MSAs, which accept message
submissions and relay them via SMTP. In certain cases, a site may
need special configurations, in which MSAs and/or MTAs submit
messages to an MSA for additional policy validation. These MSAs or
MTAs are considered gateways, because they do not follow the normal
model.
4.5.4. Add 'Change-ID' and 'Change-History'
The MSA MUST Document all modifications to the envelope or text by
adding a 'Change-ID' and one or more 'Change-History' header
fields. A transparent encoding change to the envelope or text
header, for example, removing extraneous quotes from an envelope
recipient, does not need to be noted in a Change-History header
field.
The MSA MUST add 'Change-ID' and 'Change-History' in addition to a
'Received' header; 'Change-ID' and 'Change-History' are not
substitutes for 'Received'.
'Change-ID' is a structured header field which allows an MSA to
Gellens, Alvestrand Expires November 1997 [Page 5]
Internet Draft Message Submission and Relay May 1997
list the changes it made, and to
provide trace and contact information should problems with its
changes be detected. All parameter names and parameter values are case-insensitive, unless
otherwise noted.
5.5.3. parameter values are
case-insensitive, unless otherwise noted. Exactly one 'Change-ID'
header field MUST be added.
'Change-History' is a structured header field which allows an MSA
to list the changes it made. All parameter names and parameter
values are case-insensitive, unless otherwise noted.
Each 'Change-History' header field contains parameters describing a
specific change made by the MSA.
Gellens, Klensin Expires September 1998 [Page 9]
Internet Draft SMTP Message Submission March 1998
5. 'Change-ID' and 'Change-History'
5.1. Parameters of 'Change-History' 'Change-ID'
The following parameters are defined for the 'Change-History' 'Change-ID' header
field. Additional parameters may be defined specified in the future, and will
must be registered with IANA. Names beginning with 'X' or 'x' are
reserved for non-standard parameters. Other names Optional parameters are reserved for
standard parameters.
5.5.3.1. The 'Contact-Domain' parameter
'Contact-Domain' is registered
on a required parameter. It specifies first-come, first-served basis. Required parameters must be
specified in a FQDN, the
postmaster of which 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 contact point for problems detected by
the recipient of time and date at which the message.
5.5.3.2. The 'MSA' parameter
While
change was made.
5.1.2. MSA
'MSA' is an optional a required parameter, either it or
'MSA-Identity-Token' is required. 'MSA' lists the FQDN which can be in one of the MSA.
5.5.3.3. two forms.
The 'MSA-Identity-Token' parameter
While 'MSA-Identity-Token' token form is an optional parameter, either it or
'MSA' is required. 'MSA-Identity-Token' is any a quoted string which is sufficient for the
postmaster at the contact domain to identify the software which
modified the message. This form of the parameter value must be
treated as case sensitive; that is, its case must be preserved.
This allows the generating site to use values which are either
case sensitive 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 the TCP port on
which the message was received.
5.1.4. Contact
'Contact' is a required parameter. It specifies a fully-qualified
email address, which is the contact point for problems detected by
the recipient of the message. It is generally not a good idea to
use the email address of an individual. Instead, role addresses
should be used. For example, 'MSA-Admin' or 'mail-nanny' for the
local-part, which could then be aliased to one or more specific
people, or even to another role address (such as 'postmaster').
5.2. Parameters of 'Change-History'
The following parameters are defined for the 'Change-History'
header field. Additional parameters may be defined in the future,
and 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 SMTP Message Submission March 1998
parameters must be specified in a standards-track or insensitive.
5.5.3.4. The 'Date' parameter
'Date' IESG-approved
Experimental RFC.
A registration template is required and contains the time and date at which the
change was made, using syntax as included in [RFC-822] and [RFC-1123].
5.5.3.5. The 'Element' parameter this memo.
5.2.1. Element
The 'Element' parameter is required and identifies which header
field or envelope item was changed. If the body was changed (for
example, upgraded to MIME and content-transfer-encoded), 'body'
should be specified. If a multi-valued field or item (such as an
address field) was changed, the specific element MAY be indicated by
appending a dot and an integer. For example, the first address in
Gellens, Alvestrand Expires November 1997 [Page 6]
Internet Draft Message Submission and Relay May 1997
'To' would be 'To.1', and the first RCPT TO would be 'RCPT.1'.
5.5.3.6. The 'Action' parameter
5.2.2. Action
The 'Action' parameter is required and specifies the type of
change: 'Added', 'Expanded', 'Quoted', 'Unquoted', 'Changed', or
'Removed'.
5.5.3.7. The 'Cause' parameter
5.2.3. Cause
The 'Cause' parameter optionally identifies the justification for
the change: 'Bad-Syntax', 'Incorrect', 'Missing', 'Nickname', or
'Policy'.
5.5.3.8. The 'Bad-Syntax' indicates the original value was not
syntactically valid. 'Incorrect' means the original value was not
correct. 'Missing' is used when a field or item has been added.
'Nickname' indicates the original value was a local DNS alias.
'Policy' refers to changes required by site policy, as opposed to
corrections or additions required for conformance with Internet
standards.
5.2.4. Original
'Original' is an optional parameter which contains the value of the
field or subfield (individual value of a multi-valued field) before
it was changed. 'Original' SHOULD NOT be used if 'Element' is
'body'.
5.2.5. Result
'Result' is an optional parameter which contains the value of the
field before any changes were made.
5.5.4. or subfield after it was changed.
5.3. ABNF for 'Change-ID'
Gellens, Klensin Expires September 1998 [Page 11]
Internet Draft SMTP Message Submission March 1998
This defines the syntax for the 'Change-ID' header field using ABNF
as specified in RFC 2234 [ABNF]. Comments and folding white space
[RFC-822] may be inserted wherever a space is specified, and
nowhere else.
change-id ::= "Change-ID" ":" SP id-parameters
contact ::= "Contact" "=" "<" local-part "@" (domain /
IP) ">"
date ::= "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 'Change-History'
This defines the syntax for the 'Change-History' header field using
terminals as specified in RFC 2045 [MIME-IMB]:
change-history ::= "Change-History:" parameter *(";" parameter)
parameter ::= action / contact-domain / cause / date
/ element / msa / msa-identity-token
/ original
[ABNF]. Comments and folding white space [RFC-822] may be inserted
wherever a space is specified, and nowhere else.
action ::= "Action" "=" ("Added" / "Changed"
/ "Expanded" / "Quoted" / "Removed"
/ "Unquoted")
contact-domain ::= "Contact-Domain" "=" <FQDN>
cause ::= "Cause" "=" ("Bad-Syntax" / "Incorrect"
/ "Missing" / "Nickname" / "Policy")
date
change-history ::= "Date" "=" <quoted-string containing
date-time as specified in RFCs 822 and 1123> "Change-History" ":" SP hist-parameters
element ::= field / envelope
envelope ::= "Envelope" "=" ("MAIL" / "RCPT") "RCPT" / "DATA" /
ext-parameter)
field ::= "Field" "=" ("body" / header-field)
header-field ::= <header field as specified in RFCs 822 or 2076 [HEADERS]>)
msa [HEADERS]>
hist-parameters ::= "MSA" element ";" SP action [";" SP cause]
[";" SP original] [";" SP result]
*(";" SP ext-parameter)
original ::= "Original" "=" value
result ::= "Result" "=" <FQDN> value
value ::= simple-value / quoted-string
5.5. Common ABNF
The following [ABNF] rules and terminals are referenced above:
alphanumeric ::= ALPHA / DIGIT
atext ::= alphanumeric /
"!" / "#" /
"$" / "%" /
"&" / "'" /
"*" / "+" /
Gellens, Alvestrand Klensin Expires November 1997 September 1998 [Page 7] 13]
Internet Draft SMTP Message Submission March 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 in the range exclamation
;mark through tilde, except quote and Relay May 1997
msa-identity-token
;semicolon
simple-value ::= "MSA-Identity-Token" "=" value
original 1*simple-char
snum ::= "Original" "=" value
5.5.11. 1*3DIGIT ;range 0 through 255
5.6. Examples of 'Change-ID' and 'Change-History'
Change-History:
Change-ID: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com;
Contact=<Postmaster@Qualcomm.Com>
Change-History: Envelope=MAIL; Action=Changed; Cause=Policy
Change-History: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com;
Envelope=RCPT.1; Envelope=RCPT; Action=Expanded; Cause=Nickname; Original=Foo
Original=Foo; Result=Foobar
Change-History: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=To.1; Field=To; Action=Expanded; Cause=Nickname; Original=Foo
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=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com;
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
It may be desirable to extend the submission process in the future,
using a mechanism which is clearly differentiated from normal SMTP.
This specification defines a new verb, SUBM, which is only valid on
the submit port. Clients may send SUBM at any time after the
server has sent the initial greeting. Until such time as
submission extensions are defined, servers SHOULD send a 250
response. Clients MUST be prepared for a 502 (command not
implemented) response.
6.1. SUBM Example
C: SUBM S: 250 No extensions supported
7. Interaction with Other Other SMTP Extensions
The following table lists the current standards-track and
Experimental SMTP extensions. Listed are the RFC, name, status, an
indication if the extension is valid on the submit port, and a
reference:
RFC Name Status Submission Reference
---- --------------- ------ ---------- ------------------
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]
The MSA advertises support for specific extensions in the EHLO
response, as usual.
Future extensions may be defined which are intended for use only
with SMTP Extensions transfer, or only with the submission service. Future
extensions should explicitly specify if they are valid with SMTP,
Submission, or both.
Some SMTP extensions are especially useful for message submission:
Gellens, Klensin Expires September 1998 [Page 15]
Internet Draft SMTP Message Submission March 1998
Extended Status Codes [SMTP-CODES], if SHOULD be supported and used
according to [CODES-EXTENSION], [CODES-EXTENSION]. This permits the MSA to notify the
client of specific configuration or other problems. In particular, when
result code 554 is used problems in more detail
than the response codes listed in this memo. Because some
rejections are related to reject a MAIL FROM, RCPT TO, or DATA
command, or if 504 is site's security policy, care should be
used not to reject a MAIL FROM command, expose more detail than is needed to correct the codes
defined in [SMTP-CODES] will
problem.
[PIPELINING] SHOULD be helpful. supported by the MSA.
Methods have been proposed which would allow for SMTP
authentication. These extensions, if supported and used, would
allow the MSA to validate the authority and determine the identity
of the submitting user.
7.
Any references to the DATA command in this memo also refer to any
substitutes for DATA, such as the BDAT command used with
[CHUNKING].
8. Message Rejection
The MTA and Bouncing
MTAs and MSAs MAY choose to implement message rejection rules which
rely in part on whether the message is a submission or a relay.
For example, some sites might configure their MTA and MSA to reject all
RCPT TOs for messages being relayed which do not reference local users, and/or and
configure their MSA to reject all message submissions which do not
come from local users (based on IP address and/or authenticated
identity).
The
If the MSA may is not able to determine a return path to the submitting
user (from a valid MAIL FROM, or based on authenticated identify),
it MUST immediately reject the message. A message can be
immediately rejected by returning a 5xx code to the MAIL FROM
command or after receiving the data.
Except in the case where the MSA is unable to comply determine a valid
return path for the message being submitted, text in this memo
which instructs an MSA to issue a rejection code MAY be complied
with by accepting the message and subsequently generating a bounce
message. Note that in the normal case of message submission,
immediately rejecting the message is preferred, as it gives the
user and MUA direct feedback. To properly handle delayed bounces,
the requirements for relaying client must maintain a
submitted message. For example, queue of messages it has submitted, and
match bounces to them. In the domain names in case of batch submission, the message client
is requesting the delayed bounce behavior.
9. Reply Codes
Gellens, Alvestrand Klensin Expires November 1997 September 1998 [Page 8] 16]
Internet Draft SMTP Message Submission and Relay May 1997
headers and/or envelope might be unqualified and either unknown or
ambiguous, preventing the MSA from qualifying them. If the MSA is
able March 1998
This memo adds several reply codes to produce a valid message, it may either reject the message
immediately, those defined in [SMTP-MTA].
The reply codes used in this document are:
250 Requested action okay, completed.
502 Command not implemented.
503 Bad sequence of commands.
505 Authentication required. Site policy requires authentication
before issuing this command.
554 Transaction Failed. (Various errors in contents of MAIL FROM,
RCPT TO, or accept it and issue DATA).
555 Bad domain. Invalid or improper domain in MAIL FROM, RCPT TO,
or DATA.
556 Not a bounce. If the MSA submission. The message appears to have been submitted
earlier.
560 Not allowed. The address in MAIL FROM is not
able
believed to determine have submission rights, or is invalid, or is not
authorized with the authentication used; the address in a return path
RCPT TO command is inconsistent with the permissions given to the submitting user (from a valid
MAIL FROM, or
user; the message data is rejected based on authenticated identify), it MUST immediately
reject the message. A message can submitting user.
An implementation MAY include a configuration option to generate
554 instead of 560, to avoid revealing information about
security-related rejections.
10. IANA Considerations
10.1. Registration Procedures
'Change-ID' and 'Change-History' parameters MUST be immediately rejected registered with
IANA. Optional parameters are registered on a first-come,
first-served basis. Required parameters must be specified in a
standards-track or IESG-approved Experimental RFC.
Registration of a 'Change-ID' or 'Change-History' parameter is done
by
returning 554 filling in the template below and sending it in to iana@isi.edu.
IANA has the MAIL FROM command or after receiving right to reject obviously bogus registrations, but
will perform no review of clams made in the final
period.
8. Possible Other Cases registration form.
There is no naming convention for Treating Messages as Submissions
For backwards compatibility with older mailers 'Change-ID' and MTAs, the MTA MAY
consider 'Change-History'
parameters.
10.2. Change Control
Once a 'Change-ID' and 'Change-History' parameter registration has
been published by IANA, the message author may request a submission, and treat it change to its
definition. The change request follows the same procedure as above, under some
combinations of the following circumstances:
8.1.
registration request.
Gellens, Klensin Expires September 1998 [Page 17]
Internet Draft SMTP Message Submission March 1998
The message lacks any 'Received' fields.
8.2. 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 message comes from IESG may reassign responsibility for a host known parameter, or make
changes to the MTA as being a "pure
client", such 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 PC.
8.3. The message lacks a 'Date' field.
8.4.
change to their "intended use" field; such parameters will be
clearly marked in the lists published by IANA.
The MTA knows that all IESG is considered to be the owner of its messages are submissions. For
example, an MTA and all clients might parameters which are
specified in standards track or IESG-approved Experimental RFCs.
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 configured so that all
submissions go through that MTA, and only submissions go through 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 MTA.
9. the author deems interesting may be
added below this line.)
11. Security Considerations
Separation of submission and relay of messages can allow a site to
implement more secure policies. This can aid in tracking spam, and
can allow a site to ensure that it is not used as a spam injection
point by outsiders. or
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' header field allows for problem tracking and
reporting, through use of the 'Contact-Domain' parameter with either
the 'Contact' and 'MSA' or the 'MSA-Identity-Token' parameter. parameters. Sites
wanting to prevent disclosing disclosure of details of their local network
(such as the identities of local servers) should use 'MSA-Identity-Token', the token
form, while sites without these concerns can use the simpler 'MSA' parameter.
10. domain
form.
12. Acknowledgments
This updated draft has been revised in part based on comments and
Gellens, Alvestrand Expires November 1997 [Page 9]
Internet Draft Message Submission and Relay May 1997
discussions which took place on and off the IETF-Submit mailing
list.
11.
Special thanks to Harald Alvestrand, who started this effort and
wrote the original version of the draft.
13. References
[ESMTP] J. Klensin, J., N. Freed, N., M. Rose, M., E. Stefferud, E., and D.
Crocker, "SMTP Service Extensions", RFC 1869, STD 10, United Nations
University, Innosoft International, Inc., Dover Beach Consulting,
Inc., Network Management Associates, Inc., The Branch Office, RFC 1869, November
1995, <ftp://ds.internic.net/rfc/rfc1869.txt>
[RFC-822] <ftp://ftp.isi.edu/in-notes/rfc1869.txt>
[SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.
Partridge, "Mail Routing and the Domain System", STD 14, RFC 974,
January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden,
Editor, "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989,
<ftp://ftp.isi.edu/in-notes/rfc1123.txt>
[MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA
Internet text messages", RFC 822, STD 11, University of Delaware, 08/13/1982,
<ftp://ds.internic.net/rfc/rfc822.txt>
[RFC-1123] 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, USC/Information Sciences
Institute, October 1989, <ftp://ds.internic.net/rfc/rfc1123.txt>
[SMTP] J. Postel, "Simple Mail Transfer Protocol", <ftp://ftp.isi.edu/in-notes/rfc1123.txt>
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 821, STD 10,
Information Sciences Institute, 08/01/1982,
<ftp://ds.internic.net/rfc/rfc821.txt> 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, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, Innosoft, October 1996,
<ftp://ds.internic.net/rfc/rfc2034.txt>
<ftp://ftp.isi.edu/in-notes/rfc2034.txt>
Gellens, Klensin Expires September 1998 [Page 19]
Internet Draft SMTP Message Submission March 1998
[SMTP-CODES] G. Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 1893, Octel Network Services, January 1996,
<ftp://ds.internic.net/rfc/rfc1893.txt>
[MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045,
Innosoft, First Virtual, November 1996,
<ftp://ds.internic.net/rfc/rfc2045.txt> <ftp://ftp.isi.edu/in-notes/rfc1893.txt>
[HEADERS] J. Palme, J., "Common Internet Message Headers", RFC 2076,
Stockholm University/KTH,
February 1997,
<ftp://ds.internic.net/rfc/rfc2076.txt>
12. <ftp://ftp.isi.edu/in-notes/rfc2076.txt>
[CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1830.txt>
[PIPELINING] N. Freed, "SMTP Service Extension for Command
Pipelining", September 1997,
<ftp://ftp.isi.edu/in-notes/rfc2197.txt>
[ETRN] J. De Winter, "SMTP Service Extension for Remote Message
Queue Starting", August 1996,
<ftp://ftp.isi.edu/in-notes/rfc1985.txt>
[DSN] K. Moore, "SMTP Service Extension for Delivery Status
Notifications, January 1996,
<ftp://ftp.isi.edu/in-notes/rfc1891.txt>
[SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service
Extension for Message Size Declaration, November 1995,
<ftp://ftp.isi.edu/in-notes/rfc1870.txt>
[521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code",
September 1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt>
[Checkpoint] D. Crocker, N. Freed, and A. Cargille, "SMTP
Service Extension for Checkpoint/Restart, September 1995,
<ftp://ftp.isi.edu/in-notes/rfc1845.txt>
[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July
1994, <ftp://ftp.isi.edu/in-notes/rfc1652.txt>
14. Full Copyright Statement
Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
Gellens, Klensin Expires September 1998 [Page 20]
Internet Draft SMTP Message Submission March 1998
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15. Authors' Addresses
Randall Gellens +1.619.651.5115
Qualcomm, Inc. +1.619.651.5334 +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.
Harald Tveit Alvestrand +47 73 59 70 94
John C. Klensin +1 617 960 1011
MCI Telecommunications klensin@mci.net
800 Boylston St, 7th floor
Boston, MA 02199
USA
Gellens, Alvestrand Klensin Expires November 1997 [Page 10]
Internet Draft Message Submission and Relay May 1997
UNINETT Harald.T.Alvestrand@uninett.no
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
Gellens, Alvestrand Expires November 1997 September 1998 [Page 11] 21]
----