idnits 2.17.1 draft-newton-maawg-spf-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 654. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 670), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2005) is 6945 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-lyon-senderid-core-00 == Outdated reference: A later version (-01) exists of draft-lyon-senderid-pra-00 == Outdated reference: A later version (-01) exists of draft-katz-submitter-00 == Outdated reference: A later version (-02) exists of draft-schlitt-spf-classic-00 == Outdated reference: A later version (-20) exists of draft-kucherawy-sender-auth-header-01 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton, Editor 3 Internet-Draft Message Anti-Abuse Working Group 4 Expires: October 20, 2005 April 21, 2005 6 Considerations for the use of the Sender Policy Framework 7 draft-newton-maawg-spf-considerations-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 20, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document describes issues and considerations when deploying the 41 Sender Policy Framework for the purposes of authenticating sending 42 domains with Internet email. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. SPF Background . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2.1 SPF Variants . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.1.1 Original SPF . . . . . . . . . . . . . . . . . . . . . 4 50 2.1.2 SPF Classic . . . . . . . . . . . . . . . . . . . . . 4 51 2.1.3 Sender ID . . . . . . . . . . . . . . . . . . . . . . 5 52 2.2 SPF Email Identities . . . . . . . . . . . . . . . . . . . 5 53 3. Identity Usage . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1 User Agents . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.3 Publisher's Intent . . . . . . . . . . . . . . . . . . . . 9 57 4. Multihoming of Mail Servers . . . . . . . . . . . . . . . . . 10 58 5. Usage of Headers for Check Status . . . . . . . . . . . . . . 11 59 6. DNS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 6.1 Mechansim Lookups . . . . . . . . . . . . . . . . . . . . 12 61 6.2 Zone Cut Issues . . . . . . . . . . . . . . . . . . . . . 12 62 6.3 Publication Procedures . . . . . . . . . . . . . . . . . . 13 63 6.3.1 Initial Publication . . . . . . . . . . . . . . . . . 13 64 6.3.2 Continued Publication . . . . . . . . . . . . . . . . 14 65 6.3.3 Use of the 'include' Mechanism . . . . . . . . . . . . 14 66 7. SPF Results . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 7.1 Administrative Utility . . . . . . . . . . . . . . . . . . 15 68 7.2 Use of Other Authentication Schemes . . . . . . . . . . . 15 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 9. Informative References . . . . . . . . . . . . . . . . . . . . 16 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . . 18 74 1. Introduction 76 The Sender Policy Framework (SPF) describes a DNS TXT resource record 77 to be used for authenticating the sending domain in the transmission 78 of Internet email (from one domain to another). SPF sits atop the 79 current email standards and is intended to disallow certain abusive 80 use cases of email. To accomplish this task, SPF places new 81 restrictions upon the email transmission from one domain to another. 83 This document describes issues and considerations regarding the use 84 of SPF that network and mail administrators may have no need to 85 consider otherwise. 87 These considerations are collected from the membership of the Message 88 Anti-Abuse Working Group. This document is intended to be for 89 informational purposes only. 91 2. SPF Background 93 The Sender Policy Framework is an email sender authentication scheme 94 that defines a syntax of a DNS TXT resource record. Through various 95 devices, this DNS TXT resource record lists allowed, disallowed, 96 neutral, and unknown source IP addresses. SPF relies upon the 97 difficulty of spoofing IP addresses with SMTP connections as the 98 basis for its authentication mechanism; senders are matched to the 99 source IP address of an SMTP connection via various identities. 100 Authorization to use the IP address by a sender is given in the DNS 101 TXT resource record. 103 2.1 SPF Variants 105 SPF describes itself as a framework, and as such there are many 106 variants of SPF. When deploying SPF, it is crucial to understand 107 which variants of SPF are being advertised as a sender of email and 108 the intentions of the sending SPF domain as a receiver of email. 109 Otherwise, it is likely that non-forged email may not be delivered 110 while forged email may be delivered. The following is a partial list 111 of SPF variants. 113 2.1.1 Original SPF 115 The specification in [1] (and its immediate predessor) was the first 116 specification considered to contain the basis of SPF. This 117 specification uses the email address presented by a sending server in 118 the SMTP MAIL FROM command or the fully qualified domain name 119 presented by a sending server in the SMTP HELO or EHLO command if no 120 email address is given in the MAIL FROM command. It should be noted 121 that this specification is no longer being advanced through 122 standardization processes by its authors. However, it is important 123 because many implementations cite it as the specification to which 124 they comply. 126 2.1.2 SPF Classic 128 There exists some ambiguity regarding the term "Classic SPF" or "SPF 129 Classic" as it was originally used to distinquish original SPF 130 (Section 2.1.1) from a variant of SPF known as Sender ID (Section 131 2.1.3). However, the more recent use of the term "SPF Classic" 132 refers to [5]. This specification differs from original SPF (Section 133 2.1.1) in the following ways: 134 o DNS lookups that fail to find TXT records will use an algorithm to 135 find DNS zone cuts and requery the DNS further up the tree. 136 o Checking of the fully qualified domain name given in an SMTP HELO 137 or EHLO command is optional even if an address is given in the 138 SMTP MAIL FROM command. 140 2.1.3 Sender ID 142 This variant of SPF is defined by [2] , [3] and [4]. It differs from 143 the above specifications in the following ways: 144 o The email identity used is determined by the publisher of the SPF 145 record. 146 o It defines a new email identity that is selected from the headers 147 of the email message using an algorithm called the Purported 148 Responsible Address (PRA). 149 o The syntax of the record can either be the SPF syntax specified by 150 original SPF (Section 2.1.1) (identified by the "v=spf1" version 151 identifier) or a slightly different SPF syntax (identified by the 152 "spf2.0" identifier). 153 o The email address selected by the PRA algorithm can be transmitted 154 by the sender to the receiver in the SMTP MAIL FROM command using 155 an ESMTP extension called SUBMITTER. 157 It should be noted that some proponents of SPF Classic (Section 158 2.1.2) do not consider Sender ID (Section 2.1.3) to be a legitimate 159 variant of SPF. This may cause confusion when determining the 160 compliance of software. 162 2.2 SPF Email Identities 164 All SPF variants use a domain name to lookup an SPF DNS TXT resource 165 record. These domain names are taken from different parts of the 166 SMTP transaction as email is transmitted from one mail server to 167 another. 169 The following is an example of an SMTP transaction. The first two 170 columns are provided for illustrative reasons and are not part of the 171 SMTP transaction. The first column is a line number, and the second 172 column contains an "S:" or "C:" to show who said what in the SMTP 173 conversation. Lines with an "S:" (for server) indicate the mail 174 server receiving the email, and lines with a "C:" (for client) 175 indicate the mail server sending the email. 177 1 S: 220 milo.example.org SuperDuper Mail Server v1.5 178 2 C: HELO felix.example.net 179 3 S: 250 milo.example.org Ok. 180 4 C: MAIL FROM: 181 5 S: 250 Ok. 182 6 C: RCPT TO: 183 7 S: 250 Ok. 184 8 C: DATA 185 9 S: 354 Ok. 186 10 C: Subject: This is an example email 187 11 C: From: Bob 188 12 C: To: Alice 189 13 C: 190 14 C: This is the body of the email message. 191 15 C: It is two lines long. 192 16 C: . 193 17 S: 250 Ok. 42548455.00000B74 195 Figure 1: An Example SMTP Transaction 197 The domain name given on line 2 (felix.example.net) of the SMTP 198 transaction is the HELO identity, and it is suppose to be the fully 199 qualified domain name of the mail server sending the email. Original 200 SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) specify that an 201 SPF DNS TXT resource record by that name is to be consulted to 202 determine if the source IP address of the SMTP connection is 203 authorized to act on behalf of the HELO identity. 205 The domain name of the email address in Line 4 (example.com) is the 206 MAIL FROM identity used by original SPF (Section 2.1.1) and SPF 207 Classic (Section 2.1.2) An SPF DNS TXT resource record by that name 208 is to be consulted to determine if the source IP address of the SMTP 209 connection is authorized to act on behalf of the MAIL FROM identity. 211 Lines 10 through 12 are the headers of the email message. The PRA 212 algorithm selects an identity from these headers. In this example, 213 the PRA specifies the email address in Line 11 and the use of the 214 domain name in that email address (example.net) as the Purported 215 Responsible Domain (PRD). An SPF DNS TXT resource record by that 216 name is to be consulted to determine if the source IP address of the 217 SMTP connection is authorized to act on behalf of the PRA identity. 218 See [3]. 220 3. Identity Usage 222 Proper deployment of SPF requires an understanding of the proper 223 usages of identities used in the tranmission of email from one mail 224 server to another. Improper deployment of SPF may result in 225 inappropriately high confidence of protection against certain classes 226 of mail forgery or may result in the loss of certain types of message 227 transfers or both. 229 3.1 User Agents 231 Given the example in Figure 1, the following is typical of what will 232 be seen by an end-user with a mail client. 234 Subject: This is an example email 235 From: Bob 236 To: Alice 237 Date: Wed, 06 Apr 2005 20:52:11 -0400 239 This is the body of the email message. 240 It is two lines long. 242 Figure 2: User Agent Example 244 The identity used with the SMTP MAIL FROM command is bob@example.com 245 but the end-user sees the message as being from bob@example.net (note 246 the difference between example.com and example.net). Therefore, 247 SPF's use of the identity in the SMTP MAIL FROM command will not stop 248 users from seeing a forged identity. 250 Since the PRA is the only identity verified that is part of the email 251 message, verification of the PRA is the only part of SPF that 252 attempts to insure that end-users see authorized email addresses. 253 However, the PRA algorithm does not always select an identity that is 254 shown to end users by mail clients. Therefore, SPF is not guaranteed 255 to prevent end users from seeing forged identities. 257 Additionally, the PRA identity only focuses on the address 258 specification part of a header in an email message. It does not 259 validate against the display name part of a header in an email 260 message. Using the example above: 261 From: Bob 262 The display name portion in this header is "Bob" and the address 263 specification portion in this header is ". Many 264 email clients show only the display name portion of the header. 265 Therefore, it is possible to have a positive validation against the 266 PRA without having a positive validation against the information 267 given to the user. For example: 269 From: Bob Smurd 270 would be seen as: 271 From: Bob Smurd 272 yet yield a positive result. 274 3.2 Forwarding 276 Forwarding of email from one mail server to another may prevent 277 proper delivery of messages using the MAIL FROM and PRA identities. 278 Consider the following email forwarding scenario. 280 +----------------------+ 281 | | 282 | felix.example.net | 283 | | 284 +----------------------+ 285 | 286 (1) | MAIL FROM: 287 | 288 V 289 +----------------------+ +----------------------+ 290 | | (2) | | 291 | milo.example.org |------------------------->| calvin.example.com | 292 | | MAIL FROM: | | 293 +----------------------+ +----------------------+ 295 Figure 3: Mail Path Example 297 In this scenario, MAIL FROM checking from felix.example.net to 298 milo.example.org would produce valid results. However, a MAIL FROM 299 check from milo.example.org to calvin.example.com would produce 300 invalid results as george@example.net would cause the SPF record for 301 example.net to be consulted even though the SMTP connection is 302 originating from example.org. 304 While the intent of PRA algorithm is to properly detect the last 305 forwarder of an email, it relies upon behaviors not found in all mail 306 servers and programs. Therefore, it is quite possible that PRA 307 checking would also have the same results as MAIL FROM checking. 309 For mail services with a small and fixed number of known forwarding 310 relationships, this problem may be overcome using the include 311 mechanism. In this case, "include:example.org" placed in the SPF 312 record of example.net would produce proper results. However, there 313 are some drawbacks to using the "include" mechanism (see Section 314 6.3.3). 316 However, it is not always possible to know forwarding relationships 317 or to produce SPF include mechanisms for all known forwarding 318 relationships. To overcome this problem, it is advisable to do the 319 following: 320 o For MAIL FROM checking, rewriting the MAIL FROM identity to point 321 to the domain of the sending server will cause the proper SPF 322 records to be consulted. In the example above, if the server 323 milo.example.org used a MAIL FROM identity of george@example.org 324 instead of george@example.net, then the records pertaining to 325 milo.example.org would be consulted. It is important to note that 326 all upstream notifications are to be directed to the MAIL FROM 327 identity, therefore MAIL FROM rewriting will require 328 milo.example.org to properly handle any bounces of the message it 329 is sending. 330 o To use PRA checking, a forwarder should insert the proper PRA 331 compatible header or headers into the message. See [3]. 333 Note that the HELO identity will not cause false positives with 334 forwarding. As noted above, the MAIL FROM identity is used as the 335 address to which bounces should be sent in case of errors, and many 336 forwarding processes legitimately do not rewrite MAIL FROM for this 337 reason. However, such a reason does not exist for the HELO identity 338 and there are no legitimate reasons for a mail server to use the 339 identity of another. 341 3.3 Publisher's Intent 343 As noted in Section 3.2, to prevent the consultation of inappropriate 344 SPF records, senders may adopt strategies of rewriting MAIL FROM or 345 inserting PRA compliant headers or both. The strategy picked should 346 be reflected in the SPF record, and therefore receivers of email 347 should follow the intent of the published SPF record regarding which 348 identity is to be checked. 350 With the given SPF variants (Section 2.1), there are three types of 351 SPF records that give scope to the identifier to be checked. 352 1. v=spf1 353 2. spf2.0/mfrom 354 3. spf2.0/pra 356 For the purposes of backwards compatibility, Sender ID (Section 357 2.1.3) interprets the first record to be equivalent to "spf2.0/ 358 mfrom,pra", which is to say that both MAIL FROM and PRA checks are to 359 occur. To avoid confusion, senders should explicitly publish spf2.0/ 360 mfrom records. If a sender has not taken prepatory steps to 361 accomodate PRA checking, a non-committal SPF record of "spf2.0/mfrom 362 ?all" will signal that all PRA checking against this domain will have 363 unknown results. 365 4. Multihoming of Mail Servers 367 Because SPF uses IP addresses as the key to authentication, special 368 care must be given with mail servers that have more than one IP 369 address, especially if they are not all listed in the SPF record. 370 Here is one such common scenario: a separate publicly addressable 371 network interface is given to a server for the sole purpose of remote 372 management. In these cases, changes to the routing fabric of the 373 Internet may cause mail service to switch away from the intended 374 network interface to one not intended to service SMTP traffic. 376 To avoid this problem, mail servers should be explicitly bound to the 377 network interfaces published in the SPF records. 379 5. Usage of Headers for Check Status 381 Original SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) defines 382 the Received-SPF trace header to be added to email messages that have 383 undergone SPF checking. Because these are trace headers, multiple 384 sets of Received-SPF headers may appear in a single email, each set 385 being added by a previous mail hop. Without proper care, simple 386 filtering (such as with an unscoped regular expression) may have 387 unexpected results. And like Recieved headers, Received-SPF headers 388 are an easy target for forgery. Mail filters and clients should not 389 use their contents to determine the disposition of email messages. 391 Because SPF is not the only type of email authentication in use, mail 392 servers should use the Authentication-Results header (See [6]). This 393 header has the advantage of working with multiple authentication 394 schemes and is intended to allow a mail server to communicate the 395 status of an authentication check to mail filters and mail clients. 397 6. DNS Usage 399 6.1 Mechansim Lookups 401 Network administrators need to be conscious of the fact that SPF 402 records can create more load on their DNS servers than just that of 403 querying the SPF records. 405 SPF Classic (Section 2.1.2), which has the most strict upper bounds 406 on DNS lookups, allows for 10 SPF mechanisms that may trigger 407 subsequent DNS lookups. In turn each mechanism may require more than 408 one DNS lookup to fulfill the requirements of the mechanism. The 409 theoretical maximum to conduct an SPF check is 111 DNS lookups. For 410 instance, the appearance of one "mx" mechanism in an SPF record could 411 result in 10 DNS lookups in the process of following the targets of 412 the queried DNS MX records. 414 To avoid lengthy processing times and excess load on DNS, the use of 415 the "ip4" and "ip6" mechanisms is recommended. Use of the "include", 416 "a", "mx", "ptr", "exists" mechanisms, the "redirect" modifier, and 417 the %{p} macro should carefully consider the total number of DNS 418 lookups incorporated into an SPF record. 420 Additionally, SPF Classic (Section 2.1.2) places an upper bound of 20 421 seconds on the duration needed to process the SPF check. SPF checks 422 that take longer than 20 seconds or require more than 101 DNS lookups 423 will result in message delivery rejection. Use of an SPF profiler is 424 recommended to determine the number of DNS lookups and the potential 425 check duration. 427 These restrictions also need to be taken into consideration when 428 performing SPF checks. While 111 DNS lookups with a 20 second 429 timeout is tolerable for infrequent email reception, receivers and 430 senders may need to reach bilateral transaction agreements that 431 bypass SPF in cases where SPF records cannot be formulated with more 432 tolerable values. 434 6.2 Zone Cut Issues 436 SPF Classic (Section 2.1.2) introduces an algorithm to find the DNS 437 zone cut of administrative domains. For example, if an SPF check is 438 conducted against a non-existent domain name of prattle.example.net, 439 the SPF record at example.net will be found. This algorithm is an 440 attempt to overcome undesirable behaviour in DNS wildcards (which are 441 not recommended for use by SPF Classic). 443 This algorithm has implications with regards to the confidence 444 attached to HELO checking. Should a misconfiguration occur, a HELO 445 check may inadvertently consult the wrong SPF record. Because SPF 446 records related to HELO can be stricter than SPF records relating to 447 MAIL FROM and PRA, this would result in the loss of security. 449 Synthesized DNS records, whether provided by the standard DNS 450 wildcard device or other means, are an administrative issue. Other 451 methods can be employed to get the proper DNS behaviour by the 452 publisher of an SPF record. 454 Therefore, disabling the DNS zone cut algorithm in an SPF processor 455 is recommended. 457 6.3 Publication Procedures 459 6.3.1 Initial Publication 461 Because there are many unknowns in the paths email messages may take 462 through the Internet, many publishers of SPF records make 463 non-committal assertions regarding their message delivery (usually by 464 ending an SPF record with "~all"). To a receiver, a non-committal 465 assertion may not have any affect on judging the disposition of 466 email, and issues with regard to SPF processing may not be noticed 467 until a more aggressive SPF record is published. 469 SPF publishers should follow these steps on initial publication of an 470 SPF record: 471 1. Initially publish the SPF record with a neutral assertion (i.e. 472 end it in "?all"). 473 2. Once there is a high degree of confidence that the SPF record 474 accurately reflects message delivery, lower the TTL on the SPF 475 record to a value that allows the record to be quickly propagated 476 within the DNS should it need to be changed rapidly. 477 3. Change the SPF record so that it makes the more aggressive 478 assertion of softfail (i.e. end it in "~all"). 479 4. If no adverse problems are found after a sufficient period of 480 time, change the SPF record so that it makes the most aggressive 481 assertion (i.e. end it in "-all"). 482 5. Once there is a high degree of confidence that the SPF record is 483 not causing adverse mail delivery problems, increase the TTL on 484 the SPF record to a more reasonable value. 486 It should be noted that decreasing the TTL on the SPF record will 487 result in higher DNS query load. 489 Due to unknowable forwarding relationships with the Internet email 490 infrastructure, it may not be possible for all domains to publish SPF 491 records with an agressive assertion. Use of these publication 492 procedures may even lead to the conclusion that email should not be 493 subjected to SPF checks (see Section 7.2). 495 6.3.2 Continued Publication 497 Once an SPF record has been established, a publisher should put in 498 place proper procedures for the maintenance and continued publication 499 of the SPF record. 501 Over time, it is highly likely that some changes will need to be made 502 to the contents of the SPF record. Because the SPF syntax is 503 seemingly simple, administrators may be tempted to modify the record 504 without full knowledge of the SPF syntax. Failure to correctly 505 modify an SPF record may result in message delivery rejections. To 506 avoid this problem, any SPF record should be run against an SPF 507 syntax checker before the new record is published. 509 Additionally, it might be useful to store SPF records in a version 510 control system. This allows quick reversion back to a previous 511 record should a problem be discovered. It will also help in the 512 analysis of mail problems by allowing past records to be studied. 514 6.3.3 Use of the 'include' Mechanism 516 As stated in Section 2.1, many implementations of SPF adhere to 517 original SPF (Section 2.1.1) even though that current branch of SPF 518 is described by SPF Classic (Section 2.1.2). Unfortunately, both use 519 the same "v=spf1" record identifier, so there exists no easy method 520 to differentiante the two programmatically. 522 Both versions differ substantially in their error case for the 523 "include" mechanism. Under original SPF (Section 2.1.1), if an 524 "include" mechanism references a non-existent SPF record, SPF 525 processing against all email for the domain making the reference 526 would cease (essentially resulting in a state equivalent to having no 527 SPF record for the domain making the reference). 529 Under SPF Classic (Section 2.1.2), if an "include" mechansim 530 references a non-existent SPF record, SPF processing against all 531 email for the domain making the reference would result in a PermError 532 state and consequent permanent SMTP rejection of the email. 534 For SPF publishers defering to the SPF records of other domains (a 535 common scenario for commercial enterprises that out-source their 536 transaction email operations), the existance of the target SPF record 537 should be verified before the use of an associated "include" 538 mechanism. Additionally, SPF publishers should seek assurance of 539 continued SPF publication from the SPF publishers to which they make 540 a reference. 542 7. SPF Results 544 7.1 Administrative Utility 546 SPF recognizes five states with which a publisher can declare their 547 intentional use of SPF: none, pass, fail, neutral, and softfail 548 (PermError and TempError as defined by SPF Classic (Section 2.1.2) 549 are error states and not intential usage states). The differences 550 between none, neutral, and softfail may not be programattically 551 meaningful ([5] specifies neutral to be programmatically equivalent 552 to none). 554 However, these differences can have meaning to administrators 555 attempting to resolve problems manually. The result of neutral 556 differs from the result of none in that it does indicate that the SPF 557 publisher is aware of SPF checking. The result of none indicates 558 that the SPF publisher is not aware of SPF checking. 560 7.2 Use of Other Authentication Schemes 562 There do exist scenarios where mail administrators do not wish to 563 subject their email practices to SPF checks but do wish to offer an 564 affirmative acknowledgment of the practice of using SPF. Such a 565 scenario would be email sending domains that wish to rely on other 566 authentication schemes, such as cryptographic-based signature 567 schemes. 569 This is easily accomplished with the exclusive use of the "all" 570 mechanism using the pass result. Such as: 571 v=spf1 +all 572 or 573 spf2.0/mfrom,pra +all 575 8. Security Considerations 577 SPF depends on the integrity of various parts of Internet 578 infrastructure and has other security considerations that should be 579 understand before the deployment of SPF. Sender ID (Section 2.1.3) 580 clearly enumerates these isses which have implications for all 581 variants of SPF. 583 Briefly, these issues are: 584 1. SPF is only as secure as DNS. Should the integrity of DNS be 585 compromised, then SPF becomes much less effective. 586 2. SPF relies on the difficult nature of IP address spoofing within 587 TCP (the transport used by SMTP). 588 3. SPF does not always prevent users from seeing forged sender 589 information even when SPF checks return positive results (see 590 Section 3.1). 591 4. SPF relies upon the linkage between an SPF publisher and their 592 assocation to IP address space. Attacks against the routing 593 fabric of the Internet can break this linkage rendering SPF 594 ineffective. 595 5. SPF may be used to perpetrate "bounce attacks". While original 596 SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) are less 597 likely to be used for such an attack, they are not immune to it 598 given their described usage of SoftFail. 600 9 Informative References 602 [1] Lentczner, M., "Sender Policy Framework (SPF) A Convention to 603 Describe Hosts Authorized to Send SMTP Traffic", 604 draft-mengwong-spf-01 (work in progress), May 2004. 606 [2] Lyon, J., "Sender ID: Authenticating E-Mail", 607 draft-lyon-senderid-core-00 (work in progress), November 2004. 609 [3] Lyon, J., "Purported Responsible Address in E-Mail Messages", 610 draft-lyon-senderid-pra-00 (work in progress), November 2004. 612 [4] Allman, E., "SMTP Service Extension for Indicating the 613 Responsible Submitter of an E-mail Message", 614 draft-katz-submitter-00 (work in progress), November 2004. 616 [5] Wong, M., "Sender Policy Framework: Authorizing Use of Domains 617 in E-MAIL", draft-schlitt-spf-classic-00 (work in progress), 618 January 2005. 620 [6] Kucherawy, M., "Message Header for Indicating Sender 621 Authentication Status", draft-kucherawy-sender-auth-header-01 622 (work in progress), March 2005. 624 Author's Address 626 Andrew L. Newton 627 Message Anti-Abuse Working Group 629 EMail: anewton@verisignlabs.com; andy@hxr.us 630 URI: http://www.maawg.org/ 632 Intellectual Property Statement 634 The IETF takes no position regarding the validity or scope of any 635 Intellectual Property Rights or other rights that might be claimed to 636 pertain to the implementation or use of the technology described in 637 this document or the extent to which any license under such rights 638 might or might not be available; nor does it represent that it has 639 made any independent effort to identify any such rights. Information 640 on the procedures with respect to rights in RFC documents can be 641 found in BCP 78 and BCP 79. 643 Copies of IPR disclosures made to the IETF Secretariat and any 644 assurances of licenses to be made available, or the result of an 645 attempt made to obtain a general license or permission for the use of 646 such proprietary rights by implementers or users of this 647 specification can be obtained from the IETF on-line IPR repository at 648 http://www.ietf.org/ipr. 650 The IETF invites any interested party to bring to its attention any 651 copyrights, patents or patent applications, or other proprietary 652 rights that may cover technology that may be required to implement 653 this standard. Please address the information to the IETF at 654 ietf-ipr@ietf.org. 656 Disclaimer of Validity 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Copyright Statement 668 Copyright (C) The Internet Society (2005). This document is subject 669 to the rights, licenses and restrictions contained in BCP 78, and 670 except as set forth therein, the authors retain all their rights. 672 Acknowledgment 674 Funding for the RFC Editor function is currently provided by the 675 Internet Society.