RFC 4407

RFC 4407: Purported Responsible Address in E-Mail Messages 💌✨

• RFC: 4407
• Title: Purported Responsible Address in E-Mail Messages
• Author: Jim Lyon, Microsoft Corp. 💅
• Category: Experimental 🧪
• Date: April 2006 🌸
• Obsoletes / Updates: nothing listed in the header 🦋

---

Status of This Memo 📋

Okay so this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind, so don't treat it like one! Discussion and suggestions for improvement are requested 💬. Distribution of this memo is unlimited 🌈.

Copyright Notice ©️

Copyright (C) The Internet Society (2006).

IESG Note 📣

Okay, this part is lowkey important. The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published at the same time as Experimental RFCs, even though there is no general technical consensus and efforts to reconcile the two approaches have failed 💔. So these documents have not gotten full IETF review. They're 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 🙅‍♀️. It also warns the reader that there are serious open issues for each approach, plus 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 were created for the current SPF experiment or for earlier versions in this set of experiments 🧩. Depending on what's in the record, Sender-ID heuristics might get applied incorrectly to a message. And depending on what the recipient does with those heuristics, the message may not be delivered or may get discarded on receipt 💀.

Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. That's the big warning, bestie 🚨.

Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 🎀. They may also 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 😭. This includes automatic forwarders that comply with the standards by not adding Resent-* headers, and systems that 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 watch how the two approaches do during the two years after publication, so a community consensus can be reached in the future 👀✨.

Abstract 📜

This document defines an algorithm that, given an e-mail message, lets you 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 pretty directly from a sender to a recipient, with a small number of Mail Transfer Agents (MTAs) in between 📨. Some messages, though, get resent by forwarding agents, mailing list servers, and other software like that 🔁. These messages basically turn into 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 🛤️. That can happen, for example, when one mailing list is subscribed to another, or when the address subscribed to a mailing list is a forwarding service 🙃.

It gets messier, too. Sometimes the party that introduces a message isn't the author of the message 🫠. For example, lots of news websites have a "Mail this article" function that the public can use to e-mail a copy of an article to a friend 📰. In that case the mail is "from" the person who pressed the button, but it's physically sent by the operator of the website 🤷‍♀️.

This document defines a new identity associated with an e-mail message, called the Purported Responsible Address (PRA) 👑. You figure it out by inspecting the header of the message 🔍. The PRA is designed to be the entity that (according to the header) most recently caused the message to be delivered 🎯.

Heads up: the results of this algorithm are only as truthful as the headers in the message. If a message has fraudulent or incorrect headers, the algorithm will give an incorrect result 🚩. That's why the result is called the "Purported Responsible Address". "Purported" because it tells you what a message claims about where it came from, but not necessarily where it actually came from 🕵️‍♀️.

This document does not prescribe any particular uses for the Purported Responsible Address 🙌. However, [RFC4406] describes a method of determining whether a particular MTA is authorized to send mail on behalf of the domain contained in the PRA 🔐.

1.1. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.

Part 2 (Section 2 onward) is coming next, so stay tuned 👀🫶.

Intellectual Property ✨

okay so the IETF is not picking a side on whether any Intellectual Property Rights (IPR) apply to the tech in this doc, or how much license might exist for it. it also hasn't gone hunting for any of those rights itself 🫠 For how rights work with RFC documents, check out BCP 78 and BCP 79 📚

if you want copies of IPR disclosures sent to the IETF Secretariat, or assurances that licenses will be available, or the results of anyone trying to get a general license or permission to use proprietary rights for this spec (for implementers or users), you can grab all of that from the IETF online IPR repository at http://www.ietf.org/ipr 🗂️

and the IETF really wants to hear from you 🫶 if you know of any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, send it to ietf-ipr@ietf.org 💌

bestie, that last bit is the one to actually remember: the IETF is literally asking the whole world to tell them about any rights that might be in the way of building this 🚨

---

Acknowledgement 🌸

the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💖