RFC 4406

Sender ID: Authenticating E-Mail

📅 published April 2006, from ietf

Sender ID: Authenticating E-Mail 💌

Network Working Group Request for Comments: 4406 🎀 Authors: J. Lyon (Microsoft Corp.) and M. Wong (pobox.com) 💖 Category: Experimental 🧪 Date: April 2006 📅 Obsoletes and Updates: this header doesn't list any ✨

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, just an experiment! The authors are asking everyone to share discussion and suggestions for improvement 💬, and distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006). ✨

IESG Note 🧾

so the IESG (the group that okays Internet standards) is explaining that RFC 4405, RFC 4406, RFC 4407, and RFC 4408 all got published at the same time as Experimental RFCs 🎀. There's no general technical consensus on them, and attempts to reconcile the two approaches have failed 😭. These documents did not get full IETF review and were published "AS-IS" 🫶, just to document the different approaches as they were considered in the MARID working group 💅.

The IESG takes no position on which approach is better 🤷‍♀️. It warns readers that each approach has serious open issues, and that using them together is a concern too ⚠️. The IESG believes that documenting the different approaches does less harm than not documenting them 🌸.

Now, 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 the record says, Sender-ID heuristics might get applied incorrectly to a message 💀. And depending on what the recipient does with those heuristics, the message might not be delivered, or it might be discarded on receipt 😱.

So, participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this situation 🙈. Participants publishing SPF experiment DNS records should think about the advice given in section 3.4 of RFC 4406, and they may want to publish both v=spf1 and spf2.0 records to avoid the conflict 🧚.

Also, participants in the Sender-ID experiment need to know that the way Resent-* header fields are used will cause failure to receive legitimate email when interacting with standards-compliant systems 😭. Specifically, that covers automatic forwarders that follow the standards by not adding Resent-* headers, and systems that comply with RFC 822 but haven't implemented RFC 2822 Resent-* semantics yet 🫠. It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem 🚫.

Finally, the community is invited to watch how the two approaches do during the two years after publication 👀✨. The goal is for a community consensus to be reached in the future 🤝.

Abstract 🫧

Internet mail has a big problem: lots of unwanted mail gets sent using spoofed addresses 😤. In this case, "spoofed" means the address is used without the permission of the domain owner 🙅‍♀️. This document describes a family of tests that let SMTP servers figure out whether an e-mail address in a received message was used with the permission of the owner of the domain in that address 🔍✨.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
   2. Problem Statement ...............................................4
   3. SPF 2.0 Records .................................................5
      3.1. Version and Scope ..........................................5
           3.1.1. Minor Version .......................................6
      3.2. Multiple Records ...........................................6
      3.3. Positional Modifiers .......................................7
      3.4. Compatibility ..............................................8
   4. Decision Model ..................................................8
      4.1. Arguments ..................................................9
      4.2. Results ....................................................9
      4.3. Record Lookup ..............................................9
      4.4. Record Selection ...........................................9
   5. Actions Based on the Decision ..................................10
      5.1. Neutral, None, SoftFail, or PermError .....................11
      5.2. Pass ......................................................11
      5.3. Fail ......................................................11
      5.4. TempError .................................................11
   6. Security Considerations ........................................11
      6.1. DNS Attacks ...............................................12
      6.2. TCP Attacks ...............................................12
      6.3. Forged Sender Attacks .....................................12
      6.4. Address Space Hijacking ...................................12
      6.5. Malicious DNS Attacks on Third Parties ....................13
   7. Implementation Guidance ........................................13
      7.1. Simple E-Mailers ..........................................14
      7.2. E-Mail Forwarders .........................................14
      7.3. Mailing List Servers ......................................15
      7.4. Third-Party Mailers .......................................15
      7.5. MUA Implementers ..........................................15
   8. Acknowledgements ...............................................16
   9. References .....................................................17
      9.1. Normative References ......................................17
      9.2. Informative References ....................................17

1. Introduction ✨

okay so a huge majority of unwanted e-mail has headers that lie about where the mail came from 🤥. This is true of most spam, and basically all of the virus e-mail that gets sent 🦠.

This document describes a mechanism that lets receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) recognize mail in that category and take appropriate action 🫶. For example, an MTA might refuse to accept a message, an MDA might discard a message instead of putting it into a mailbox, and an MUA might render that message in some distinctive fashion 🎨.

