Internet Draft Category: Experimental J. Lyon, Microsoft Corp draft-ietf-marid-spf-7-pra-00.txt Meng Weng Wong, pobox.com Expires: September 2004 July 2004 SPF/PRA Determining sender policy for the Purported Responsible Address Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is part of the Unified SPF series. It defines the SPF/PRA test, which uses the spf_test() function in conjunction with the Purported Responsible Address (PRA) from an email message. This document describes the mechanics, semantics and utility of the SPF/PRA test. It also recommends receiver policy actions. The PRA is defined according to an algorithm which selects the Purported Responsible Address from a variety of headers. The specification is carefully tailored to ensure that the overwhelming majority of legitimate emailers, remailers and mailing list operators are already compliant. Table of Contents TOC GOES HERE 1. Introduction Today, a huge majority of unwanted email contains headers that misrepresent origination. For example, mail may come from a broadband end-user machine in Europe but claim to be sent by an AOL subscriber in the US. This is true of most spam and substantially all of the virus email that is sent. It is generally believed that a reduction in such forgery would provide a benefit to the community of email users. This document describes a mechanism which allows receiving MTAs, MDAs and/or MUAs to distinguish between authorized and unauthorized uses of domain names in certain email headers. This distinction is useful to mail receivers who seek to make local policy decisions on the basis of the Purported Responsible Address (PRA). For example, a receiver may wish to whitelist permitted MTAs from trusted domains. Or a receiver may wish to reject SMTP transactions from hosts that are not permitted to use the FQDN according to the domain owner's published record. Owners of domain names can publish SPF records to distinguish between hosts which are and are not permitted to use their names in the origination headers of an email message. Mail receivers perform the SPF/PRA test to determine if a particular host is permitted according to the domain's published SPF record. Once the distinction has been made, an MTA might refuse to accept a message, an MDA might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion. 1.1 Requirement levels 1.1.1 This document describes operations but does not require them. This document does not require mail receivers 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 PRA domain name, and assigns a meaning to the result of that evaluation. Other documents raise the requirement level for SPF/PRA; see [SPF Unified] and [SPF BestPractices]. 1.1.2 DNS publishers SHOULD expect evaluation in this context. Domain owners who publish an SPF record for a given domain name should expect that record to be evaluated in the context of the SPF/PRA test, and ensure their record reflects their domain's policy on who is permitted to use the domain name in PRA. For example, suppose the MTA 192.0.2.4 sends mail with the header: Sender: If the owner of the domain mx.example.com approves of this use of its name by 192.0.2.4, the SPF record for mx.example.com MUST return a PASS result for 192.0.2.4. 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. << Text contained in double angle brackets describes actions that are yet to be taken and decisions that are yet to be made. No such text should survive in the final version of this draft. >> 1.3 Related Proposals The essential semantics of SPF/PRA are shared by [CallerID]. 2 Inputs to the spf_test() Function To perform the SPF/PRA Test, an SMTP server evaluates the spf_test() function with these arguments: -- the IP address of the SMTP client
-- the Purported Responsible Address from the headers -- the string "pra" 2.1. Determining the Purported Responsible Address The purported responsible address (PRA) of a message is determined by the following algorithm: 1. Locate the first non-empty Resent-Sender header in the message. If no such header is found, proceed to step 2. If it is preceded by a non-empty Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header, proceed to step 2. If the Resent-Sender header is hopelessly malformed (e.g. it appears to contain multiple mailboxes, or if the single mailbox is hopelessly malformed) then exit, without returning a PRA. Otherwise exit, returning the mailbox from the Resent-Sender header as the PRA. 2. Locate the first non-empty Resent-From header in the message. If no such header is found, proceed to step 3. If it is hopelessly malformed (e.g. one or more mailboxes in the header are hopelessly malformed) then exit without returning a PRA. If it contains multiple mailboxes, then exit without returning a PRA. Otherwise exit, returning the single mailbox from the Resent-From header as the PRA. 3. Locate the first non-empty Delivered-To, X-Envelope-To or Envelope-To header in the message. If no such header is present, proceed to step 4. If it appears to contain multiple mailboxes, then exit without returning a PRA. Otherwise, treat the contents of the header as a mailbox, and exit returning this mailbox as the PRA (unless the mailbox is hopelessly malformed, in which case exit without returning a PRA). << Note. This means that a non-standard header that does *not* contain a single valid mailbox will cause the PRA algorithm to fail and may cause the message to be rejected. But anything else means that the process doing the MARID checks might make a different decision as to the validity of the mailbox from a subsequent MUA which attempts to display the purported responsible address by parsing the headers. Maybe it would be better to drop this step, and go back to only considering RFC(2)822 headers? >> 4. Locate all the non-empty Sender headers in the message. If there are no such headers, continue to step 5. If there are multiple such headers, exit without returning a PRA. If the single non-empty Sender header is hopelessly malformed (e.g. if it appears to contain multiple mailboxes, or if the single mailbox is hopelessly malformed), exit without returning a PRA. Otherwise, exit returning the mailbox from the Sender header as the PRA. 5. Locate all the non-empty From headers in the message. If there are no such headers, or multiple such headers, exit without returning a PRA. If the single non-empty From header is hopelessly malformed (e.g. it contains one or more mailboxes that are hopelessly malformed) then exit without returning a PRA. If it contains multiple mailboxes, exit without returning a PRA. Otherwise, return the single mailbox from the From header as the PRA. The purported responsible domain of the message is the domain part of the purported responsible address returned by the above algorithm. 2.2 Considerations If the above algorithm fails to return a PRA, or if the PRA does not contain a domain, then the result of the SPF/PRA test is deemed to be "fail", and an MTA SHOULD reject the message as hopelessly malformed. The [Submitter] document specifies a way in which the PRA may be promoted into the MAIL command as a pre-DATA optimization. 3. Applicability Statement The SPF/PRA test is equivalent to asking the question "Does the PRA authorize the client host to send mail?" 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/PRA 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/PRA is the only SPF test performed on the message, 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 not authorized by the domain to send mail with its name in the PRA. Receivers MAY terminate the SMTP transaction 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 a 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 somewhere between Unknown and Fail; the transaction should be allowed to proceed, but it should be subjected to extra scrutiny. In any case, if the domain has a negative reputation, a receiver MAY terminate the session with a 550 Local Policy rejection. 3.1.1 Special SUBMITTER behaviour If the PRA is determined before DATA time using the SUBMITTER parameter to MAIL, the results Neutral, None, and Softfail MUST be treated as equivalent to FAIL. Any sending MTA that provides SUBMITTER MUST ensure that the domain specified in SUBMITTER publishes an SPF record that evaluates to a PASS for that MTA. If the domain in SUBMITTER does not publish an SPF record, the MTA should refrain from passing SUBMITTER. 4. Changes to Existing Semantics SPF/PRA may require some mail senders to be more particular about prepending headers. End-users may need to "phone home" to their domain's approved MSA servers and use an authentication technology such as SMTP AUTH to perform message submission. This change is structurally similar to the closing of open relays. 5. Problem Statement 5.1 Positive 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 the mailbox that allegedly caused the most recent introduction of the message into the mail delivery system? 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 mechanism of this document also 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 mailing list server, the address being authenticated is that of the third party, the forwarder or the mailing list. This document provides means to authenticate the DOMAIN of the appropriate email address; it makes no attempt 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.) 5.2 Negative Problem Statement This section describes alternate questions, which this document makes no attempt to solve. Is the host at a particular IP address authorized to act as an SMTP client? [SPF/PTR] attempts to answer this question using a reverse DNS lookup. It suffers from the fact that reverse DNS lookups are poorly implemented in major fractions of the IP address space, from the fact that many ISPs refuse to reverse-delegate to small domains, and from the fact that it's all or nothing: authority to act as an SMTP client conveys authority to send absolutely any email, legitimate or otherwise. Is an SMTP client authorized to use a particular domain name in its SMTP EHLO command? [SPF/HELO] attempts to answer this question. Is an SMTP client authorized to use a particular email address in an SMTP "MAIL FROM:" command? [SPF/MAILFROM] attempts to answer this question. These suffer from the fact that the MAIL FROM address really describes where to send DSNs to, and in many third-party and forwarder situations this address is unrelated to the domain that is resending the message. Was a message really authored by who it claims to be authored by? [SMIME] and [DK] attempt to answer the question of original authorship. While this is a useful question to answer, cryptographic approaches face significant deployment challenges. 6. 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. 6.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. 6.2 E-mail Forwarders A program that forwards received mail to other addresses MUST add an appropriate header that contains an email address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose. Many of today's forwarders already add an appropriate header (although most of them use Delivered-To or some other nonstandard header rather than Resent-From.) 6.3 Mailing List Servers A mailing list server MUST add an appropriate header that contains an email address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose. Most of today's mailing list software already adds an appropriate header (although most of them use Sender rather than Resent-From). 6.4 Third-Party Mailers A program that sends mail on behalf of another user MUST add an appropriate header than contains an email address that it is authorized to use. Such programs SHOULD use the Sender header for this purpose. Many, but not all, of today's third-party mailers are already compliant. 6.5 MTA Implementers MTAs that are acting as SMTP servers SHOULD implement the checks described in this document. See also [SPF Protocol]. 6.6 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 From address. This display SHOULD be in addition to the From address. 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. 7. IANA Considerations The IANA is requested to register the following URI: URI: urn:ietf:params:xml:schema:marid-1 Registrant Contact: IESG. XML: See [SPF XML]. 8. Acknowledgements Variations on the idea of using a DNS record to check the legitimacy of an email address have occurred multiple times. The earliest known work is [RMX]; others include [SPF} and [CallerID]. The current document borrows heavily from each of the above, and incorporates many ideas proposed by many members of the MARID working group. References Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2026] S. Bradner, "The Internet Standards Process – Revision 3", RFC 2026. [RFC3275] D. Eastlake et al, "XML-Signature Syntax and Processing", RFC 3275. [XMLSchema] "XML Schema Part 1: Structures", W3C Recommendation 2 May 2001, http://www.w3c.org/TR/2001/REC-xmlschema-1- 20010502/ Informative References [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical Specification, http://www.microsoft.com/mscorp/twc/privacy/spam_callerid .mspx. [CSV] D. Crocker, "Client SMTP Validation (CSV)", draft- crocker-marid-smtp-validate-01. Work in progress. [DK] M. Delany, "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", draft- delany-domainkeys-base-00. Work in progress. [MTAMARK] M. Stumpf, and S. Hoehne, "Marking Mail Transfer Agents in Reverse DNS with TXT RRs", draft-stumpf-dns-mtamark- 02. Work in progress. [RMX] H. Danisch, "The RMX DNS RR and method for lightweight SMTP sender authorization", draft-danisch-dns-rr-smtp-04. Work in progress. [SMIME] B. Ramsdell (editor), "S/MIME Version 3 Message Specification", RFC 2633. [SPF] M. Lentczner and M. Weng, "Sender Policy Framework (SPF): A Convention to Describe Hosts Authorized to Send SMTP Traffic", draft-mengwong-spf-01. Work in progress. [Submitter] E. Allman and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message", draft-ietf-marid-submitter-00. Work in progress. Authors' Addresses Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA jimlyon@microsoft.com Meng Weng Wong Singapore mengwong@dumbo.pobox.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.