From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4406.txt | 1067 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc4406.txt (limited to 'doc/rfc/rfc4406.txt') diff --git a/doc/rfc/rfc4406.txt b/doc/rfc/rfc4406.txt new file mode 100644 index 0000000..41dbdff --- /dev/null +++ b/doc/rfc/rfc4406.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group J. Lyon +Request for Comments: 4406 Microsoft Corp. +Category: Experimental M. Wong + pobox.com + April 2006 + + + Sender ID: Authenticating E-Mail + +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 + + + + + +Lyon & Wong Experimental [Page 1] + +RFC 4406 Sender ID: Authenticating E-Mail 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 + + Internet mail suffers from the fact that much unwanted mail is sent + using spoofed addresses -- "spoofed" in this case means that the + address is used without the permission of the domain owner. This + document describes a family of tests by which SMTP servers can + determine whether an e-mail address in a received message was used + with the permission of the owner of the domain contained in that + e-mail address. + + + + + + + + + + + + + + + + + + + + + + + + + + +Lyon & Wong Experimental [Page 2] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +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 + + Today, a huge majority of unwanted e-mail contains headers that lie + about the origin of the mail. This is true of most spam and + substantially all of the virus e-mail that is sent. + + This document describes a mechanism such that receiving Mail Transfer + Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents + (MUAs) can recognize mail in the above category and take appropriate + action. For example, an MTA might refuse to accept a message, an MDA + + + +Lyon & Wong Experimental [Page 3] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + might discard a message rather than placing it into a mailbox, and an + MUA might render that message in some distinctive fashion. + + In order to avoid further fragmentation of the Internet e-mail + system, it is desirable that the Internet community as a whole come + to a consensus as to 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 is not necessary to reach a + consensus regarding the actions that various parties take once a + message has been determined to be spoofed. This can be done + unilaterally -- one agent might decide to discard a spoofed message + whereas 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 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 of this document allow one to answer + the following 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 seen from the question, this mechanism applies to unrelated + parties: It is useful at the point where a message passes across the + Internet from one organization to another. It is beyond the scope of + this document to describe authentication mechanisms that can be + deployed within an organization. + + The PRA version of the test seeks to authenticate the mailbox + associated with the most recent introduction of a message into the + mail delivery system. In simple cases, this is who the mail is from. + However, in the case of a third-party mailer, a forwarder, or a + + + +Lyon & Wong Experimental [Page 4] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + mailing list server, the address being authenticated is that of the + third party, the forwarder, or the mailing list. + + On the other hand, the MAIL-FROM version of the test seeks to + authenticate the mailbox that would receive Delivery Status + Notifications (DSNs, or bounces) for the message. In simple cases, + this too is who the mail is from. However, third-party mailers, + forwarders, and mailing list servers MUST specify an address under + their control, and SHOULD arrange that DSNs received at this address + are forwarded to the original bounce address. + + In both cases, the domain associated with an e-mail address is what + is authenticated; no attempt is made to authenticate the local-part. + A domain owner gets to determine which SMTP clients speak on behalf + of addresses within the domain; a responsible domain owner should not + authorize SMTP clients that will lie about local parts. + + In the long run, once the domain of the sender is authenticated, it + will be possible to use that domain as part of a mechanism to + determine the likelihood that a given message is spam, using, for + example, reputation and accreditation services. (These services are + not 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", that allows sending domains to explicitly specify how their + records should be interpreted, and 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 + + Under Sender ID, receiving domains may perform a check of either the + PRA identity or the MAIL-FROM identity. Sending domains therefore + require a method for declaring whether their published list of + authorized outbound e-mail servers can be used for the PRA check, the + MAIL-FROM check, or both. + + This section replaces the definition of the version identifier in + Section 4.5 of [RFC4408] and adds the concept of SPF record scopes. + + + + +Lyon & Wong Experimental [Page 5] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + SPF records begin with a version identifier and may 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, the SPF record + + spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all + + defines an SPF record that can be used for either MAIL FROM or PRA + checks. + + This document only defines the existence of two scopes: "mfrom" and + "pra". The details of these two scopes are defined in other + documents: "mfrom" is defined in [RFC4408]; "pra" is defined in + [RFC4407]. + + Other scopes may be defined by future documents only. There is no + registry for scopes. A scope definition must define what it + identifies as the sending mailbox for a message, how to extract that + information from a message, how to determine the initial arguments + for the check_host() function, and what the compliant responses to + the result are. This ensures that domains with published records and + mail receiver agree on the semantics of the scope. + + 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, provided that each + scope appears in at most one SPF 2.0 record. In addition, 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 + define the precedence of these records. + + + +Lyon & Wong Experimental [Page 6] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +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 affect the evaluation of the + check_host() function. + + Modifiers are either global or positional: + + 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 does not matter, except that: + + 1. positional modifiers must appear after the mechanism they affect + and before any subsequent mechanisms; and + + 2. when a multiple modifier appears more than one time, the ordering + of the appearances may be significant to the modifier. + + Other than these constraints, implementations MUST treat different + orders of modifiers the same. An intended side effect of these rules + is that modifiers cannot be defined that modify other modifiers. + + These rules allow an implementation to correctly pre-parse a record. + Furthermore, they are crafted to allow the parsing algorithm to be + stable, even when new modifiers are introduced. + + + + +Lyon & Wong Experimental [Page 7] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + Modifiers that are unrecognized MUST be ignored. This allows older + implementations to handle records with modifiers that were defined + after they were written. + +3.4. Compatibility + + Domain administrators complying with this specification are required + to publish information in DNS regarding their authorized outbound + e-mail servers. [RFC4408] describes a format for this information + identified by the version prefix "v=spf1". Many domains have + published information in DNS using this format. In order to provide + compatibility for these domains, Sender ID implementations SHOULD + interpret the version prefix "v=spf1" as equivalent to + "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists. + + Administrators who have already published "v=spf1" records SHOULD + review these records to determine whether they are also valid for use + with PRA checks. If the information in a "v=spf1" record is not + correct for a PRA check, administrators SHOULD publish either an + "spf2.0/pra" record with correct information or an "spf2.0/pra ?all" + record indicating that the result of a PRA check is explicitly + inconclusive. + +4. Decision Model + + Sender ID enables receiving e-mail systems to answer the following + 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 be asked by an SMTP server as part of + deciding whether to accept an incoming mail message. However, this + question could also be asked later by a different party. An MUA, for + example, could use the result of this question to determine how to + file or present a message. + + There are three steps to answering this question: + + 1. From an e-mail message, extract the address to verify. The PRA + variant of this test does so as specified in [RFC4407], or + alternatively, using the submitter address as specified in + [RFC4405]. The MAIL FROM variant of this test does so as + specified in [RFC4408]. + + 2. Extract the domain part of the address determined in step 1. + + + + +Lyon & Wong Experimental [Page 8] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + 3. Call the check_host() function defined in [RFC4408] and modified + by the following subsections. + + If the Sender ID check is being performed by an MTA as part of + receiving an e-mail message, and it cannot determine an address in + step 1 above (because the message or address is malformed), then the + message SHOULD be rejected with error "550 5.7.1 Missing Purported + Responsible Address" or error "550 5.7.1 Missing Reverse-Path + address". + +4.1. Arguments + + Sender ID modifies the check_host() function by the addition of a + scope parameter. Thus, for Sender ID the check_host() function is + called passing the following 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) from which the message is + being or has been received. + 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 the values + "Neutral", "Pass", "Fail", "SoftFail", "None", "TempError", or + "PermError". Section 5 describes how these results are used by MTAs + receiving messages. This specification imposes no requirements on + parties performing this test in other environments. + +4.3. Record Lookup + + SPF records are looked up in DNS in accordance with Section 4.4 of + [RFC4408]. + + When performing 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 that were returned by the lookup, + record selection proceeds in these steps: + + + + +Lyon & Wong Experimental [Page 9] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + 1. If any records of type SPF are in the set, then all records of + type TXT are discarded. + + 2. Records that do not begin with proper version and scope sections + are discarded. The version section for "spf2" records contains a + ver-minor field that is for backward-compatible future extensions. + This field must be well formed for a record to be retained, but is + otherwise ignored. + + 3. Records that use the "spf2" version identifier and do not have a + scope-id that matches are discarded. Note that this is a + complete string match on the scope-id tokens: If is "pra", + then the record starting "spf2.0/mfrom,prattle,fubar" would be + discarded, but a record starting "spf2.0/mfrom,pra,fubar" would be + retained. + + 4. If the lookup returned two records, one containing the "v=spf1" + version identifier and the other containing the "spf2" version + identifier, the "spf2" version takes precedence for the desired + scope-id. If the "spf2" record does not contain the desired + scope-id, then the "v=spf1" record is selected. + + 5. If an "spf2" record does not contain the desired scope-id and + there is no "v=spf1" record for the domain, then no record is + selected. + + After the above steps, there should be one record remaining and + evaluation can proceed. If there are two or more records remaining, + then check_host() exits immediately with the error "PermError". + + If there are no matching records remaining after the initial DNS + query or any subsequent optional DNS queries, then check_host() exits + immediately with the result "None". + +5. Actions Based on the Decision + + When the Sender ID test is used by an SMTP server as part of + receiving a message, the server should take the actions described by + this section. + + The check_host() function returns one of the following results. See + [RFC4408] for the meaning of these results. + + + + + + + + + +Lyon & Wong Experimental [Page 10] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +5.1. Neutral, None, SoftFail, or PermError + + An SMTP server receiving one of these results SHOULD NOT reject the + message for this reason alone, but MAY subject the message to + heightened scrutiny by other measures, and MAY reject the message as + a result of this heightened scrutiny. + + Such additional security measures MAY take into account that a + message for which the result is "SoftFail" is less likely to be + authentic than a message for which the result is "Neutral". + +5.2. Pass + + An SMTP server receiving this result SHOULD treat the message as + authentic. It may accept or reject the message depending on other + policies. + +5.3. Fail + + When performing the Sender ID test during an SMTP transaction, an MTA + that chooses to reject a message receiving this result SHOULD reject + the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, + where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced + with the additional reason returned by the check_host() function, and + "zzz" is replaced with the explanation string returned by the + check_host() function. + + When performing the Sender ID test after accepting an e-mail message + for delivery, an MTA that chooses to reject a message receiving this + result SHOULD NOT deliver the message. Instead, it should create a + DSN message, consistent with the usual rules for DSN messages. + +5.4. TempError + + An SMTP server receiving this result MAY reject the message with a + "450 4.4.3 Sender ID check is temporarily unavailable" error code. + Alternatively, an SMTP server receiving this result MAY accept a + message and optionally subject it to heightened scrutiny by other + anti-spam measures. + +6. Security Considerations + + This entire document describes a new mechanism for mitigating spoofed + e-mail, which is today a pervasive security problem in the Internet. + + Assuming that this mechanism is widely deployed, the following + sections describe counter attacks that could be used to defeat this + mechanism. + + + +Lyon & Wong Experimental [Page 11] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +6.1. DNS Attacks + + The new mechanism is entirely dependent on DNS lookups, and is + therefore only as secure as DNS. An attacker bent on spoofing + messages could attempt to get his messages accepted by sending forged + answers to DNS queries. + + An MTA could largely defeat such an attack by using a properly + paranoid DNS resolver. DNS Security (DNSSEC) may ultimately provide + a way to completely neutralize this class of attacks. + +6.2. TCP Attacks + + This mechanism is designed to be used in conjunction with SMTP over + TCP. A sufficiently resourceful attacker might be able to send TCP + packets with forged from-addresses, and thus execute an entire SMTP + session that appears to come from somewhere other than its true + origin. + + Such an attack requires guessing what TCP sequence numbers an SMTP + server will use. It also requires transmitting completely in the + blind -- the attack will be unable to hear any of the server's side + of the conversation. + + Attacks of this sort can be ameliorated if IP gateways refuse to + forward packets when the source address is clearly bogus. + +6.3. Forged Sender Attacks + + This mechanism chooses an address to validate either from one of a + number of message headers or from the RFC 2821 MAIL command, and then + uses that address for validation. A message with a true Resent-From + header or Return-Path, but a forged From header, will be accepted. + Since many MUAs do not display all of the headers of received + messages, the message will appear to be forged when displayed. + + In order to neutralize this attack, MUAs will need to start + displaying at least the address that was verified. In addition, MTAs + could subject messages to heightened scrutiny when the validated + address differs from the From header. + +6.4. Address Space Hijacking + + This mechanism assumes the integrity of IP address space for + determining whether a given client is authorized to send messages + from a given PRA. In addition to the TCP attack given in Section + 6.2, a sufficiently resourceful attacker might be able to alter the + IP routing structure to permit two-way communication using a + + + +Lyon & Wong Experimental [Page 12] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + specified IP address. It would then be possible to execute an SMTP + session that appears to come from an authorized address, without the + need to guess TCP sequence numbers or transmit in the blind. + + Such an attack might occur if the attacker obtained access to a + router that participates in external BGP routing. Such a 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 class of attacks in which an attacker A can entice a + participant P to send a malicious message to a victim V. + + These attacks are undertaken by A citing the address of V in the SMTP + MAIL FROM request and then by causing P to generate (or invoke the + generation of) a Delivery Status Notification 'bounce' message + (RFC3464), which is sent to the victim V. + + The attacker relies upon it being common practice to copy the + original message into the 'bounce' report, thereby causing the malice + to be sent onward to V. + + This mode of attack has the advantages (to the attacker) of + obfuscating the location of the host from which the attack was + mounted, and of possibly damaging the reputation of P by making it + appear that P originated or was an active participant in the sending + of the malicious message. + + In current practice, A causes P to cause 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 selected by the attacker to be such that, when P undertakes the + Sender ID test, a Fail will result (Section 5.3). + + The message will be rejected (as the attacker intended) and a + malicious 'bounce' message may be generated and sent to the victim V. + +7. Implementation Guidance + + This section describes the actions that certain members of the + Internet e-mail ecosystem must take to be compliant with this + specification. + + + + + +Lyon & Wong Experimental [Page 13] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +7.1. Simple E-Mailers + + A domain that injects original e-mail into the Internet, using its + own name in From headers, need do nothing to be compliant. However, + such 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 + this case, domains SHOULD publish their information using an SPF + record with the prefix "v=spf1". Doing so will render their + published information usable by the older SPF protocol, too. (See + [RFC4408] for information on the SPF protocol.) + +7.2. E-Mail Forwarders + + In order to pass the PRA variant of the test, a program that forwards + received mail to other addresses MUST add an appropriate header that + contains an e-mail address that it is authorized to use. Such + programs SHOULD use the Resent-From header for this purpose. + + In order 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. Should that address + eventually receive a DSN relating 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, these messages MUST NOT be forwarded to the + original MAIL FROM address; they SHOULD be refused during an SMTP + transaction. + + In addition, 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 many of them use Sender rather than Resent-From.) Most of + them do not perform the address-rewriting specified above. + + Note that an e-mail forwarder might receive a single message for two + or more recipients, each of whom requests forwarding to a new + address. In this case, the forwarder's MTA SHOULD transmit the + message to each new recipient individually, with each copy of the + message containing a different newly inserted Resent-From header + field. + + + + + + +Lyon & Wong Experimental [Page 14] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +7.3. Mailing List Servers + + In order to pass the PRA variant of the test, a mailing list server + MUST add an appropriate header that contains an e-mail address that + it is authorized to use. Such programs SHOULD use the Resent-From + header for this purpose. + + In order 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. + + In addition, 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 + + In order to pass the PRA variant of this test, a program that sends + mail on behalf of another user MUST add an appropriate header that + contains an e-mail address that it is authorized to use. Such + programs SHOULD use the Sender header for this purpose. + + In order 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. Defining what the program does with any + mail received at that address is beyond the scope of this document. + + In addition, 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 are already + compliant with the PRA variant of the test. The extent to which + mailers are already compliant 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. + + + + + +Lyon & Wong Experimental [Page 15] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + + When a received message contains multiple headers that might be used + for the purported responsible address determination, an MUA should + consider displaying all of them. That is, if a message contains + several Resent-From's, a Sender, and a From, an MUA should consider + displaying all of them. + + Sender ID also does not validate the display name that may be + transmitted along with an e-mail address. The display name is also + vulnerable to spoofing and other forms of attacks. In order to + reduce the occurrence and effectiveness of such attacks, MUA + implementers should consider methods to safeguard the display name. + This could include the following: + + * Not presenting the display name to the user at all, or not + presenting the display name 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 [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 ancestry to "Repudiating Mail From" draft by Paul + Vixie [Vixie] (based on suggestion by Jim Miller) and to "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 incorporates + ideas proposed by many members of the MARID working group. The + contributions of each of the above are gratefully acknowledged. + + + + + + + + + + + + + +Lyon & Wong Experimental [Page 16] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +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 + + [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical + Specification, http://www.microsoft.com/mscorp/safety/ + technologies/senderid/resources.mspx + + [DMP] Fecyk, G., "Designated Mailers Protocol", + http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt, December + 2003. + + [Green] David Green, "Mail-Transmitter RR", + http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ + msg00656.html, June 2002. + + [RMX] H. Danisch, "The RMX DNS RR and method for lightweight + SMTP sender authorization", + http://www.danisch.de/work/security/txt/ + draft-danisch-dns-rr-smtp-04.txt + + [Vixie] Paul Vixie, "Repudiating Mail From", + http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ + msg00658.html, June 2002. + + + + + + + + + + + +Lyon & Wong Experimental [Page 17] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lyon & Wong Experimental [Page 18] + +RFC 4406 Sender ID: Authenticating E-Mail April 2006 + + +Full Copyright Statement + + 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found 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 made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Lyon & Wong Experimental [Page 19] + -- cgit v1.2.3