To avoid further fragmenting the Internet e-mail system, it's desirable that the Internet community as a whole reaches a consensus on what mail senders should do to make their mail appear non-spoofed 🧩, and how mail receivers should determine whether mail is spoofed 🔎. On the other hand, it's not necessary to agree on what different parties do once a message has been determined to be spoofed 🙌. That can be done unilaterally, so one agent might discard a spoofed message while another decides to add a disclaimer 💅.

This document defines a pair of closely related tests 👯‍♀️. One validates a message's Purported Responsible Address (PRA), as defined in [RFC4407] 💌. The other validates a message's Reverse-Path (also known as the MAIL-FROM address), as defined in [RFC4408] 📬.

An e-mail sender complying with this specification SHOULD publish information for both tests, and SHOULD arrange that any mail that is sent will pass both tests 🎀. An e-mail receiver complying with this specification SHOULD perform at least one of these tests 💖.

1.1. Conventions Used in This Document 📝

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

2. Problem Statement 🔍

Briefly stated, the mechanisms in this document let you answer this question 💭:

When a message is transferred via SMTP between two unrelated parties, does the SMTP client host have permission to send mail on behalf of a mailbox referenced by the message?

As you can see from the question, this mechanism is for unrelated parties 🤝. It's useful at the point where a message crosses the Internet from one organization to another 🌍. Describing authentication mechanisms that can be deployed within an organization is beyond the scope of this document 🏢.

The PRA version of the test tries to authenticate the mailbox associated with the most recent introduction of a message into the mail delivery system 📮. In simple cases, that's who the mail is from 💫. But for a third-party mailer, a forwarder, or a mailing list server, the address being authenticated is the one belonging to that third party, forwarder, or mailing list 🧚.

The MAIL-FROM version of the test, on the other hand, tries to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message 📨. In simple cases, this is also who the mail is from 💌. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange for DSNs received at that address to be forwarded to the original bounce address 🔁.

In both cases, what gets authenticated is the domain associated with an e-mail address. No attempt is made to authenticate the local-part 🙈. A domain owner gets to decide which SMTP clients speak on behalf of addresses within the domain 👑, and a responsible domain owner should not authorize SMTP clients that will lie about local parts 🚫.

In the long run, once the sender's domain is authenticated, it will be possible to use that domain as part of a mechanism for judging how likely a given message is to be spam 🕵️‍♀️. That could use reputation and accreditation services, for example 🌟. These services aren't the subject of the present mechanism, but it should enable them 🫶.

3. SPF 2.0 Records 📡

Domains declare which hosts are and are not authorized to transmit e-mail messages on their behalf by publishing Sender Policy Framework (SPF) records in the Domain Name System 🌐. [RFC4408] defines a format for these records, identified by the version prefix v=spf1 📋. This section defines an amended format, identified by the version prefix spf2.0 ✨. It lets sending domains explicitly specify how their records should be interpreted, and it provides for additional extensibility 🧩. Sending domains MAY publish either or both formats 🎀.

Since the two formats are identical in most respects, the following subsections define the spf2.0 format relative to [RFC4408] 💅.

3.1. Version and Scope ✨

okay so under Sender ID, receiving domains can run a check on either the PRA identity or the MAIL-FROM identity 👀 which means sending domains need a way to say whether their published list of authorized outbound e-mail servers works for the PRA check, the MAIL-FROM check, or both 💅

this section replaces the version identifier definition in Section 4.5 of [RFC4408] and adds the concept of SPF record scopes 🎀

SPF records start with a version identifier and can also include a scope 🌸

record      = version terms *SP
version     = "v=spf1" | ( "spf2." ver-minor scope)
ver-minor   = 1*DIGIT
scope       = "/" scope-id *( "," scope-id )
scope-id    = "mfrom" / "pra" / name

for example, this record

spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all

is an SPF record that can be used for either MAIL FROM or PRA checks 🦋

this document only defines that the two scopes "mfrom" and "pra" exist ✨ the details of those two scopes live in other documents: "mfrom" is defined in [RFC4408] and "pra" is defined in [RFC4407] 🫶

other scopes can only be defined by future documents 🔮 there's no registry for scopes. a scope definition has to say what it identifies as the sending mailbox for a message, how to pull that info out of a message, how to figure out the initial arguments for the check_host() function, and what the compliant responses to the result are. this makes sure domains with published records and mail receivers agree on what the scope means 🤝

