datatracker.ietf.org
Sign in
Version 5.6.2.p6, 2014-09-03
Report a bug

SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
RFC 4405

Document type: RFC - Experimental (April 2006; No errata)
Was draft-katz-submitter (individual in app area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4405 (Experimental)
Responsible AD: Ted Hardie
Send notices to: No addresses provided

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

[include full document text]