Internet Draft Category: Experimental Mark Lentczner draft-ietf-marid-spf-5-helo-00.txt Meng Weng Wong, pobox.com Expires: September 2004 July 2004 SPF/HELO Determining sender policy for the HELO domain name 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/HELO test, which uses the spf_test() function in conjunction with the HELO argument in an SMTP transaction. This document describes the mechanics, semantics and utility of the SPF/HELO 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 HELO/EHLO command of an SMTP/ESMTP transaction. Mail receivers perform the SPF/HELO 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 make local policy decisions on the basis of the HELO domain name. 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. 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 HELO 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/HELO test, and ensure their record reflects their domain's policy on who is permitted to use the domain name in HELO. For example, suppose the MTA 192.0.2.2 issues the SMTP greeting: HELO mx.example.com. If the owner of the domain mx.example.com approves of this use of its name by 192.0.2.2, the SPF record for mx.example.com 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. 1.3 Related Proposals The essential semantics of SPF/HELO are shared by [CSV]. 2 Inputs to the spf_test() Function In an SMTP session, an SMTP client should provide a FQDN in the EHLO or HELO command. [RFC2821] This FQDN, when present and well-formed, is called the HELO domain for the purposes of this document. To perform the SPF/HELO Test, an SMTP server evaluates the spf_test() function with these arguments: -- the IP address of the SMTP client -- the HELO domain -- the string "helo" 2.1 Considerations The SMTP standard allows the FQDN in the EHLO and HELO command to be replaced with an address literal in situations where the FQDN is not available. Best practices recommend the use of an FQDN, and most sending domains do use an FQDN. If the argument to the EHLO (or HELO) command is not a well formed FQDN (for example, is an address literal, as defined by [RFC2821], or doesn't contain a period, or is blank), then the SPF/HELO test has a result of "none". There is no need to evaluate spf_test() in this situation; the result is deemed to be "none". 3. Applicability Statement The SPF/HELO test is equivalent to asking the question "Does the domain indicated in the HELO command 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/HELO 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/HELO 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 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. In particular, since the SPF test will be performed on the FQDN given in the EHLO (or HELO) command, an SPF publisher will need to publish SPF records for domains used in this way. If an organization's MTAs use their own host name as the FQDN, then each will require an SPF record. This may or may not be a issue for system administrators. On the other hand, an organization may choose to have all their MTAs use the same FQDN in the EHLO command, thereby only needing one SPF record to handle them all. Such usage was not anticipated by RFC 2821. A domain could choose to have that single FQDN forward map to all the IPs of the MTAs in order to be strictly adherent. However, we know of no software that would require such a list, though there might be local policies that do. 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