a compliant domain SHOULD publish authorizations for every defined scope 💜

3.1.1. Minor Version

all published records that use the "spf2" version identifier MUST start with "spf2.0" 📌 this document only specifies records with a minor version of "0" 🍓

future versions of this document may define other minor versions to be used 🧚

3.2. Multiple Records

a domain MAY publish multiple SPF 2.0 records, as long as each scope shows up in at most one SPF 2.0 record 🌈 a domain MAY also publish an SPF record that uses the "v=spf1" version identifier defined in [RFC4408] 💖 the selection rules in Section 4.4 decide which of these records takes priority 👑

3.3. Positional Modifiers

this section replaces Section 4.6.3 of [RFC4408] and adds the concept of positional modifiers 🎀

modifiers are key/value pairs that change how the check_host() function gets evaluated 🔥

modifiers are either global or positional, and it's giving very clear sorting 💅

Global modifiers MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms and positional modifiers.
Positional modifiers apply only to the mechanism they follow. It is a syntax error for a positional modifier to appear before the first mechanism.

modifiers of either type are also either singular or multiple 🦋

Singular modifiers may appear only once in the record if they are global, or once after each mechanism if they are positional.
Multiple modifiers may appear multiple times in the record if they are global, or multiple times after each mechanism if they are positional.

a modifier is not allowed to be defined as both global and positional 🙅‍♀️

the modifiers "redirect" and "exp" described in Section 6 of [RFC4408] are global and singular 🌸

ordering of modifiers doesn't matter, except for these two things:

  1. positional modifiers must appear after the mechanism they affect and before any later mechanisms; and
  2. when a multiple modifier appears more than one time, the order of those appearances may matter to the modifier.

other than those constraints, implementations MUST treat different orders of modifiers the same 🫶 an intended side effect of these rules is that modifiers can't be defined to modify other modifiers 🙈

these rules let an implementation pre-parse a record correctly 🧠 and they're built so the parsing algorithm stays stable even when new modifiers get introduced ✨

modifiers that are unrecognized MUST be ignored 🌷 this lets older implementations handle records with modifiers that were defined after they were written 🥹

3.4. Compatibility

domain administrators who follow this specification are required to publish info in DNS about their authorized outbound e-mail servers 📮 [RFC4408] describes a format for this info, identified by the version prefix "v=spf1", and tons of domains already publish in that format 😭 so to keep those domains working, Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra", as long as no record starting with "spf2.0" exists 🫶

administrators who've already published "v=spf1" records SHOULD review them to see whether they're also valid for PRA checks 🔍 if the info in a "v=spf1" record isn't correct for a PRA check, administrators SHOULD publish either an "spf2.0/pra" record with correct info, or an "spf2.0/pra ?all" record that says the result of a PRA check is explicitly inconclusive 💀

4. Decision Model

Sender ID lets receiving e-mail systems answer this question 👀

Given an e-mail message, and given an IP address from which it has been (or will be) received, is the SMTP client at that IP address authorized to send that e-mail message?

this question will usually get asked by an SMTP server while it decides whether to accept an incoming message 📥 but a different party could also ask it later on. an MUA, for example, could use the answer to decide how to file or present a message 📂

there are three steps to answering the question 💅

  1. from an e-mail message, extract the address to verify. the PRA variant of this test does that as specified in [RFC4407], or alternatively, using the submitter address as specified in [RFC4405]. the MAIL FROM variant of this test does it as specified in [RFC4408].
  2. extract the domain part of the address found in step 1.
  3. call the check_host() function defined in [RFC4408], as modified by the following subsections.

if the Sender ID check is being done by an MTA as part of receiving an e-mail message, and it can't determine an address in step 1 above (because the message or address is malformed), then the message SHOULD be rejected with the error "550 5.7.1 Missing Purported Responsible Address" or the error "550 5.7.1 Missing Reverse-Path address" 🙅‍♀️

4.1. Arguments

Sender ID changes the check_host() function by adding a scope parameter ✨ so for Sender ID, the check_host() function gets called with these parameters:

  • a. a scope of "pra" (for the PRA variant of the test), or "mfrom" (for the MAIL FROM variant of the test).
  • b. the IP address (either IPv4 or IPv6) that the message is being or has been received from.
  • c. the domain from step 2 above.
  • d. the address from step 1 above.

