Internet Draft H. Alvestrand and R. Gellens, Authors
Expires 22 May 1997 R. Gellens, Editor
22 November, 1996
draft-gellens-submit-02.txt
SMTP Message Submission and 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-submit-02.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 headers.
Alvestrand, Gellens Expires May 1997 [Page 1]
Internet Draft SMTP Submission November 1996
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 messages to be
identified as submissions or relays.
2. SUBMIT Servers
To distinguish relay SMTP from submission, port XXXX is reserved as the
SMTP SUBMIT port. Messages received on this port are assumed to be
submissions, even though the protocol used is otherwise SMTP.
However, in lieu of using this port, it may in certain cases be preferred
to use the standard SMTP port (port 25) on a system dedicated for and
known to be a SUBMIT server. When this is done, the SUBMIT server MUST
NOT be listed as an MX record for any domain. Additionally, the SUBMIT
server SHOULD verify that it is not configured as a normal SMTP server;
when the MTA receives a mail message with a RCPT TO, it SHOULD query
the DNS to verify that its IP address is not listed in any MX record for
the domain specified in the RCPT TO command. If there are no MX records
for that domain, the MTA SHOULD verify that its IP address is not
listed in any A records for that domain. If either verification fails,
the RCPT TO SHOULD be rejected, unless the local-part is "Postmaster"
(case insensitive) and it knows where to forward postmaster mail.
3. SMTP Extension for Message Relay
The name of this extension [ESMTP] is "Relay".
The EHLO keyword is RELAY.
One new optional parameter is defined for the MAIL FROM verb: RELAY.
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
Alvestrand, Gellens Expires May 1997 [Page 2]
Internet Draft SMTP Submission November 1996
submission; the MTA can either treat it as a relay or reject
the MAIL FROM command with 504. (Although 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 RELAY 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.
4. 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.
5. Actions when the Message Is a Submission
The following things MUST be done by the 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 the 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 rights, or is invalid.
Failure code 554 should be used for this purpose.
(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.
(3) Add a 'Sender' field to the submitted message, if the
identity of the sender is known 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.
Alvestrand, Gellens Expires May 1997 [Page 3]
Internet Draft SMTP Submission November 1996
(8) Resolve aliases (CNAME records) for domain names, in the
envelope as well as the text, 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.
(9) Rewrite local parts and/or domains, 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.
If the MTA treats a message as a submission (see also section 8) 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.
6. 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.
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 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 MTA 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 MTA from qualifying them. If the MTA
is able to determine a return path to the submitting user (from a valid
MAIL FROM, or based on authenticated identify), the MTA may either
reject the message immediately, or accept it and issue a bounce. If
the MTA is not able to determine a return path to the submitting
user, it MUST immediately reject messages which it is unable to relay.
A message can be immediately rejected by returning 554 to the MAIL FROM
command or after receiving the final period.
Alvestrand, Gellens Expires May 1997 [Page 4]
Internet Draft SMTP Submission November 1996
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:
(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 that MTA, and only submissions go
through that MTA.
9. Security Considerations
Security issues are not considered in this memo.
10. Acknowledgements
This updated draft has been revised in part based on comments and
discussions which took place on and off the IETF-SMTP mailing list.
11. References
[AUTH]
J. Myers, "Internet Draft: SMTP Authentication", Carnegie
Mellon, draft-myers-smtp-auth-04.txt, November 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
Alvestrand, Gellens Expires May 1997 [Page 5]
Internet Draft SMTP Submission November 1996
Institute, October 1989
[SMTP]
J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10,
Information Sciences Institute, 08/01/1982
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
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 May 1997 [Page 6]