Network Working Group E. Allman
Request for Comments: 4405 Sendmail, Inc.
Category: Experimental H. Katz
Microsoft Corp.
April 2006
SMTP Service Extension for
Indicating the Responsible Submitter of an E-Mail Message
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
are published simultaneously as Experimental RFCs, although there is
no general technical consensus and efforts to reconcile the two
approaches have failed. As such, these documents have not received
full IETF review and are published "AS-IS" to document the different
approaches as they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred
and cautions the reader that there are serious open issues for each
approach and concerns about using them in tandem. The IESG believes
that documenting the different approaches does less harm than not
documenting them.
Note that the Sender ID experiment may use DNS records that may have
been created for the current SPF experiment or earlier versions in
this set of experiments. Depending on the content of the record,
this may mean that Sender-ID heuristics would be applied incorrectly
to a message. Depending on the actions associated by the recipient
with those heuristics, the message may not be delivered or may be
discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned
that they may lose valid messages in this set of circumstances.
Participants publishing SPF experiment DNS records should consider
Allman & Katz Experimental [Page 1]
RFC 4405 SMTP Responsible Submitter Extension April 2006
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Participants in the Sender-ID experiment need to be aware that the
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics). It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.
The community is invited to observe the success or failure of the two
approaches during the two years following publication, in order that
a community consensus can be reached in the future.
Abstract
This memo defines an extension to the Simple Mail Transfer Protocol
(SMTP) service that allows an SMTP client to specify the responsible
submitter of an e-mail message. The responsible submitter is the
e-mail address of the entity most recently responsible for
introducing a message into the transport stream. This extension
helps receiving e-mail servers efficiently determine whether the SMTP
client is authorized to transmit mail on behalf of the responsible
submitter's domain.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. The SUBMITTER Service Extension .................................4
3. The SUBMITTER Keyword of the EHLO Command .......................5
4. The SUBMITTER Parameter of the MAIL Command .....................5
4.1. Setting the SUBMITTER Parameter Value ......................5
4.2. Processing the SUBMITTER Parameter .........................5
4.3. Transmitting to a Non-SUBMITTER-Aware SMTP Server ..........6
5. Examples ........................................................6
5.1. Mail Submission ............................................7
5.2. Mail Forwarding ............................................7
5.3. Mobile User ................................................8
5.4. Guest E-Mail Service .......................................9
5.5. SUBMITTER Used on a Non-Delivery Report ...................11
6. Security Considerations ........................................11
datatracker.ietf.org