4.2. Results

the result of the check_host() function is one of these values: "Neutral", "Pass", "Fail", "SoftFail", "None", "TempError", or "PermError" 🎀 Section 5 explains how MTAs receiving messages use these results. this specification puts no requirements on parties doing this test in other environments 🫶

4.3. Record Lookup

SPF records get looked up in DNS according to Section 4.4 of [RFC4408] 🔎

when doing the PRA version of the test, if the DNS query returns "non-existent domain" (RCODE 3), then check_host() exits immediately with the result "Fail" 💀

4.4. Record Selection

this section replaces the record selection steps described in Section 4.5 of [RFC4408] 🦋

starting with the set of records the lookup returned, record selection goes through these steps:

  1. if any records of type SPF are in the set, then all records of type TXT get discarded 🗑️
  2. records that don't begin with proper version and scope sections get discarded. the version section for "spf2" records has a ver-minor field that's there for backward-compatible future extensions. this field must be well formed for a record to be kept, but otherwise it's ignored 🌸
  3. records that use the "spf2" version identifier and don't have a scope-id that matches <scope> get discarded. this is a complete string match on the scope-id tokens, so it's very strict bestie 😤 if <scope> is "pra", then a record starting spf2.0/mfrom,prattle,fubar would be discarded, but a record starting spf2.0/mfrom,pra,fubar would be kept 💅
  4. if the lookup returned two records, one with the "v=spf1" version identifier and the other with the "spf2" version identifier, the "spf2" version takes precedence for the desired scope-id. if the "spf2" record doesn't contain the desired scope-id, then the "v=spf1" record gets selected 👑
  5. if an "spf2" record doesn't contain the desired scope-id and there's no "v=spf1" record for the domain, then no record gets selected 🥀

after the steps above, there should be one record left and evaluation can move forward ✨ if there are two or more records left, then check_host() exits immediately with the error "PermError" 💀

if there are no matching records left after the initial DNS query or any later optional DNS queries, then check_host() exits immediately with the result "None" 🙃

5. Actions Based on the Decision

when the Sender ID test gets used by an SMTP server as part of receiving a message, the server should take the actions described in this section 📬

the check_host() function returns one of the following results. see [RFC4408] for what these results mean 📖

5.1. Neutral, None, SoftFail, or PermError

an SMTP server that gets one of these results SHOULD NOT reject the message for that reason alone 🙅‍♀️ but it MAY give the message heightened scrutiny through other measures, and it MAY reject the message as a result of that extra scrutiny 🔍

those additional security measures MAY take into account that a message with a result of "SoftFail" is less likely to be authentic than a message with a result of "Neutral" 🧐

5.2. Pass

an SMTP server that gets this result SHOULD treat the message as authentic ✅ it may accept or reject the message depending on other policies 🫶

5.3. Fail

when doing the Sender ID test during an SMTP transaction, an MTA that chooses to reject a message with this result SHOULD reject the message with a 550 5.7.1 Sender ID (xxx) yyy - zzz SMTP error 💥 here, "xxx" gets replaced with "PRA" or "MAIL FROM", "yyy" gets replaced with the additional reason returned by the check_host() function, and "zzz" gets replaced with the explanation string returned by the check_host() function 📝

when doing the Sender ID test after accepting an e-mail message for delivery, an MTA that chooses to reject a message with this result SHOULD NOT deliver the message 🚫 instead, it should create a DSN message, following the usual rules for DSN messages 📨

5.4. TempError

an SMTP server that gets this result MAY reject the message with a 450 4.4.3 Sender ID check is temporarily unavailable error code 🕰️ or, alternatively, it MAY accept the message and optionally give it heightened scrutiny through other anti-spam measures 🛡️

6. Security Considerations 🔒✨

Okay bestie, this whole document is a new way to stop spoofed email, which is honestly still such a pervasive mess on the Internet 😭. So let's talk about the counter attacks that could still slip past this mechanism, assuming it gets widely deployed 💅.

6.1. DNS Attacks 🌐

The new mechanism is entirely dependent on DNS lookups, so it's only as secure as DNS itself 🫠. An attacker who wants to spoof messages could try to get their messages accepted by sending forged answers to DNS queries.

