Internet Draft Category: Experimental Mark Lentczner draft-ietf-marid-spf-6-mailfrom-00.txt Meng Weng Wong, pobox.com Expires: September 2004 July 2004 SPF/MAIL-FROM Determining sender policy for the MAIL-FROM return-path 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 September 2004. Abstract This document is part of the Unified SPF series. It defines the SPF/MAIL-FROM test, which uses the spf_test() function in conjunction with the MAIL FROM parameter in an SMTP transaction. This document describes the mechanics, semantics and utility of the SPF/MAIL-FROM test. It also recommends receiver policy actions. Table of Contents TOC GOES HERE 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 MAIL FROM parameter in an SMTP/ESMTP transaction. Mail receivers perform the SPF/MAIL-FROM test to determine if a particular host is permitted according to the domain's published SPF record. This distinction is useful to mail receivers and domain name owners because it mitigates against return-path forgery which leads to unwanted bounce messages. For mail receivers, it also allows reliable policy decisions on the basis of the MAIL FROM domain name. For example, a receiver may wish to accept mail without further checks from trusted domains. Or a receiver may wish to reject messages from domains that are known sources of unwanted mail. 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 MAIL FROM 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 should expect that record to be evaluated in the context of the SPF/MAIL-FROM test, and ensure their record reflects their domain's policy on who is permitted to use the domain name in MAIL FROM. For example, suppose the MTA 192.0.2.3 issues the SMTP command: MAIL FROM: If the owner of the domain mx.example.com approves of this use of its name by 192.0.2.3, the SPF record for example.com MUST return a PASS result for 192.0.2.3. 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. The operations described in this document are often referred to as "SPF Classic". They differ from prior Internet Drafts in several minor and largely insignificant respects. 1.3 Related Proposals The essential semantics of SPF/MAIL-FROM are shared by [DMP], [RMX], [Repudiating Mail-From], and [SPF Classic]. 2 Inputs to the spf_test() Function In an SMTP transaction, an SMTP client provides the return-path mailbox address in the MAIL command. This mailbox is commonly called the "envelope from address", or the "2821 From address", and is called the "" in [RFC 2821]. When this mailbox is present, and has a well formed domain part, then that domain is called the MAIL FROM domain for the purposes of this document. To perform the SPF/MAIL-FROM Test, an SMTP server evaluates the spf_test() function with these arguments: -- the IP address of the SMTP client
-- the MAIL FROM address -- the string "mail-from" 2.1 Considerations The SMTP standard allows the mailbox in the MAIL command to be the empty address ("<>") in some circumstances. If the mailbox is empty, or does not contain a domain part, then the SPF/MAIL-FROM test has a result of "None". There is no need to evaluate spf_test() in this situation; the result is deemed to be "None". Note: This is a change from prior SPF proposals (see [SPF Classic]). The fall back to using the HELO domain is not part of the SPF/MAIL-FROM test. If mail receivers wish to use such logic, they SHOULD formulate a local policy that incorporates both the SPF/MAIL-FROM and SPF/HELO tests. See [SPF Unified] for details. 3. Applicability Statement The SPF/MAIL-FROM test is equivalent to asking the question "Does the domain indicated in the MAIL command authorize the client host to inject mail on its behalf?" Receivers may further use the result of the SPF/MAIL-FROM test 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. 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/MAIL-FROM 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/MAIL-FROM 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 inject mail via SMTP. 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 transaction 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 message in this transaction 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. 4. Changes to Existing Semantics When the SPF/MAIL-FROM test is performed on the MAIL domain, the domain in the source mailbox is now considered accountable for injecting the message into the mailstream, in addition to its role for error reporting. From [RFC2821]: The portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see section 4.2 for a discussion of error reporting). This semantic change is justified by the desire to control bounces from forged messages (including the bounce's undesirable contents), the confusion and damage to the domain owner's good name, and the usefulness of having a reliable identity to whitelist. 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. Normative References [RFC2396] Informative References [RFC1034] [RFC1464] [RFC2119] [RFC2142] [RFC2234] [RFC2373] [RFC2505] [RFC2821] [RFC2822] Authors Meng Weng Wong Singapore mengwong+spf@pobox.com 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 Developers of SPF-conformant software SHOULD join the spf-devel mailing list. They also SHOULD consult the SPF Developers Guide at http://spf.pobox.com/developers-guide.html. While specifications published as RFCs are relatively static, the mailing list and developers guide are living resources. They augment this core protocol specification with generally accepted implementation practices which are outside the scope of this document. They also provide a forum for interoperability testing.