Purported Responsible Address in E-Mail Messages
RFC 4407

 
Document
Type RFC - Experimental (April 2006; Errata)
Was draft-lyon-senderid-pra (individual in app area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 4407 (Experimental)
Telechat date
Responsible AD Ted Hardie
Send notices to (None)

Email authors IPR 1 References Referenced by Nits Search lists

Network Working Group                                            J. Lyon
Request for Comments: 4407                               Microsoft Corp.
Category: Experimental                                        April 2006

            Purported Responsible Address in E-Mail Messages

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

Lyon                          Experimental                      [Page 1]
RFC 4407             Purported Responsible Address            April 2006

   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 document defines an algorithm by which, given an e-mail message,
   one can extract the identity of the party that appears to have most
   proximately caused that message to be delivered.  This identity is
   called the Purported Responsible Address (PRA).

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Determining the Purported Responsible Address ...................3
   3. Security Considerations .........................................5
   4. Acknowledgements ................................................5
   5. References ......................................................5
      5.1. Normative References .......................................5
      5.2. Informative References .....................................5

1.  Introduction

   Most e-mail flows relatively directly from a sender to a recipient,
   with a small number of Mail Transfer Agents (MTAs) in between.  Some
   messages, however, are resent by forwarding agents, mailing list
   servers, and other such software.  These messages effectively result
   in two or more mail transactions: one from the sender to the
   forwarding agent, and another from the agent to the destination.

   In some cases, messages travel through more than one of these agents.
   This can occur, for example, when one mailing list is subscribed to
   another, or when the address subscribed to a mailing list is a
   forwarding service.

   Further complicating the situation, in some cases the party that
   introduces a message is not the author of the message.  For example,
   many news web sites have a "Mail this article" function that the

Lyon                          Experimental                      [Page 2]
Show full document text