--- draft-schlitt-spf-02.clean.txt 2004-12-27 16:51:17.000000000 -0600 +++ draft-schlitt-spf-classic-00.clean.txt 2004-12-30 17:48:06.000000000 -0600 @@ -2,11 +2,11 @@ Network Working Group M. Wong Internet-Draft W. Schlitt -Expires: June 27, 2005 December 27, 2004 +Expires: June 30, 2005 December 30, 2004 Sender Policy Framework: Authorizing Use of Domains in E-MAIL - draft-schlitt-spf-02 + draft-schlitt-spf-classic-00 Status of this Memo @@ -33,7 +33,7 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 27, 2005. + This Internet-Draft will expire on June 30, 2005. Copyright Notice @@ -176,18 +176,17 @@ address", "2821 FROM", or "MAIL FROM". Since these terms are either not well defined, or often used casually, this document defines the "MAIL FROM" identity in Section 2.2. Note that other terms, that may - superficially look like the common terms, such as "reverse-path" or - "Return-Path" are used only with the defined meanings from normative - documents. + superficially look like the common terms, such as "reverse-path", are + used only with the defined meanings from normative documents. 2. Operation 2.1 The HELO Identity The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC2821].) These commands supply the SMTP client (sender) for - the STMP session. Note that requirements for the domain presented in + the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, - and receiving software must be prepared for the "HELO" identity to be + and SPF client must be prepared for the "HELO" identity to be malformed. SPF clients MAY check the "HELO" identity by calling the check_host() @@ -241,7 +240,7 @@ RECOMMENDED because there are cases that are known to give incorrect results. - It is expected that mail receivers will use the SPF check as part of + It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. For example, finding the sending host on a local white list may cause @@ -271,8 +270,8 @@ Care must be taken to correctly extract the from the as many MTAs will still accept such things as source routes (see [RFC2821] appendix C), the percent hack (see [RFC2162]) and bang - paths (see [RFC1983]). Spammers often use of such archaic features - to try and trick MTAs into being open relays. + paths (see [RFC1983]). These archaic features have been maliciously + used to bypass security systems. Software SHOULD perform this authorization check during the processing of the SMTP transaction that injects the mail. This allows errors to be returned directly to the injecting server by way @@ -323,12 +322,12 @@ mail outright. If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see - [RFC2821]) and the 5.7.1 DSN code (see [RFC2034]), in addition to an - appropriate message. The check_host() function may return either a - default explanation string, or one from the domain that published the - SPF records (see Section 6.2). If the information doesn't originate - with the checking software, it should be made clear that text is not - trusted. For example: + [RFC2821]) and, if supported, the 5.7.1 DSN code (see [RFC2034]), in + addition to an appropriate message. The check_host() function may + return either a default explanation string, or one from the domain + that published the SPF records (see Section 6.2). If the information + doesn't originate with the checking software, it should be made clear + that text is not trusted. For example: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: @@ -338,40 +337,39 @@ 2.5.5 SoftFail A SoftFail result should be treated as somewhere between a Fail and a - Neutral. This value is used by domains as an intermediate state - during roll-out of publishing records. The domain believes the host - isn't authorized but isn't willing to make that strong of a - statement. Receiving software SHOULD NOT reject the message based on - this result, but MAY subject the message to closer scrutiny. - - Because the domain has discouraged any legitimate use of this IP - address, receivers MAY try to inform either the sender or the - recipient of the e-mail. For example, the MUA could highlight the - SoftFail status for the receiver, or the MTA could issue an SMTP - reply code of 451 and the 4.3.0 DSN code, in addition to an with a - note the first time the message was received, but accept it the - second time. + Neutral. The domain believes the host isn't authorized but isn't + willing to make that strong of a statement. Receiving software + SHOULD NOT reject the message based on this result, but MAY subject + the message to closer scrutiny. + + Since the domain has discouraged the use of this host, receivers MAY + try to inform either the sender or the recipient of the e-mail. As + examples, the recipient's MUA could highlight the SoftFail status. + Or the MTA could give the sender a message using a technique called + "greylisting" where by the MTA can issue an SMTP reply code of 451 + (4.3.0 DSN code) with a note the first time the message was received, + but accept it the second time. 2.5.6 TempError - A TempError result means that the receiving server encountered a - transient error when performing the check. Checking software can - choose to accept or temporarily reject the message. If the message - is rejected during the SMTP transaction for this reason, the software - SHOULD use an SMTP reply code of 451 and the 4.4.3 DSN code. + A TempError result means that the SPF client encountered a transient + error when performing the check. Checking software can choose to + accept or temporarily reject the message. If the message is rejected + during the SMTP transaction for this reason, the software SHOULD use + an SMTP reply code of 451 and, if supported, the 4.4.3 DSN code. 2.5.7 PermError A PermError result means that the domain's published records couldn't be correctly interpreted. Checking software SHOULD reject the - message. If rejecting during SMTP transaction time, an SHOULD use an - SMTP reply code of 550 and the 5.5.2 DSN code. + message. If rejecting during SMTP transaction time, it SHOULD use an + SMTP reply code of 550 and, if supported, the 5.5.2 DSN code. 3. SPF Records An SPF record declares which hosts are, and are not, authorized to use a domain name for the "HELO" or "MAIL FROM" identity. Loosely, the record partitions all hosts into permitted and not-permitted - sets. (Though some hosts might fall into other categories.) + sets. (Though some hosts might fall into neither category.) The SPF record is a single string of text. An example record is: @@ -385,7 +383,7 @@ Domain owners wishing to be SPF compliant must publish SPF records for the hosts that are used in both the MAIL FROM and HELO identities. The SPF records are placed in the DNS tree at the host - name it partains to, not a subdomain under it, such as is done with + name it pertains to, not a subdomain under it, such as is done with SRV records. This is the same whether TXT RRs or SPF RRs are used. The example above in Section 3 might be published easily via this @@ -394,18 +392,17 @@ example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. IN TXT "v=spf1 a -all" - When published via TXT records, there may be other TXT records for - other purposes published there and this may cause problems with size - limits (see Section 3.1.4.) + When publishing via TXT records, beware of other TXT records + published there for other purposes. They may cause problems with + size limits (see Section 3.1.4.) An SPF record published at the zone cut for the domain will be used - as a default for all other domains and subdomains within the zone. - See Section 4.5 for details. Domain owners SHOULD publish SPF - records for hosts used for the HELO and MAIL FROM identities instead - of using the zone cut default because the fallback requires - additional DNS lookups. The zone cut default does reduce the need to - publish SPF records for non-email related hosts, such as - www.example.com. + as a default for all subdomains within the zone (See Section 4.5.) + Domain owners SHOULD publish SPF records for hosts used for the HELO + and MAIL FROM identities instead of using the zone cut default + because the fallback requires additional DNS lookups. The zone cut + default does reduce the need to publish SPF records for non-email + related hosts, such as www.example.com. 3.1.1 DNS Resource Record Types @@ -413,6 +410,7 @@ type code to be determined. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as US-ASCII. + It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle @@ -482,18 +480,18 @@ all, and for subdomains thereof. For example, the example given in [RFC1034], Section 4.3.3, could be extended with: - X.COM MX 10 A.X.COM - X.COM TXT "v=spf1 a:A.X.COM -all" + X.COM. MX 10 A.X.COM + X.COM. TXT "v=spf1 a:A.X.COM -all" - *.X.COM MX 10 A.X.COM - *.X.COM TXT "v=spf1 a:A.X.COM -all" + *.X.COM. MX 10 A.X.COM + *.X.COM. TXT "v=spf1 a:A.X.COM -all" - A.X.COM A 1.2.3.4 - A.X.COM MX 10 A.X.COM - A.X.COM TXT "v=spf1 a:A.X.COM -all" + A.X.COM. A 1.2.3.4 + A.X.COM. MX 10 A.X.COM + A.X.COM. TXT "v=spf1 a:A.X.COM -all" - *.A.X.COM MX 10 A.X.COM - *.A.X.COM TXT "v=spf1 a:A.X.COM -all" + *.A.X.COM. MX 10 A.X.COM + *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" Notice that SPF records must be repeated twice for every name within the domain: Once for the name, and once with a wildcard to cover the @@ -600,7 +598,7 @@ 4.6.1 Term Evaluation There are two types of terms: mechanisms and modifiers. A record - contains an ordered list of these mechanisms and modifiers: + contains an ordered list of these as specified in the following ABNF. terms = *( 1*SP ( directive / modifier ) ) @@ -841,18 +839,18 @@ 5.5 "ptr" This mechanism tests if the DNS reverse mapping for exists and - validly points to a domain name within a particular domain. + correctly points to a domain name within a particular domain. PTR = "ptr" [ ":" domain-spec ] First the 's name is looked up using this procedure: perform a DNS reverse-mapping for , looking up the corresponding PTR record - in "in-addr.arpa." if the address is an IPv4 one and "ip6.arpa." if - it is an IPv6 address. For each record returned, validate the domain - name by looking up its IP address. To prevent DoS attacks, a limit - of 10 PTR names MUST be enforced (see Section 10). If is among - the returned IP addresses, then that domain name is validated. In - pseudocode: + in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." + if it is an IPv6 address. For each record returned, validate the + domain name by looking up its IP address. To prevent DoS attacks, a + limit of 10 PTR names MUST be enforced (see Section 10). If is + among the returned IP addresses, then that domain name is validated. + In pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. @@ -1014,11 +1012,11 @@ then treated as an which is macro-expanded. This final result is the explanation string. - Software evaluating check_host() can use this string when to - communicate information from the publishing domain in the form of a - short message or URL. Software should make it clear that the - explanation string comes from a third party. For example, it can - prepend the macro string "%{o} explains: " to the explanation. + Software evaluating check_host() can use this string to communicate + information from the publishing domain in the form of a short message + or URL. Software should make it clear that the explanation string + comes from a third party. For example, it can prepend the macro + string "%{o} explains: " to the explanation. Implementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable @@ -1080,24 +1078,24 @@ amplification. Therefore the processing limits need to be quite small. - SPF implementations MUST limit the number of mechanisms that do DNS - lookups to at most 10. For example, the "mx" and "include" - mechanisms requires DNS lookups, so will count against this limit, - while the "ip4" mechanism does not require any DNS lookups. - - When evaluating the "mx" mechanism, there MUST be a limit of no more - than 10 MXes looked up and checked for matching IP addresses. - - When evaluating the "ptr" mechanism or the %{p} macro, there MUST be - a limit of at most 10 PTR DNS records looked up and checked for a - validated domain name. + SPF implementations MUST limit the number of mechanism that do DNS + lookups to at most 10, if this number is exceeded, a PermError MUST + be returned. The mechanisms that count against this limit are + "include", "a", "mx", "ptr", "exists" and the "redirect" modifier. + The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and + therefore do not count against this limit. The "exp" modifier + requires a DNS lookup, but it is not counted as it is used only in + the case of errors. + + When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, + there MUST be a limit of no more than 10 MX or PTR RRs looked up and + checked. SPF implementation SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there may need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage, and DoS attacks. - Implementations must be prepared to handle records that are set up incorrectly or maliciously. @@ -1138,7 +1136,8 @@ information is intended for the recipient. (Information intended for the sender described in Section 6.2, Explanation.) - The header SHOULD be prepended to existing headers, above the + The Received-SPF header is a trace field (See [RFC2822] section + 3.6.7) and SHOULD be prepended to existing headers, above the Received: header that is generated by the SMTP receiver. It MUST appear above any other Received-SPF headers in the message. The header has the format: @@ -1148,15 +1147,16 @@ result = "Pass" / "Fail" / "TempError" / "SoftFail" / "Neutral" / "None" / "PermError" - key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] key-value-pair = name [CFWS] "=" ( dot-atom / quoted-string ) - dot-atom = ; unquoted word as per RFC2822 + dot-atom = ; unquoted word as per [RFC2822] - quoted-string = ; quoted string as per RFC2822 + quoted-string = ; quoted string as per [RFC2822] - CFWS = ; comment or folding white space as per RFC2822 + CFWS = ; comment or folding white space as per [RFC2822] The should convey supporting information for the result, such as , and . @@ -1226,7 +1226,7 @@ domain-spec = macro-string domain-end domain-end = ( "." toplabel ) / macro-expand toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See RFC3696) + ; LDH rule (See [RFC3696]) alphanum = ALPHA / DIGIT macro-string = *( macro-expand / macro-literal ) explain-string = *( macro-string / SP ) @@ -1421,7 +1421,7 @@ It can be helpful to publish records that include a "tracking exists:" mechanism. By looking at the name server logs, an incompletely list may be generated. For example: - v=spf1 exists:CL.%{i}.FR.%{s}.HE.%{h}._spf.%{d} ?all" + v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 9.2 Mailing Lists @@ -1444,11 +1444,11 @@ Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the - near-universal practice of such services is to use the original - reverse-path of a message when re-injecting it for delivery to the - external mailbox. [RFC1123] and [RFC2821] describe this action as an - "alias" rather than a "mail list". This means the external mailbox's - MTA sees all such mail in a connection from a host of the forwarding + near-universal practice of such services is to use the original MAIL + FROM of a message when re-injecting it for delivery to the external + mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" + rather than a "mail list". This means the external mailbox's MTA + sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not in general pass authorization. @@ -1464,12 +1464,12 @@ domain's mailboxes. In such cases, white lists of generally recognized forwarding services could be employed. - Forwarding services can also solve the problem by using reverse-paths + Forwarding services can also solve the problem by using MAIL FROM that contain their own domain. This means that mail bounced from the external mailbox will have to be re-bounced by the forwarding service. Various schemes to do this exist though they vary widely in complexity and resource requirements on the part of the forwarding - service. Several polular MTAs can change "alias" semantics to + service. Several popular MTAs can change "alias" semantics to "mailing list" semantics by including an adding another alias with "owner-" added to the beginning of the alias name. (e.g. an alias of "friends: george@example.com, fred@example.org" would need another @@ -1479,12 +1479,12 @@ Entities that offer mail services to other domains such as sending of bulk mail will may have to alter their mail in light of the - authorization check in this document. If the reverse-path used for - such e-mail uses the domain of the mail service provider, then the + authorization check in this document. If the MAIL FROM used for such + e-mail uses the domain of the mail service provider, then the provider needs only to ensure that their sending host is authorized by their own SPF record, if any. - If the reverse-path does not use the mail service provider's domain, + If the MAIL FROM does not use the mail service provider's domain, then extra care must be taken. The SPF record format has several options for authorizing the sending MTAs of another domain (the service provider's) @@ -1548,10 +1548,10 @@ machines would then present a DNS load on the target as they fetched the relevant DNS references. While implementations of check_host() need to limit the number of - DNS lookups, malicious domains could publish records that exercise - or exceed these limits in an attempt to waste computation effort - at their targets when they send them mail. Malicous domains could - also design SPF records that cause excessive memory or CPU usage. + DNS lookups, malicious domains could publish records exceed these + limits in an attempt to waste computation effort at their targets + when they send them mail. Malicious domains could also design SPF + records that cause excessive memory or CPU usage. Malicious parties could send large volume mail purporting to come from the intended target to a wide variety of legitimate mail hosts. These legitimate machines would then present a DNS load on @@ -1571,10 +1571,10 @@ strings in their SPF records. SPF uses information supplied by third parties, such as the HELO - domain name, the return-path and SPF records. This information is - then sent to the receiver in the Received-SPF: mail headers and - possibly returned to the client MTA in the form of an SMTP rejection - message. This information must be checked for invalid characters and + domain name, the MAIL FROM and SPF records. This information is then + sent to the receiver in the Received-SPF: mail headers and possibly + returned to the client MTA in the form of an SMTP rejection message. + This information must be checked for invalid characters and excessively long lines. 11. IANA Considerations @@ -1735,7 +1735,7 @@ domain-spec = macro-string domain-end domain-end = ( "." toplabel ) / macro-expand toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum - ; LDH rule (See RFC3696) + ; LDH rule (See [RFC3696]) alphanum = ALPHA / DIGIT macro-string = *( macro-expand / macro-literal ) explain-string = *( macro-string / SP ) @@ -1756,15 +1756,16 @@ result = "Pass" / "Fail" / "TempError" / "SoftFail" / "Neutral" / "None" / "PermError" - key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] key-value-pair = name [CFWS] "=" ( dot-atom / quoted-string ) - dot-atom = ; unquoted word as per RFC2822 + dot-atom = ; unquoted word as per [RFC2822] - quoted-string = ; quoted string as per RFC2822 + quoted-string = ; quoted string as per [RFC2822] - CFWS = ; comment or folding white space as per RFC2822 + CFWS = ; comment or folding white space as per [RFC2822] Appendix B. Extended Examples These examples are based on the following DNS setup: @@ -1943,5 +1944,5 @@ -Wong & Schlitt Expires June 27, 2005 [Page 48] +Wong & Schlitt Expires June 30, 2005 [Page 48]