Internet Draft H. Alvestrand and R. Gellens, Authors
Expires 28 February 1997 R. Gellens, Editor
28 August, 1996
draft-gellens-smtp-submit-01.txt
SMTP Extension for Message Submission/Relay
Status of this Memo:
This draft document is being circulated for comment.
Please send comments to the IETF SMTP mailing list,
<ietf-smtp@list.cren.net>. To subscribe, send a message containing
SUBSCRIBE IETF-SMTP to <listproc@listproc.net>.
The following text is required by the Internet-draft rules:
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).
The file name of this version is draft-gellens-smtp-submit-01.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
Alvestrand, Gellens Expires February 1997 [Page 1]
Internet Draft Submit SMTP August 1996
to add Received headers.
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 (incomplete) 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 an MTA to be
informed how SMTP is being used (submission or relay mode).
2. SMTP Extension for Message Submission or Relay
The name of this extension [ESMTP] is "Message Mode".
The EHLO keyword is MODE.
One new parameter is defined for the MAIL FROM verb: MODE. It has
a required value, which must be either SUBMIT or RELAY.
If SUBMIT is used with the MAIL FROM command, the message is to be
treated as a submission. If RELAY is used, the message is to be
treated as a relay.
In addition to supporting the MODE extension, an MTA MAY choose to
receive messages on an additional port, port X. If so, all messages
received using port X are to be treated as submissions. This is for
the benefit of clients which do not use EMSTP but which can be
easily configured to use a port other than 25.
If neither SUBMIT nor RELAY is used, and the message was received on
the standard SMTP port (port 25), the MTA may either unconditionally
treat the message as a relay, or use the guidelines in section 6 to
determine if the message is a submission or a relay.
Alvestrand, Gellens Expires February 1997 [Page 2]
Internet Draft Submit SMTP August 1996
3. Actions when RELAY Is Used
If the MAIL FROM line 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.
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 to reject all RCPT TOs
for messages being relayed which do not reference local users.
4. Actions when the Message Is a Submission
The following things MUST be done by an MTA if the message is a
submission:
(1) Ensure all domains (in the envelope as well as the text)
are fully-qualified.
The following things MAY be done by an MTA if the message is a
submission:
(1) Refuse the MAIL FROM command if the address in MAIL FROM is
not believed to have submission right at this MTA, or is
invalid.
(2) Refuse the DATA command if the submitted message is
syntactically invalid, or seems inconsistent with
permissions given to the user (if known).
(3) Add a 'Sender' field to the submitted message, if it knows
the identity of the sender and this is not given in the
'From' field.
(4) Add a 'Date' field to the submitted message, if it lacks it.
(5) Correct the 'Date' field if it does not conform to [RFC-822]
syntax (as modified by [RFC-1123]).
(6) Add a 'Message-ID' field to the submitted message, if it
lacks it.
(7) Transfer encode the message according to MIME conventions,
if desirable and needed
(8) Resolve aliases (CNAME records) for domain names, in the
envelope as well as the text, subject to local policy. For
Alvestrand, Gellens Expires February 1997 [Page 3]
Internet Draft Submit SMTP August 1996
example, if www.ab.com and ftp.ab.com are both aliases for
mail.ab.com, rewriting them could lose useful information.
(9) Rewrite local parts, according to local policy. For example,
a site may prefer to rewrite JRU as J.Random.User in order
to hide logon names.
(10) Add a 'Content-MD5' field to the submitted message, if it
lacks it.
If an MTA treats a message as a submission (see also section 6) and
modifies its text in any way as a result, it SHOULD document all
such alterations by one or more of the following:
(1) Add a comment to each added or altered field, of the form
"(added/corrected by MTA <domainname>)".
(2) Add a 'Comments' field which lists what alterations were
made, the reason why each was done, and the domain name of
the MTA.
5. Interaction with Other SMTP Extensions
The SMTP [AUTH] extension, if supported and used, may allow the MTA
to determine the identity of the submitting user.
6. 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:
(1) The message lacks any 'Received' fields.
(2) The message comes from a host known to the MTA as being a
"pure client", such as a PC.
(3) The message lacks a 'Date' field.
(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 the MTA, and only submissions go
through that MTA.
Alvestrand, Gellens Expires February 1997 [Page 4]
Internet Draft Submit SMTP August 1996
6. Security Considerations
Security issues are not considered in this memo.
7. Acknowledgements
This updated draft has been revised in part based on comments and
discussions which took place on the IETF-SMTP mailing list.
8. References
[AUTH]
J. Myers, "Internet Draft: SMTP Authentication", Carnegie
Mellon, draft-myers-smtp-auth-02.txt, January 1996, work in
progress.
[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
[RFC-822]
D. Crocker, "Standard for the format of ARPA Internet text
messages", RFC 822, STD 11, University of Delaware, 08/13/1982
[RFC-1123]
R. Braden, Editor, "Requirements for Internet Hosts --
Application and Support", RFC 1123, USC/Information Sciences
Institute, October 1989
[SMTP]
J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10,
Information Sciences Institute, 08/01/1982
8. Authors' Addresses
Harald Tveit Alvestrand +47 73 59 70 94
UNINETT Harald.T.Alvestrand@uninett.no
P.O.Box 6883 Elgeseter
N-7002 TRONDHEIM
NORWAY
Randall Gellens +1.714.380.6350
Alvestrand, Gellens Expires February 1997 [Page 5]
Internet Draft Submit SMTP August 1996
Unisys Corporation +1.714.380.5912 (fax)
25725 Jeronimo Road Randy.Gellens@MV.Unisys.Com
Mail Stop 237
Mission Viejo, CA 92651
U.S.A.
Alvestrand, Gellens Expires February 1997 [Page 6]