One document matched: draft-gellens-submit-04.txt
Differences from draft-gellens-submit-03.txt
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 revised 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.orgt>.
This document will expire before December 1997. Distribution of
this draft is unlimited.
The file name of this version is draft-gellens-submit-04.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 September 1997 [Page 1]
Internet Draft Message Submission and Relay March 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 when used as a relay protocol.
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 XXXX 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 or Submission
In addition to providing for a submission server separate from SMTP,
this memo proposes an SMTP extension [ESMTP] to assert that a
message is not a submission, or when it is, to provide a means for
MUAs to request non-default handling of their submissions.
The name of this extension is "Mode".
The EHLO keyword is MODE.
Gellens, Alvestrand Expires September 1997 [Page 2]
Internet Draft Message Submission and Relay March 1997
One new optional parameter is defined for the MAIL FROM verb: MODE.
It has a required value, which must be either SUBMIT or RELAY. When
SUBMIT appears, it may be followed by a list of modifiers enclosed
in parentheses.
If MODE=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. (While 504 is not listed in RFC 821 as
a valid failure response to MAIL FROM, it seems to make the most
sense, although cases can be made for 521 and 554).
If MODE was not used, and the message was received on the standard
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.
If MODE=SUBMIT is used on the SMTP port, the MTA may either accept
the MAIL FROM and treat the message as a submission, or reject the
MAIL FROM with response code 504.
No modifiers are defined at this time for the SUBMIT value of the
MODE parameter. However, such modifiers may be defined in the
future. Names beginning with 'x' or 'X' are reserved for
non-standard use. All other names are reserved for standardized
modifiers. IANA will maintain the list of standard names.
4. Actions when MODE=RELAY Is Used
If the MAIL FROM command has the MODE=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.
Gellens, Alvestrand Expires September 1997 [Page 3]
Internet Draft Message Submission and Relay March 1997
5.1.2. It is better to reject than to risk damage. When a problem with
a message is detected, and there is no specificly 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
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 MUST 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.
Gellens, Alvestrand Expires September 1997 [Page 4]
Internet Draft Message Submission and Relay March 1997
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
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 MODE=RELAY parameter to the MAIL FROM command when
relaying the message, if the server MTA understands ESMTP and
supports the MODE 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
Gellens, Alvestrand Expires September 1997 [Page 5]
Internet Draft Message Submission and Relay March 1997
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
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 to site to use values which are either
case sensitive or insensitive.
5.5.3.4. The 'Date' parameter
Gellens, Alvestrand Expires September 1997 [Page 6]
Internet Draft Message Submission and Relay March 1997
'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 'Field' parameter
The 'Field' parameter is required and identifies which header field
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 (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 'To' would be 'To.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 / field / 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
Gellens, Alvestrand Expires September 1997 [Page 7]
Internet Draft Message Submission and Relay March 1997
in RFC 822 and RFC 1123>
field ::= "Field" "=" ("body" / <header fields as specified in RFC
822 or RFC 2076 [HEADERS]>)
msa ::= "MSA" "=" <FQDN>
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; 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
The SMTP [AUTH] extension, if supported and used, may allow the MSA
to determine the identity of the submitting user.
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 commad, the codes
defined in [SMTP-CODES] will be helpful.
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
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
Gellens, Alvestrand Expires September 1997 [Page 8]
Internet Draft Message Submission and Relay March 1997
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' paremeter.
10. Acknowledgements
This updated draft has been revised in part based on comments and
discussions which took place on and off the IETF-Submit mailing
list.
11. References
Gellens, Alvestrand Expires September 1997 [Page 9]
Internet Draft Message Submission and Relay March 1997
[AUTH] J. Myers, "Internet Draft: SMTP Authentication", Carnegie
Mellon, draft-myers-smtp-auth-05.txt, February, 1997, work in
progress,
<ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-05.txt>
[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>
[HEADERS] 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.658.1560 (fax)
6455 Lusk Blvd. Randy@Qualcomm.Com
San Diego, CA 92121
U.S.A.
Harald Tveit Alvestrand +47 73 59 70 94
Gellens, Alvestrand Expires September 1997 [Page 10]
Internet Draft Message Submission and Relay March 1997
UNINETT Harald.T.Alvestrand@uninett.no
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
Gellens, Alvestrand Expires September 1997 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 16:56:34 |