Internet Draft Mark Lentczner Category: Experimental Wayne Schlitt draft-schlitt-marid-spf-from-hdr-00.txt Meng Weng Wong, pobox.com Expires: December 2004 July 2004 SPF/FROM-HDR Determining sender policy for the From: header Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in December 2004. Abstract This document is part of the Unified SPF series. It defines the SPF/FROM-HDR test, which uses the spf_test() function in conjunction with the From: header of the email. This document describes the mechanics, semantics and utility of the SPF/FROM-HDR test. It also recommends receiver policy actions. Table of Contents 1. Introduction 1.1 Requirement levels 1.1.1 The operations described are NOT REQUIRED of receivers. Schlitt, Wong & Lentczner [Page 01] Internet-Draft Sender Policy Framework Jul 12 2004 1.1.2 DNS publishers SHOULD expect evaluation in this context. 1.2 Terminology 2 Inputs to the spf_test() Function 2.2 Considerations 2.1. Email Authentication Algorithm 3. Applicability Statement 3.1 Interpretation of Results 4. Changes to Existing Semantics 5. Recommendations for MTAs and MUAs 5.1 Simple E-mailers 5.2 E-mail Forwarders 5.3 Mailing List Servers 5.4 MUA Implementers Normative References Informative References Authors 1. Introduction Owners of domain names can publish SPF records to distinguish between hosts which are and are not permitted to use their names in the email's From: header. Mail receivers perform the SPF/FROM-HDR test to determine if a particular host is permitted according to the domain's published SPF record. This distinction is useful to mail receivers who seek to ensure that the email address on the From: header is either from a source authenticated by the "from" domain owner, or from a source approved (whitelisted) by the receiver. 1.1 Requirement levels 1.1.1 The operations described are NOT REQUIRED of receivers. Mail receivers are NOT REQUIRED to perform the operations described herein. If they choose to perform these operations, however, they MUST follow the forms prescribed. This document defines how to evaluate the spf_test function described in [spf-protocol] in the context of the From: header domain name, and assigns a meaning to the result of that evaluation. 1.1.2 DNS publishers SHOULD expect evaluation in this context. Domain owners who publish an SPF record for a given domain name Schlitt, Wong & Lentczner [Page 02] Internet-Draft Sender Policy Framework Jul 12 2004 should expect that record to be evaluated in the context of the SPF/FROM-HDR test, and ensure their record reflects their domain's policy on who is permitted to use the domain name in the From: header. For example, suppose the MTA 192.0.2.2 sends mail with the header: From: If the owner of the domain example.org approves of this use of its name by 192.0.2.2, the SPF record for example.org MUST return a PASS result for 192.0.2.2. For more information on interactions with other tests, see: [SPF Unified]. 1.2 Terminology 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]. This document uses other terminology defined in the [SPF protocol] document. 2 Inputs to the spf_test() Function To perform the SPF/FROM-HDR Test, an SMTP server or MUA evaluates the spf_test() function with these arguments: -- the IP address of the SMTP client -- the domain from the first email address on the From: header -- the string "from-hdr" 2.2 Considerations Email received by an individual mail box may come from many different sources, but the vast majority of email will come from one of two sources. First, email may be sent directly, in which case the From: header of the email should be able to be authenticated. Second, email may be sent indirectly through a forwarding relationship that the receiver has set up and authorized. While there may be many email forwarding relationships in general, each individual mail box will usually have a very small set of these relationships, and the set does usually change very often. Since such forwarding relationships are created by the receiver, the receiver will generally try not to use forwarders that do not Schlitt, Wong & Lentczner [Page 03] Internet-Draft Sender Policy Framework Jul 12 2004 abuse the receivers trust. There are many types of email forwarding relationships, but the two most common are mailing lists and mailbox aliases where the receiver has elected to have all email sent to one mail box to be forwarded to another, possibly on a different system. In the case of mailing lists, RFC2821 says that the return address (the envelope from) is changed to the list administrator, which can be used as a receiver approved whitelist value. In the case of aliases, the To: header usually contains the mail box that the email was forwarded from, and thus can be used as a receiver approved whitelist value. The MTA doing the forwardering will also usually be from a limited set, which can be used as a receiver approved whitelist value. Email that does not come directly to the mail box or through a receiver approved forwarding relationship should be considered highly suspect. 2.1. Email Authentication Algorithm In order authenticate the email as being valid, the following steps SHOULD be followed. Additional step and/or omitting steps may be appropriate, depending on the email receiver's situation. 1. Check the first mailbox found on the From: header to see if it passes. That is, from_result = spf_test(From:,IP). If the result passes, then exit and return the from_result. 2. Check to see if any of the mailboxes on the To: header has been whitelisted by the receiver. For each whitelisted mailbox, check to see if the spf_test(To:,IP) passes. If any of them do, then the exit and return "pass". 3. Check to see if the RFC2821 envelope from domain is whitelisted by the receiver. If it is, check to see if the spf_test(MAIL FROM, IP) passes. If the result passes, then exit and return "pass". 4. Check to see if the RFC2821 HELO domain is whitelisted by the receiver. If it is, check to see if the spf_test(HELO,IP) passes. If the result passes, then exit and return "pass". 5. Return the from_result as obtained from step 1. 3. Applicability Statement Schlitt, Wong & Lentczner [Page 04] Internet-Draft Sender Policy Framework Jul 12 2004 The SPF/FROM-HDR test is equivalent to asking the question "Does the domain indicated in the From: header authorize the client host to initiate SMTP sessions on its behalf?" Receivers may use the result as an input to local policy decisions. For example, rejections can be returned early in the SMTP transaction if the host is not authorized by the domain. If the host is authorized, then policy can be based on the reputation of the domain, rather than the host IP. For more information on local policy decisions, see [SPF Unified]. 3.1 Interpretation of Results This section gives recommendations for local policy regarding the SPF/FROM-HDR test. A compliant SPF local policy needs to take into account any other SPF tests that are performed. See [SPF Unified] for a complete set of requirements for local policy. If SPF/FROM-HDR is the only SPF test performed on the SMTP session, then these recommendations are a conformant policy under [SPF Unified]. If any other SPF tests are performed, [SPF Unified] MUST be consulted. In the case of conflict between this section and [SPF Unified], the latter is considered normative. Result: Fail Policy: The client is explicitly not authorized by the domain to initiate SMTP sessions. Receivers MAY terminate the SMTP session with a 550 code. The text of the 550 rejection should include the explanation string, if any, that was set in the SPF record's exp= modifier. Result: Pass Policy: Since the client is authorized by the domain, further processing can be based on the reputation of the domain name. For example, if the domain is in a local white-list, all further mail could be accepted without further checks. On the other hand, if the domain has a negative reputation, the session MAY be terminated with a 550 Local Policy response. Result: Error Policy: this indicates a transient error. Receivers MAY return an Schlitt, Wong & Lentczner [Page 05] Internet-Draft Sender Policy Framework Jul 12 2004 SMTP 450 Temporary Failure code. Result: Neutral, Unknown, or None Policy: In these cases, no determination about the client can be made. Local policy may dictate that the messages in this session will be subject to further tests and/or marked as being from an unverified MTA. Result: Softfail Policy: This result SHOULD be treated as equivalent to a FAIL result. In any case, if the domain has a negative reputation, a receiver MAY terminate the session with a 550 Local Policy rejection. 4. Changes to Existing Semantics There are no changes in semantics to existing protocols. However, the existence of this test may cause system administrators to make some choices differently. 5. Recommendations for MTAs and MUAs This section describes the actions that certain members of the Internet email ecosystem must take to be compliant with this specification. 5.1 Simple E-mailers A domain that injects original email into the Internet, using its own name in From: headers, need do nothing to be compliant. However, such domains SHOULD publish e-mail policy records in DNS. 5.2 E-mail Forwarders A program that forwards received mail to other addresses SHOULD rewrite the RFC2821 envelope from to their own domain to accept responsibility for any bounces that are created and to facilitate receiver approved whitelisting. Email forwarders should also use a consistent and valid HELO domain to facilitate whitelisting. 5.3 Mailing List Servers Schlitt, Wong & Lentczner [Page 06] Internet-Draft Sender Policy Framework Jul 12 2004 A mailing list server SHOULD rewrite the RFC2821 envelope from to the the list administrators email address to accept responsibility for any bounces that are created and to facilitate receiver approved whitelisting. Almost all of today's mailing list software already rewrites the RFC2821 envelope from. 5.4 MUA Implementers When displaying a received message, an MUA SHOULD display the results of the email authentication algorithm. Normative References [RFC2396] Informative References [RFC1034] [RFC1464] [RFC2119] [RFC2142] [RFC2234] [RFC2373] [RFC2505] [RFC2821] [RFC2822] Authors Wayne Schlitt 4615 Meredeth #9 Lincoln, NE 68506 United Status of America wayne@midwestcs.com Meng Weng Wong Singapore mengwong+spf@pobox.com Schlitt, Wong & Lentczner [Page 07] Internet-Draft Sender Policy Framework Jul 12 2004 Mark Lentczner 1209 Villa Street Mountain View, CA 94041 United States of America markl@glyphic.com Comments on this draft are welcome. In the interests of openness, before contacting the authors directly, please post to the spf-discuss mailing list. To join the mailing list, please see http://spf.pobox.com/mailinglist.html