An MTA can mostly shut that down by using a properly paranoid DNS resolver 🛡️. DNS Security (DNSSEC) may eventually give us a way to completely neutralize this whole class of attacks 🎀.

6.2. TCP Attacks 🧦

This mechanism is designed to be used alongside SMTP over TCP. A sufficiently resourceful attacker might be able to send TCP packets with forged from-addresses, and then run an entire SMTP session that looks like it's coming from somewhere other than its real origin 👀.

This kind of attack requires guessing what TCP sequence numbers an SMTP server will use. It also means transmitting completely in the blind, since the attacker can't hear any of the server's side of the conversation 🙈.

Attacks like this can be eased off if IP gateways refuse to forward packets when the source address is clearly bogus 🚫.

6.3. Forged Sender Attacks 🎭

This mechanism picks an address to validate, either from one of several message headers or from the RFC 2821 MAIL command, and then uses that address for the check. A message with a true Resent-From header or Return-Path, but a forged From header, will be accepted 😬. Since lots of MUAs don't display every header of received messages, the message will look forged when it's displayed 💀.

To neutralize this attack, MUAs will need to start displaying at least the address that was verified 👑. On top of that, MTAs could give messages extra scrutiny when the validated address differs from the From header 🔍.

6.4. Address Space Hijacking 🏴‍☠️

This mechanism assumes the integrity of IP address space when deciding whether a given client is authorized to send messages from a given PRA. On top of the TCP attack from Section 6.2, a sufficiently resourceful attacker might be able to alter the IP routing structure so two-way communication works using a specified IP address. Then they could run an SMTP session that looks like it's coming from an authorized address, without needing to guess TCP sequence numbers or transmit in the blind 😱.

This could happen if the attacker got access to a router that takes part in external BGP routing. That router could advertise a more specific route to a rogue SMTP client, temporarily overriding the legitimate owner of the address 🚨.

6.5. Malicious DNS Attacks on Third Parties 😈

There is a class of attacks where an attacker A can entice a participant P into sending a malicious message to a victim V 🫣.

These attacks work like this: A cites the address of V in the SMTP MAIL FROM request, and then causes P to generate (or invoke the generation of) a Delivery Status Notification 'bounce' message (RFC3464), which gets sent to the victim V 📨.

The attacker is counting on it being common practice to copy the original message into the 'bounce' report, which means the malice gets sent onward to V 💔.

This style of attack is extra sneaky for the attacker 🥷. It hides where the attack was actually launched from, and it can damage P's reputation by making it look like P originated the malicious message or was actively part of sending it 😭.

In current practice, A makes P produce the 'bounce' by addressing the original message to a nonexistent recipient 📭.

Sender ID enables a new variant of this attack 🆕.

In this variant, the attacker A sends a message whose PRA (Section 4) is chosen so that, when P runs the Sender ID test, the result is a Fail (Section 5.3) ❌.

The message gets rejected, which is exactly what the attacker wanted, and a malicious 'bounce' message may then be generated and sent to the victim V 😤.

7. Implementation Guidance 🛠️

This section lays out the actions that certain members of the Internet e-mail ecosystem must take to be compliant with this specification 📋.

7.1. Simple E-Mailers 📬

A domain that injects original e-mail into the Internet, using its own name in From headers, needs to do nothing to be compliant 🥳. However, these domains SHOULD publish records in DNS as defined by [RFC4408] and this specification 💅.

In the majority of cases, the domain's published information will be the same for both the PRA and MAIL FROM variants of this test. In that case, domains SHOULD publish their information using an SPF record with the prefix "v=spf1". Doing this makes their published information usable by the older SPF protocol too 🧚. (See [RFC4408] for information on the SPF protocol.)

7.2. E-Mail Forwarders 🔁

To pass the PRA variant of the test, a program that forwards received mail to other addresses MUST add an appropriate header containing an e-mail address that it is authorized to use 🎀. Programs like this SHOULD use the Resent-From header for that job.

To pass the MAIL FROM variant of the test, a program that forwards received mail to other addresses MUST alter the MAIL FROM address to an address under its control 🔄. If that address eventually receives a DSN related to the original message, that DSN SHOULD be forwarded to the original MAIL FROM address. However, if this altered address receives any messages other than DSNs related to the original message, those messages MUST NOT be forwarded to the original MAIL FROM address. They SHOULD be refused during an SMTP transaction 🙅‍♀️.

