Internet Draft: Message Submission and Relay R. Gellens
Document: draft-gellens-submit-05.txt Qualcomm
Expires: 8 November 1997 H. Alvestrand
UNINETT
8 May, 1997
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 comments to
the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe,
send a message containing SUBSCRIBE to
<ietf-submit-request@imc.org>.
This document will expire before December 1997. Distribution of
this draft is unlimited.
The file name of this version is draft-gellens-submit-05.txt
1. Introduction
SMTP was defined as a message *relay* protocol, that is, a means for
message transfer agents (MTAs) to route finished (complete)
messages. SMTP forbids MTAs from altering the message text, except
to add 'Received' header fields.
Gellens, Alvestrand Expires November 1997 [Page 1]
Internet Draft Message Submission and Relay May 1997
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 to ensure
they conform to [RFC-822], [RFC-1123], and later requirements. For
example, the message may lack proper Date or Message-ID headers, 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), local site policy may dictate that the message
text be modified in some ways. Such completions or modifications
violate the letter and spirit of SMTP.
This memo proposes a low cost, deterministic means for messages to
be identified as submissions or relays, and specifies what actions
are to be taken by a submission server.
Separation of messages into submissions and relays 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), making it easier to detect configuration problems with a
site's mail clients, providing a migration path to get relays out of
the dangerous business of modifying mail, and providing a basis for
adding additional functionality in the future.
2. SUBMIT Servers
To distinguish relay SMTP from submission, port 587 is reserved as
the MAIL SUBMIT port. Messages received on this port are assumed to
be submissions, even though the protocol used is otherwise SMTP.
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 agent.
3. SMTP Extension for Message Relay Assertion
In addition to providing for SMTP submission on a separate port from
relay, 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; the MSA may either treat it as a relay or reject the
MAIL FROM command with 504.
If RELAY is not used, and the message is received on the relay
SMTP port (port 25), the MTA may either treat the message as a
relay, or use the guidelines in section 8 to determine if the
message is a submission or a relay.
4. 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. Actions when the Message Is a Submission
5.1. General Rules
5.1.1. 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 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. 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 code 554 to reject a
MAIL FROM, RCPT TO, or DATA command which contains something
improper.
5.2. Things which MAY Be Done by the MSA if the Message Is a Submission
5.2.1. 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. Failure code 554
should be used for this purpose.
5.2.2. 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 the
message and subsequently issue a bounce.
5.2.3. Add or replace a '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. 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 MSA adds or changes the 'Date'
field, it SHOULD add a comment to the field indicating this. This
is because an altered or MSA-created 'Date' field is likely to be
misleading to the recipient.
5.2.5. Add a 'Message-ID' field to the submitted message, if it lacks
it.
5.2.6. Transfer encode the message according to MIME conventions, if
needed and not harmful to the MIME type.
5.2.7. Resolve aliases (CNAME records) for domain names, in the
envelope as well as 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 local parts and/or domains, in the envelope as well as
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 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. Things which MUST Be Done by the MSA if the Message Is a
Submission
Gellens, Alvestrand Expires November 1997 [Page 4]
Internet Draft Message Submission and Relay May 1997
5.3.1. Ensure all domains (in the envelope as well as the text) are
fully-qualified. Single-level domains (for example, 'sales') MAY be
expanded based on local configuration (for example, to
'sales.foo.com'). Multi-level domains which are not fully-qualified
(for example, 'sales.foo') MUST be rejected, not expanded. Response
code 554 should be used to reject a MAIL FROM, RCPT TO, 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 or
recipient address. This applies after any address transformations
have been done. Response code 554 should be used to reject a MAIL
FROM, RCPT TO, or DATA command which contains improper domains. The
MSA MAY instead accept the message and subsequently issue a bounce.
5.3.3. Use the RELAY parameter to the MAIL FROM command when relaying
the message, if the server MTA understands ESMTP and supports the
RELAY extension.
5.4. Things which MUST NOT Be Done by the MSA if the Message Is a
Submission
5.4.1. 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. Things which SHOULD Be Done by the MSA if the Message Is a
Submission
5.5.1. Log message errors, especially apparent misconfigurations of
client software. It can be very helpful to notify the local
postmaster when problems are detected with local mail clients. This
is another advantage of distinguishing submission from relay: local
postmasters are likely to be interested in local configuration
problems, but 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 a result modifies the contents of any structured header
fields or makes other significant changes, it SHOULD document all
such alterations by adding one or more 'Change-History' header
fields.
'Change-History' 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. 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. Names beginning with 'X' or 'x' are
reserved for non-standard parameters. Other names are reserved for
standard parameters.
5.5.3.1. The 'Contact-Domain' parameter
'Contact-Domain' is a required parameter. It specifies a FQDN, the
postmaster of which is the contact point for problems detected by
the recipient of the message.
5.5.3.2. The 'MSA' parameter
While 'MSA' is an optional parameter, either it or
'MSA-Identity-Token' is required. 'MSA' lists the FQDN of the MSA.
5.5.3.3. The 'MSA-Identity-Token' parameter
While 'MSA-Identity-Token' is an optional parameter, either it or
'MSA' is required. 'MSA-Identity-Token' is any string which is
sufficient for the postmaster at the contact domain to identify the
software which modified the message. This 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 or insensitive.
5.5.3.4. The 'Date' parameter
'Date' is required and contains the time and date at which the
change was made, using syntax as in [RFC-822] and [RFC-1123].
5.5.3.5. The 'Element' parameter
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
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
The 'Cause' parameter optionally identifies the justification for
the change: 'Bad-Syntax', 'Incorrect', 'Missing', 'Nickname', or
'Policy'.
5.5.3.8. The 'Original' parameter
'Original' is an optional parameter which contains the value of the
field before any changes were made.
5.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
action ::= "Action" "=" ("Added" / "Changed"
/ "Expanded" / "Quoted" / "Removed"
/ "Unquoted")
contact-domain ::= "Contact-Domain" "=" <FQDN>
cause ::= "Cause" "=" ("Bad-Syntax" / "Incorrect"
/ "Missing" / "Nickname" / "Policy")
date ::= "Date" "=" <quoted-string containing
date-time as specified in RFCs 822 and 1123>
element ::= field / envelope
envelope ::= "Envelope" "=" ("MAIL" / "RCPT")
field ::= "Field" "=" ("body" / <header field as
specified in RFCs 822 or 2076 [HEADERS]>)
msa ::= "MSA" "=" <FQDN>
Gellens, Alvestrand Expires November 1997 [Page 7]
Internet Draft Message Submission and Relay May 1997
msa-identity-token ::= "MSA-Identity-Token" "=" value
original ::= "Original" "=" value
5.5.11. Examples of 'Change-History'
Change-History: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com;
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; Action=Expanded; Cause=Nickname; Original=Foo
Change-History: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=To.1;
Action=Expanded; Cause=Nickname; Original=Foo
Change-History: Date="Fri, 20 March 1997 19:32 +0800";
MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=From;
Action=Changed; Cause=Policy
6. Interaction with Other SMTP Extensions
Extended Status Codes [SMTP-CODES], if supported and used according
to [CODES-EXTENSION], permits the MSA to notify the client of
specific configuration or other problems. In particular, when
result code 554 is used to reject a MAIL FROM, RCPT TO, or DATA
command, or if 504 is used to reject a MAIL FROM command, the codes
defined in [SMTP-CODES] will be helpful.
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. Message Rejection
The MTA 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 to reject all message submissions which do not come
from local users (based on IP address and/or authenticated
identity).
The MSA may be unable to comply with the requirements for relaying a
submitted message. For example, the domain names in the message
Gellens, Alvestrand Expires November 1997 [Page 8]
Internet Draft 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 to produce a valid message, it may either reject the message
immediately, or accept it and issue a bounce. If the MSA is not
able to determine a return path to the submitting user (from a valid
MAIL FROM, or based on authenticated identify), it MUST immediately
reject the message. A message can be immediately rejected by
returning 554 to the MAIL FROM command or after receiving the final
period.
8. Possible Other Cases for Treating Messages as Submissions
For backwards compatibility with older mailers and MTAs, the MTA MAY
consider the message a submission, and treat it as above, under some
combinations of the following circumstances:
8.1. The message lacks any 'Received' fields.
8.2. The message comes from a host known to the MTA as being a "pure
client", such as a PC.
8.3. The message lacks a 'Date' field.
8.4. The MTA knows that all of its messages are submissions. For
example, an MTA and all clients might be configured so that all
submissions go through that MTA, and only submissions go through
that MTA.
9. 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. For example, a site could configure its MSA to
require authentication before accepting a message, and could
configure its MTA to reject all RCPT TOs for non-local users. This
can be an important element in a site's total email security policy.
The 'Change-History' header field allows for problem tracking and
reporting, through use of the 'Contact-Domain' parameter with either
the 'MSA' or the 'MSA-Identity-Token' parameter. Sites wanting to
prevent disclosing details of their local network (such as the
identities of local servers) should use 'MSA-Identity-Token', while
sites without these concerns can use the simpler 'MSA' parameter.
10. 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. References
[ESMTP] Klensin, J., Freed, N., Rose, M., 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,
November 1995, <ftp://ds.internic.net/rfc/rfc1869.txt>
[RFC-822] 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] R. Braden, Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, USC/Information Sciences
Institute, October 1989, <ftp://ds.internic.net/rfc/rfc1123.txt>
[SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10,
Information Sciences Institute, 08/01/1982,
<ftp://ds.internic.net/rfc/rfc821.txt>
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, Innosoft, October 1996,
<ftp://ds.internic.net/rfc/rfc2034.txt>
[SMTP-CODES] 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>
[] Palme, J., "Common Internet Message Headers", RFC 2076,
Stockholm University/KTH, February 1997,
<ftp://ds.internic.net/rfc/rfc2076.txt>
12. Authors' Addresses
Randall Gellens +1.619.651.5115
Qualcomm, Inc. +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
Gellens, Alvestrand 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 [Page 11]