One document matched: draft-gellens-submit-03.txt

Differences from draft-gellens-submit-02.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-03.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.

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.



Alvestrand, Gellens           Expires September 1997           [Page 1]
Internet Draft          Message Submission and Relay          March 1997


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.

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


Alvestrand, Gellens           Expires September 1997           [Page 2]
Internet Draft          Message Submission and Relay          March 1997


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.


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


Alvestrand, Gellens           Expires September 1997           [Page 3]
Internet Draft          Message Submission and Relay          March 1997


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 desirable
and 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


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.


Alvestrand, Gellens           Expires September 1997           [Page 4]
Internet Draft          Message Submission and Relay          March 1997




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


Alvestrand, Gellens           Expires September 1997           [Page 5]
Internet Draft          Message Submission and Relay          March 1997


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' is an optional parameter, either it or 'MSA-Identity-Token' 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

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




Alvestrand, Gellens           Expires September 1997           [Page 6]
Internet Draft          Message Submission and Relay          March 1997


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




Alvestrand, Gellens           Expires September 1997           [Page 7]
Internet Draft          Message Submission and Relay          March 1997


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


Alvestrand, Gellens           Expires September 1997           [Page 8]
Internet Draft          Message Submission and Relay          March 1997


'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

[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

Harald Tveit Alvestrand            +47 73 59 70 94
UNINETT                            Harald.T.Alvestrand@uninett.no
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM


Alvestrand, Gellens           Expires September 1997           [Page 9]
Internet Draft          Message Submission and Relay          March 1997


NORWAY


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.














































Alvestrand, Gellens           Expires September 1997           [Page 10]