On top of that, e-mail forwarders SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result 🫶.

Some of today's forwarders already add an appropriate header (although lots of them use Sender rather than Resent-From). Most of them don't do the address-rewriting described above 🙃.

Also, an e-mail forwarder might receive a single message for two or more recipients, each of whom asks for forwarding to a new address. In that case, the forwarder's MTA SHOULD transmit the message to each new recipient individually, with each copy containing a different newly inserted Resent-From header field 🦋.

7.3. Mailing List Servers 📣

To pass the PRA variant of the test, a mailing list server MUST add an appropriate header containing an e-mail address that it is authorized to use 💌. Programs like this SHOULD use the Resent-From header for that.

To pass the MAIL FROM variant of the test, a mailing list server MUST alter the MAIL FROM address to an address under its control 🔁.

On top of that, mailing list servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result ✨.

Most of today's mailing list software already adds an appropriate header (although most of them use Sender rather than Resent-From), and most of them already alter the MAIL FROM address 🥰.

7.4. Third-Party Mailers 🧑‍🤝‍🧑

To pass the PRA variant of this test, a program that sends mail on behalf of another user MUST add an appropriate header containing an e-mail address that it is authorized to use 🪄. Programs like this SHOULD use the Sender header for that.

To pass the MAIL FROM variant of this test, a program that sends mail on behalf of another user MUST use a MAIL FROM address that is under its control 🗝️. What the program does with any mail received at that address is beyond the scope of this document 🤷‍♀️.

On top of that, third-party mailers, servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result 💜.

Many, but not all, of today's third-party mailers already comply with the PRA variant of the test. How compliant mailers are with the MAIL FROM variant of this test is unknown 🌫️.

7.5. MUA Implementers 📱

When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address 👀.

When a received message contains multiple headers that might be used to determine the purported responsible address, an MUA should consider displaying all of them. So if a message has several Resent-Froms, a Sender, and a From, an MUA should consider displaying all of them 🧐.

Sender ID also doesn't validate the display name that may come along with an e-mail address. The display name is vulnerable to spoofing and other kinds of attacks too 😩. To reduce how often these attacks happen and how well they work, MUA implementers should consider ways to safeguard the display name. That could include:

  • Not presenting the display name to the user at all, or not presenting it unless the corresponding e-mail address is listed in the user's address book 📒.
  • Treating as suspicious any e-mail where the display name is itself in the form of an e-mail address, especially when it differs from the actual e-mail address in the header 🚩.
  • Making it clear to users that the e-mail address has been checked, rather than the display name 🔎.

8. Acknowledgements 🫂

This design is based on earlier work published in 2003 in the [RMX] and [DMP] drafts (by Hadmut Danisch and Gordon Fecyk, respectively). The idea of using a DNS record to check the legitimacy of an e-mail address traces its roots to the "Repudiating Mail From" draft by Paul Vixie [Vixie] (based on a suggestion by Jim Miller), and to the "Domain-Authorized SMTP Mail" draft by David Green [Green], who first introduced this idea on the namedroppers mailing list in 2002 🌸.

The current document borrows heavily from each of the above, as well as earlier versions of [RFC4408] and [CallerID], and it incorporates ideas proposed by many members of the MARID working group 💖. The contributions of each of these are gratefully acknowledged 🙌.

9. References 📚

9.1. Normative References 📖

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4405]   Allman E. and H. Katz, "SMTP Service Extension for
            Indicating the Responsible Submitter of an E-Mail
            Message", RFC 4405, April 2006.

[RFC4407]   Lyon, J., "Purported Responsible Address in E-Mail
            Messages", RFC 4407, April 2006.

[RFC4408]   Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
            for Authorizing Use of Domains in E-Mail", RFC 4408,
            April 2006.

9.2. Informative References ✨

okay so these are the "go read this if you're curious" sources 📚🫶 nothing here is required to implement the thing, but they're the receipts for the ideas floating around the whole doc:

Authors' Addresses 💌

Jim Lyon 💅 Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA

EMail: jimlyon@microsoft.com

Meng Weng Wong 🎀 Singapore

EMail: mengwong@dumbo.pobox.com

Okay, legal bit, but make it cute: Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🔒

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to find any such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79. 📖

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🗂️

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📬

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌈

📦 where this page comes from