idnits 2.17.1 draft-ietf-marid-core-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 24 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (June 2004) is 7248 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) == Missing Reference: 'RFC3513' is mentioned on line 575, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Missing Reference: 'RFC2396' is mentioned on line 604, but not defined ** Obsolete undefined reference: RFC 2396 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSchema' == Outdated reference: A later version (-06) exists of draft-delany-domainkeys-base-00 == Outdated reference: A later version (-04) exists of draft-stumpf-dns-mtamark-02 -- Obsolete informational reference (is this intentional?): RFC 2633 (ref. 'SMIME') (Obsoleted by RFC 3851) == Outdated reference: A later version (-03) exists of draft-ietf-marid-submitter-00 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID Working Group J. Lyon 2 Internet Draft Microsoft Corp 3 Document: draft-ietf-marid-core-01.txt M. Wong 4 pobox.com 5 Expires: December 2004 June 2004 7 MTA Authentication Records in DNS 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Internet mail suffers from the fact that much unwanted mail is sent 32 using spoofed addresses �- "spoofed" in this case means the address 33 is used without the permission of the domain owner. This document 34 describes the following: mechanisms by which a domain owner can 35 publish its set of outgoing MTAs, mechanisms by which SMTP servers 36 can determine what email address is allegedly responsible for most 37 proximately introducing a message into the Internet mail system, and 38 whether that introduction is authorized by the owner of the domain 39 contained in that email address. 41 The specification is carefully tailored to ensure that the 42 overwhelming majority of legitimate emailers, remailers and mailing 43 list operators are already compliant. 45 Table of Contents 47 1. Introduction................................................. 3 48 2. Problem Statement............................................ 3 49 2.1 Positive Problem Statement............................... 3 50 2.2 Negative Problem Statement............................... 4 51 3. Decision Model............................................... 5 52 4. Determining the Purported Responsible Address................ 6 53 5. E-mail Policy Document....................................... 7 54 5.1 Elements of the Infoset.................................. 8 55 5.2 Macro Expansion..........................................12 56 5.3 Determining the E-mail Policy Document for a Domain .....14 57 5.4 Recursion Limitations....................................18 58 6. Actions Based on the Decision................................18 59 6.1 pass.....................................................18 60 6.2 fail.....................................................18 61 6.3 softFail.................................................18 62 6.4 neutral..................................................19 63 6.5 transientError...........................................19 64 6.6 hardError................................................19 65 6.7 none.....................................................19 66 7. Security Considerations......................................19 67 7.1 DNS Attacks..............................................20 68 7.2 TCP Attacks..............................................20 69 7.3 Forged Resent-From Attacks...............................20 70 8. Extensibility Considerations.................................20 71 9. Applicability Statement......................................21 72 9.1 Simple E-mailers.........................................21 73 9.2 E-mail Forwarders........................................21 74 9.3 Mailing List Servers ....................................22 75 9.4 Third-Party Mailers......................................22 76 9.5 MTA Implementers.........................................22 77 9.6 MUA Implementers.........................................22 78 10. IANA Considerations.........................................23 79 11. Acknowledgements............................................23 80 12. References..................................................23 81 12.1 Normative References....................................23 82 12.2 Informative References..................................23 83 13. Authors' Addresses..........................................24 84 14. Full Copyright Statement....................................24 85 Appendix A: XML Schema for urn:ietf:params:xml:schema:marid-1..26 87 Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 << Text contained in double angle brackets describes actions that are 94 yet to be taken and decisions that are yet to be made. No such text 95 should survive in the final version of this draft. >> 97 1. Introduction 99 Today, a huge majority of unwanted email contains headers that lie 100 about the origin of the mail. This is true of most spam and 101 substantially all of the virus email that is sent. 103 This document describes a mechanism such that receiving MTAs, MDAs 104 and/or MUAs can recognize mail in the above category and take 105 appropriate action. For example, an MTA might refuse to accept a 106 message, an MDA might discard a message rather than placing it into a 107 mailbox, and an MUA might render that message in some distinctive 108 fashion. 110 In order to avoid further fragmentation of the Internet email system, 111 it is necessary that the Internet community as a whole come to a 112 consensus as to what mail senders should do to make their mail appear 113 non-spoofed, and how mail receivers should determine whether mail is 114 spoofed. On the other hand, it is not necessary to reach a consensus 115 regarding the actions that various parties take once a message has 116 been determined to be spoofed. This can be done unilaterally -- one 117 agent might decide to discard a spoofed message while another decides 118 to add a disclaimer. 120 2. Problem Statement 122 2.1 Positive Problem Statement 124 Briefly stated, the mechanisms of this document allow one to answer 125 the following question: 127 When a message is transferred via SMTP between two UNRELATED parties, 128 does the SMTP client host have permission to send mail on behalf of 129 the mailbox that allegedly caused the most recent introduction of the 130 message into the mail delivery system? 132 As seen from the question, this mechanism applies to unrelated 133 parties: it is useful at the point where a message passes across the 134 Internet from one organization to another. It is beyond the scope of 135 this document to describe authentication mechanisms that can be 136 deployed within an organization. 138 The mechanism of this document also seeks to authenticate the mailbox 139 associated with the MOST RECENT introduction of a message into the 140 mail delivery system. In simple cases, this is who the mail is from. 141 However, in the case of a third-party mailer, a forwarder or a 142 mailing list server, the address being authenticated is that of the 143 third party, the forwarder or the mailing list. 145 This document provides means to authenticate the DOMAIN of the 146 appropriate email address; it makes no attempt to authenticate the 147 local-part. A domain owner gets to determine which SMTP clients 148 speak on behalf of addresses within the domain; a responsible domain 149 owner should not authorize SMTP clients that will lie about local 150 parts. 152 In the long run, once the domain of the sender is authenticated, it 153 will be possible to use that domain as part of a mechanism to 154 determine the likelihood that a given message is spam, using, for 155 example, reputation and accreditation services. (These services are 156 not the subject of the present mechanism, but it should enable them.) 158 2.2 Negative Problem Statement 160 This section describes alternate questions, which this document makes 161 no attempt to solve. 163 Is the host at a particular IP address authorized to act as an SMTP 164 client? [MTAMARK] attempts to answer this question using a reverse 165 DNS lookup. It suffers from the fact that reverse DNS lookups are 166 poorly implemented in major fractions of the IP address space, from 167 the fact that many ISPs refuse to reverse-delegate to small domains, 168 and from the fact that it's all or nothing: authority to act as an 169 SMTP client conveys authority to send absolutely any email, 170 legitimate or otherwise. 172 Is an SMTP client authorized to use a particular domain name in its 173 SMTP EHLO command? [CSV] attempts to answer this question. It 174 suffers from the fact that the EHLO name has a tenuous relationship, 175 at best, with the contents of any mail message. 177 Is an SMTP client authorized to use a particular email address in an 178 SMTP "MAIL FROM:" command? [RMX] and [SPF] attempt to answer this 179 question. These suffer from the fact that the MAIL FROM address 180 really describes where to send NDRs to, and in many third-party and 181 forwarder situations this address is unrelated to the domain that is 182 resending the message. 184 Was a message really authored by who it claims to be authored by? 185 [SMIME] and [DK] attempt to answer the question of original 186 authorship. While this is a useful question to answer, these 187 approaches suffer from severe deployment issues. 189 3. Decision Model 191 The essence of this specification is: 193 Given an email message, and given an IP address from which it has 194 been (or will be) received, is the SMTP client at that host address 195 authorized to send that email message? 197 There are four steps to answering this question: 199 (1) From the headers of the email message, extract the "purported 200 responsible address". This is the mailbox that the message 201 claims is responsible for the most recent introduction of the 202 message into the delivery system. This step is described in 203 detail in section 4 below. A separate specification, 204 [Submitter], describes an SMTP extension that allows an SMTP 205 server to perform this check at the time of the SMTP MAIL 206 command instead of the SMTP DATA command. 208 (2) Extract the domain part of the purported responsible address. 209 Call this the "purported responsible domain". 211 (3) Find the E-mail Policy Document for the purported responsible 212 domain. Section 5.1 below describes the semantics of an E-mail 213 Policy Document. Section 5.2 below describes how to find the 214 document for a domain. The E-mail Policy Document contains a 215 description of a "client authorization function". This function 216 that takes four arguments and returns a seven-valued result. 217 The arguments are: 218 a. The local-part of an email address. 219 b. A domain name, called the "original domain". 220 c. A domain name, called the "current domain". 221 d. An IP address (either IPv4 or IPv6). 222 The result of the function is one of the seven values "pass", 223 "fail", "softFail", "neutral", "transientError", "hardError" or 224 "none". 226 (4) Execute the function, passing: 227 the local-part of the Purported Responsible Address, 228 the Purported Responsible Domain (as "original domain"), 229 the Purported Responsible Domain (as "current domain"), 230 and the IP address from which the mail was received. 232 Section 6 describes how to interpret the result. 234 4. Determining the Purported Responsible Address 236 The purported responsible address (PRA) of a message is determined by 237 the following algorithm: 239 1. Locate the first non-empty Resent-Sender header in the message. 240 If no such header is found, proceed to step 2. If it is 241 preceded by a non-empty Resent-From header and one or more 242 Received or Return-Path headers occur after said Resent-From 243 header and before the Resent-Sender header, proceed to step 2. 244 If the Resent-Sender header is hopelessly malformed (e.g. it 245 appears to contain multiple mailboxes, or if the single mailbox 246 is hopelessly malformed) then exit, without returning a PRA. 247 Otherwise exit, returning the mailbox from the Resent-Sender 248 header as the PRA. 250 2. Locate the first non-empty Resent-From header in the message. 251 If no such header is found, proceed to step 3. If it is 252 hopelessly malformed (e.g. one or more mailboxes in the header 253 are hopelessly malformed) then exit without returning a PRA. If 254 it contains multiple mailboxes, then exit without returning a 255 PRA. Otherwise exit, returning the single mailbox from the 256 Resent-From header as the PRA. 258 3. Locate the first non-empty Delivered-To, X-Envelope-To or 259 Envelope-To header in the message. If no such header is 260 present, proceed to step 4. If it appears to contain multiple 261 mailboxes, then exit without returning a PRA. Otherwise, treat 262 the contents of the header as a mailbox, and exit returning this 263 mailbox as the PRA (unless the mailbox is hopelessly malformed, 264 in which case exit without returning a PRA). 266 [Note. This means that a non-standard header that does *not* 267 contain a single valid mailbox will cause the PRA algorithm to 268 fail and may cause the message to be rejected. But anything 269 else means that the process doing the MARID checks might make a 270 different decision as to the validity of the mailbox from a 271 subsequent MUA which attempts to display the purported 272 responsible address by parsing the headers. Maybe it would be 273 better to drop this step, and go back to only considering 274 RFC(2)822 headers?] 276 4. Locate all the non-empty Sender headers in the message. If 277 there are no such headers, continue to step 5. If there are 278 multiple such headers, exit without returning a PRA. If the 279 single non-empty Sender header is hopelessly malformed (e.g. if 280 it appears to contain multiple mailboxes, or if the single 281 mailbox is hopelessly malformed), exit without returning a PRA. 282 Otherwise, exit returning the mailbox from the Sender header as 283 the PRA. 285 5. Locate all the non-empty From headers in the message. If there 286 are no such headers, or multiple such headers, exit without 287 returning a PRA. If the single non-empty From header is 288 hopelessly malformed (e.g. it contains one or more mailboxes 289 that are hopelessly malformed) then exit without returning a 290 PRA. If it contains multiple mailboxes, exit without returning a 291 PRA. Otherwise, return the single mailbox from the From header 292 as the PRA. 294 The purported responsible domain of the message is the domain part of 295 the purported responsible address returned by the above algorithm. 297 If the above algorithm fails to return a PRA, or if the PRA does not 298 contain a domain, then an MTA SHOULD reject the message as hopelessly 299 malformed. 301 What constitutes a hopelessly malformed header or a hopelessly 302 malformed mailbox is a matter for local policy. 304 [Note: such local policy will never cause two implementation to 305 return different PRAs. However it may cause one implementation to 306 return a PRA where another implementation does not. The result is 307 that corner cases may result in messages of questionable 308 deliverability, but they will never result in an MTA doing MARID 309 checks on a different PRA from the address that a PRA-aware MUA 310 chooses to display, even if they make their decisions independently.] 312 5. E-mail Policy Document 314 An E-mail Policy Document is modeled by an XML infoset that contains, 315 among other things, a definition of the function described in section 316 3 above. This function can be used to determine whether a domain 317 owner is willing to take responsibility for e-mail that is sent by a 318 particular SMTP client. 320 This document describes those parts of the XML infoset that define 321 the mail acceptance function. The infoset may contain other 322 information relating to e-mail; this other information may be the 323 subject of future IETF consensus processes. Any program that 324 interprets the XML Infoset SHOULD ignore any elements whose tags are 325 not understood by the program. 327 Section 5.1 below contains a detailed definition of the XML infoset. 328 Section 5.2 contains a description of the macro expansion performed 329 on the character data in some of the elements. Section 5.3 below 330 contains the algorithm by which the XML infoset may be obtained. 332 5.1 Elements of the Infoset 334 The root of the infoset is always a "root" element. 336 5.1.1 "root" element 338 Attributes: none 339 Child elements: A single "ep" element. 341 The "root" element carries no semantic information -- it's an 342 artifact of the manner in which the infoset is constructed. 344 5.1.2 "ep" element 346 Attributes: "testing" (Boolean) 347 Child elements: A single optional "out" element. 349 The "ep" element is intended to describe a domain's e-mail policy. 350 At the present writing, this is limited to describing the client 351 authorization function, but other information may be added in the 352 future. 354 If the "testing" attribute is "true", then programs SHOULD behave as 355 if the e-mail policy is absent, except by prior arrangement with the 356 owner of the domain. 358 If the "out" element is present, it describes the client 359 authorization function. If "out" is absent, the client authorization 360 function always returns "unknown". 362 5.1.3 "out" element 364 Attributes: "default" (one of "pass", "fail", "softFail", "unknown") 365 "redirect" (a domain name with macro expansion) 366 Child elements: A sequence of zero or more "m" elements. 368 The "out" element describes the client authorization function. To 369 evaluate this function, evaluate each of the "m" elements in sequence 370 as described below, until one of them returns a definite result. 371 That result is the result of the client authorization function. 373 If no child "m" element returns a definite result, then: 375 1. If the "redirect" attribute is present, extract the domain name 376 from it with macro expansion, obtain that domain's e-mail policy 377 document, and return the result of evaluating that document's 378 client authorization function, passing: 379 the local-part that was passed to this function, 380 the original domain name that was passed to this function, 381 the domain name from the "redirect" attribute 382 (after macro expansion), and 383 the IP address that was passed to this function. 385 2. Otherwise, if the "default" attribute is present, the result of 386 the client authorization function is the value of this 387 attribute. 389 3. Otherwise, the result of the client authorization function is 390 "fail". 392 5.1.4 "m" element 394 Attributes: "result" (one of "pass", "fail", "softFail", "unknown") 395 Child Elements: A sequence of zero or more "a", "exists", "include", 396 "mx" and "r" elements. 398 Each "m" element describes a portion of the client authorization 399 function. To evaluate the client authorization function, evaluate 400 each of the child elements in sequence, until one of them returns a 401 match. If one of them returns a match, the result of the client 402 authorization function is the value of the "result" attribute (whose 403 default is "pass"). If no child element returns a match, evaluation 404 will continue with the next "m" element. 406 5.1.5 "a" element 408 Attributes: None 409 Child Elements: None 410 Character Data: An optional domain name or IPv4 or IPv6 address, 411 with macro expansion. 413 If the character data is empty, replace it with "%D" (as defined 414 below in section 5.2. 416 If an "a" element contains an IPv4 or IPv6 address, it matches iff 417 that address exactly equals the IP address passed to the client 418 authorization function. 420 Otherwise, obtain the A or AAAA records for the given domain name 421 (after macro expansion). The "a" element matches if the IP address 422 in any of these records exactly equals the IP address that was passed 423 to the client authorization function. 425 If the specified name does not exist in DNS, or if no A or AAAA 426 records (as appropriate) exist, the "a" element does not match. If 427 any other error occurs during lookup, the result of the client 428 authorization function is "transientError". 430 5.1.6 "exists" element 432 Attributes: None 433 Child Elements: None 434 Character Data: A domain name, with macro expansion. 436 This element matches iff the domain given by the character data 437 (after macro expansion) exists in DNS. If the DNS lookup fails for 438 any reason other than nonexistence, the client authorization function 439 returns "transientError". 441 5.1.7 "include" element 443 Attributes: None 444 Child Elements: None 445 Character Data: A domain name, with macro expansion. 447 In order to determine whether this element matches, obtain the e-mail 448 policy record for the specified domain (after macro expansion), and 449 evaluate its client authorization function, passing 450 the original local-part 451 the original domain-name 452 the domain name from the character data (after macro expansion), 453 the original IP address. 455 The "include" element matches iff that domain's client authorization 456 function returns "pass". 458 Otherwise, if the recursive function returns "transientError" or 459 "hardError", that result is also the result of the current function 460 evaluation. 462 5.1.8 "mx" element 464 Attributes: None 465 Child Elements: None 466 Character Data: An optional domain name, with macro expansion. 468 If the character data is empty, replace it with "%D". 470 This element matches iff the IP address is listed as a mail server 471 for the specified domain. This can occur for either of two reasons: 473 1. One or more MX records exists for the domain, and one of the MX 474 records references a domain that contains an A or AAAA record 475 that exactly matches the input IP address. 477 2. No MX records exist for the domain, and an A or AAAA record for 478 the domain exactly matches the input IP address. 480 If any DNS lookup error other than domain not found occurs, the 481 client authorization function returns "transientError". 483 5.1.9 "ptr" element 485 Attributes: None 486 Child Elements: None 487 Character Data: A domain name, with macro expansion. 489 To determine whether this element matches, first perform a reverse 490 DNS lookup of the IP address. This element matches iff the given 491 domain name is a suffix of any of the domain names that were fetched 492 in the lookup. 494 If any DNS lookup error other than domain not found occurs, the 495 client authorization function returns "transientError". 497 5.1.10 "r" element 499 Attributes: None 500 Child Elements: None 501 Character Data: IP address '/' count 503 This element matches iff the IP address in the character data is of 504 the same form as the input IP address (IPv4 or IPv6), and the two 505 addresses are equal when comparing only the most significant 'count' 506 bits. 508 5.2 Macro Expansion 510 This section defines the macro expansion that occurs on many of the 511 domain names in the e-mail policy document. 513 5.2.1 Macro definitions 515 macro-string = *( macro-char / VCHAR ) 516 macro-char = ( "%{" ALPHA transformer *delimiter "}" ) 517 / "%%" / "%_" / "%-" 518 transformer = [ *DIGIT ] [ "r" ] 519 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 521 A literal "%" is expressed by "%%". 522 %_ expands to a single " " space. 523 %- expands to a URL-encoded space, viz. "%20". 525 The following macro letters are expanded in directive arguments: 527 l = local-part passed to the client authorization function. 528 s = Same as "%{l}@%{o}". 529 o = original domain passed to the client authorization function. 530 d = current domain passed to the client authorization function. 531 i = SMTP client IP (nibble format when an IPv6 address). 532 p = SMTP client domain name 533 v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6 534 r = domain name of the SMTP server. 536 The uppercase versions of all these macros are URL-encoded. 538 A '%' character not followed by a '{', '%', '-', or '_' character 539 MUST be interpreted as a literal. SPF publishers SHOULD NOT rely on 540 this feature; they MUST escape % literals. 542 Legal optional transformers are: 544 *DIGIT ; zero or more digits 545 'r' ; reverse value, splitting on dots by default 547 If transformers or delimiters are provided, the macro strings are 548 split into parts. After performing any reversal operation or removal 549 of left-hand parts, the parts are rejoined using "." and not the 550 original splitting characters. 552 By default, strings are split on "." (dots). Macros may specify 553 delimiter characters which are used instead of ".". Delimiters MUST 554 be one or more of the characters: 556 "." / "-" / "+" / "," / "/" / "_" / "=" 558 The 'r' transformer indicates a reversal operation: if the client IP 559 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 560 and the macro %{ir} would expand to "1.2.0.192". 562 The DIGIT transformer indicates the number of right-hand parts to use 563 after optional reversal. If a DIGIT is specified, it MUST be 564 nonzero. If no DIGITs are specified, or if the value specifies more 565 parts than are available, all the available parts are used. If the 566 DIGIT was 5, and only 3 parts were available, the macro interpreter 567 would pretend the DIGIT was 3. Implementations MAY limit the number, 568 but MUST support at least a value of 128. 570 For IPv4 addresses, both the "i" and "c" macros expand to the 571 standard dotted-quad format. 573 For IPv6 addresses, the "i" macro expands to dot-format address; it 574 is intended for use in %{ir}. The "c" macro may expand to any of the 575 hexadecimal colon-format addresses specified in [RFC3513] section 576 2.2. It is intended for humans to read. 578 The "p" macro expands to the validated domain name of the SMTP 579 client. The validation procedure is described in section 4.6. If 580 there are no validated domain names, the word "unknown" is 581 substituted. If multiple validated domain names exist, the first one 582 returned in the PTR result is chosen. 584 The "r" macro expands to the name of the receiving MTA. This SHOULD 585 be a fully qualified domain name, but if one does not exist (as when 586 the checking is done by a script) or if policy restrictions dictate 587 otherwise, the word "unknown" SHOULD be substituted. The domain name 588 MAY be different than the name found in the MX record that the client 589 MTA used to locate the receiving MTA. 591 The "s" macro expands to the sender email address: a localpart, an @ 592 sign, and a domain. The "o" macro is the domain part of the "s". 593 They remain the same during a recursive "include" or "redirect" 594 subquery. 596 When the result of macro expansion is used in a domain name query, if 597 the expanded domain name exceeds 255 characters (the maximum length 598 of a domain name), the left side is truncated to fit, by removing 599 successive subdomains until the total length falls below 255 600 characters. 602 Uppercased macros are URL escaped. 604 URL encoding is described in [RFC2396]. 606 5.2.2 Expansion Examples 608 The is internet-draft@email.example.com. 609 The IPv4 SMTP client IP is 192.0.2.3. 610 The IPv6 SMTP client IP is 5f05:2000:80ad:5800::1. 611 The PTR domain name of the client IP is mx.example.org. 613 macro expansion 614 ------------------------------- 615 %{s} internet-draft@email.example.com 616 %{o} email.example.com 617 %{d} email.example.com 618 %{d4} email.example.com 619 %{d3} email.example.com 620 %{d2} example.com 621 %{d1} com 622 %{p} mx.example.org 623 %{p2} example.org 624 %{dr} com.example.email 625 %{d2r} example.email 626 %{l} internet-draft 627 %{l-} internet.draft 628 %{lr} internet-draft 629 %{lr-} draft-internet 630 %{l1r-} draft 632 macro-string expansion 633 --------------------------------------------------------------------- 634 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 635 %{lr-}.lp._spf.%{d2} draft.internet.lp._spf.example.com 637 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 638 Draft.internet.lp.3.2.0.192.in-addr._spf.example.com 640 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 641 3.2.0.192.in-addr.internet.lp._spf.example.com 643 %{p2}.trusted-domains.example.net 644 example.org.trusted-domains.example.net 646 IPv6: 647 %{ir}.example.org 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8. 648 5.d.a.0.8.0.0.0.2.5.0.f.5.example.org 650 5.3 Determining the E-mail Policy Document for a Domain 651 In order to find the E-mail policy document for a domain, the 652 following algorithm (or an algorithm that always yields the same 653 result) MUST be used. In this algorithm, "$DOMAIN" stands for the 654 domain whose E-mail policy document is desired. 656 1. From DNS, obtain the set of TXT records for domain "_ep.$DOMAIN". 657 If the set contains exactly one TXT record, apply the 658 transformations in section 5.3.1 to that record. 660 If the set contains more than one record, the E-mail policy 661 document cannot be obtained, and the result of validation is 662 "hardError". 664 If the set is empty, or if the domain "_ep.$DOMAIN" does not 665 exist, continue to step 2. 667 If any DNS error other than NXDOMAIN occurs, the e-mail policy 668 document cannot be obtained, and the result of validation is 669 "transientError". 671 2. From DNS, obtain the set of TXT records for domain "$DOMAIN". If 672 the set contains exactly one record whose first string starts 673 with the characters "v=spf1 ", apply the transformations in 674 section 5.3.2 to that record to obtain the EMail policy document. 676 If the record set contains more than one record whose initial 677 string starts with "v=spf1", the EMail policy document cannot be 678 obtained, and the result of validation is "hardError". 680 If the record set contains no records whose initial string starts 681 with "v=spf1", the EMail policy document cannot be obtained, and 682 the result of validation is "none". 684 If the domain "$DOMAIN" does not exist, the EMail policy document 685 cannot be obtains, and the result of validation is "fail". 687 If any DNS error other than NXDOMAIN occurs, the EMail policy 688 document cannot be obtained, and the result of validation is 689 "transientError". 691 5.3.1 From an XML TXT Record 693 Given a DNS TXT record from the "_ep" subdomain of the desired 694 domain, the EMail policy document is obtained as follows: 696 1. Append a CRLF to each string in the DNS record. 697 2. Concatenate all of the resulting strings together, in order. 698 3. Prefix the resulting string with the following: 699 700 708 4. Suffix the resulting string with the following: 709 711 5. If the resulting string is not a well-formed XML document, the 712 domain's EMail policy document cannot be obtained, and the result 713 of validation is "hardError". 715 6. If the resulting string, treated as an XML document, is not valid 716 with respect to the schema published in Appendix A, the EMail 717 policy document cannot be obtained, and the result of validation 718 is "hardError". 720 7. A processor MAY attempt to validate the resulting XML document 721 with respect to any other XML schemas of which it is aware. It 722 MAY return a "hardError" result if any such validation fails. A 723 processor SHOULD NOT attempt to dynamically locate schemas for 724 namespaces whose semantics are unknown to the processor. 726 8. The Infoset corresponding to the resulting string is the domain's 727 EMail policy document. 729 XML namespace "urn:ietf:params:xml:schema:marid-1" is defined by this 730 specification, the "...:marid-2" through "...:marid-5" namespaces are 731 reserved for definition by future IETF consensus processes, and the 732 namespaces "http://www.w3.org/2001/XMLSchema" and 733 "http://www.w3.org/2000/09/xmldsig#" are defined by [XMLSchema] and 734 [RFC3275], respectively. 736 Note: Even though the implied header for the XML document specifies 737 , domain that publish records SHOULD restrict 738 themselves to the 7-bit US-ASCII subset, because there exist DNS 739 resolvers and caching DNS servers that incorrectly reject TXT records 740 with any characters whose high bits are set. Nevertheless, should an 741 MTA receive a record containing any characters with high bits set, 742 the MTA MUST treat those characters as UTF-8 encoded. 744 Examples: 746 example.com. IN TXT "" 747 This record says that example.com's outbound mail servers are exactly 748 the same as its inbound servers. 750 example.com. IN TXT "10.1.1.0/24" 751 This record says that example.com's outbound mail servers are given 752 by the IP address range 10.1.1.0/24. 754 5.3.2 From an SPF TXT Record 756 << This text really needs to be rewritten. What follows gives the 757 concept, but isn't legalistic enough. It probably needs to stand 758 alone instead of referencing the SPF spec. >> 760 Given a TXT record from the desired domain that starts with the 761 characters "v=spf1 ", the EMail policy document is obtained via the 762 following algorithm. The namespace of all elements and attributes in 763 the resulting XML infoset is "urn:ietf:params:xml:schema:marid-1". 765 1. Start with the infoset described by the following XML text: 766 767 768 769 770 771 773 2. For each SPF mechanism in the input, create a new "m" node under 774 the "out" node. The "result" attribute of the "m" node is "pass", 775 "fail", "softFail" or "unknown", depending on whether the 776 mechanism's prefix is "+", "-", "~", or "?". 778 3. Unless the mechanism name is "all", create a new element under 779 the new "m" node, of a type as follows: 781 mechanism element 782 --------- ------- 783 a a 784 exists exists 785 include include 786 ip4 without "/" a 787 ip4 with "/" r 788 ip6 without "/" a 789 ip6 with "/" r 790 mx mx 791 ptr ptr 793 Place everything after the ":" (if any) into the character data 794 of the new element. 796 4. Treat any unknown mechanism as if it said "?all". 798 5. If there's a "redirect" modifier, set the "redirect" attribute of 799 the "out" node. 801 The resulting infoset is now complete. 803 5.4 Recursion Limitations 805 Evaluation of many of the mechanisms in section 5.1 will require 806 additional DNS lookups. To avoid infinite recursion, and to avoid 807 certain denial of service attacks, an MTA or other processor SHOULD 808 limit the total number of DNS lookups that it is willing to perform 809 in the course of a single authentication. Such a limit SHOULD allow 810 for at least 20 lookups. If such a limit is exceeded, the result of 811 authentication MUST be "hardError". 813 MTAs or other processors MAY also impose a limit on the maximum 814 amount of elapsed time to perform an authentication. Such a limit 815 SHOULD allow at least 10 seconds. If such a limit is exceeded, the 816 result of authentication SHOULD be "transientError". 818 Domains publishing records SHOULD keep the number of DNS lookups to 819 less than 20. Domains publishing records that are intended for use 820 as the target of "indirect" elements SHOULD keep the number of DNS 821 lookups to less than 10. 823 6. Actions Based on the Decision 825 This section describes the meaning of each possible result of the 826 authentication function. 828 6.1 pass 830 A "pass" result from the check means that the domain has authorized 831 the sending of the message in question. An SMTP server receiving this 832 result SHOULD accept the message. 834 6.2 fail 836 A "fail" result from the check means that the domain disclaims 837 authorization of the message. An SMTP server receiving this result 838 SHOULD reject the message with a 550 SMTP error code. 840 6.3 softFail 842 A "softFail" result from the check means that the message did not 843 originate from the domain's primary mail servers, but the domain is 844 unable to definitively state that the message was not authorized. An 845 SMTP server receiving this result SHOULD NOT reject the message for 846 this reason alone, but MAY subject the message to heightened scrutiny 847 by other anti-spam measures, and MAY reject the message as a result 848 of this heightened scrutiny. A message for which the result is 849 "softFail" is less likely to be authentic than a message for which 850 the result is "neutral". 852 6.4 neutral 854 A "neutral" result from the check means that the domain can offer no 855 information about whether the message was authorized. An SMTP server 856 receiving this result SHOULD NOT reject the message for this reason 857 alone, but MAY subject the message to heightened scrutiny by other 858 anti-spam measures, and MAY reject the message as a result of this 859 heightened scrutiny. 861 6.5 transientError 863 A "transientError" result from the check means that the check was 864 aborted because of inability to get a definitive answer from a DNS 865 lookup. An SMTP server receiving this result MAY reject the message 866 with a 450 error code (transient failure). Alternatively, an SMTP 867 server receiving this result MAY accept a message and optionally 868 subject it to heightened scrutiny by other anti-spam measures. 870 6.6 hardError 872 A "hardError" result from the check means that the check was aborted 873 because the published information was ill-formed or because too much 874 processing would be required to achieve a definitive answer. An SMTP 875 server SHOULD treat this result identically to a "neutral" result. 877 6.7 none 879 A "none" result from the check means that the check was aborted 880 because the domain did not publish an e-mail policy document. An 881 SMTP server SHOULD treat this identically to a "neutral" result. 883 7. Security Considerations 885 This entire document describes a new mechanism for mitigating spoofed 886 email, which is today a pervasive security problem in the Internet. 888 Assuming that this mechanism is widely deployed, the following 889 sections describe counter-attacks that could be used to defeat this 890 mechanism. 892 7.1 DNS Attacks 894 The new mechanism is entirely dependent of DNS lookups, and is 895 therefore only as secure as DNS. An attacker bent on spoofing 896 messages could attempt to get his messages accepted by sending forged 897 answers to DNS queries. 899 An MTA could largely defeat such an attack by using a properly 900 paranoid DNS resolver. DNSSEC may ultimately provide a way to 901 completely neutralize this class of attacks. 903 7.2 TCP Attacks 905 This mechanism is designed to be used in conjunction with SMTP over 906 TCP. A sufficiently resourceful attacker might be able to send TCP 907 packets with forged from-addresses, and thus execute an entire SMTP 908 session that appears to come from somewhere other than its true 909 origin. 911 Such an attack requires guessing what TCP sequence numbers an SMTP 912 server will use. It also requires transmitting completely in the 913 blind � the attack will be unable hear any of the server's side of 914 the conversation. 916 Attacks of this sort can be ameliorated if IP gateways refuse to 917 forward packets when the source address is clearly bogus. 919 7.3 Forged Resent-From Attacks 921 This mechanism chooses a purported responsible address from one of a 922 number of message headers, and then uses that address for validation. 923 A message with a true Resent-From header (for example), but a forged 924 From header will be accepted. Since many MUAs do not display all of 925 the headers of received messages, the message will appear to be 926 forged when displayed. 928 In order to avoid this attack, MUAs will need to start displaying at 929 least the header that was verified. 931 8. Extensibility Considerations 933 Many of the XML elements are defined to allow any attribute and any 934 child element. A program MUST ignore any element or attribute whose 935 meaning it does not understand. It will be easy to use new elements 936 and attributes to describe other pieces of email policy that are not 937 currently specified. For example, it may become appropriate to 938 define elements that allow a domain to specify how to complain about 939 spam from that domain, which accreditation agencies can vouch for the 940 domain, whether the domain is interested in answering challenges in 941 challenge / response systems, and so forth. 943 While it will be easy to add new kinds of information to the e-mail 944 policy document, future implementers must proceed with extreme care 945 if they attempt to modify the semantics of the client authorization 946 function. Code that is not aware of the new semantics will 947 completely ignore any newly invented elements. 949 It is anticipated that extensions will only be defined for the XML 950 version of the DNS record, not for the SPF version. 952 With the final draft of this document, the 953 "urn:ietf:params:xml:schema:marid-1" namespace schema becomes frozen 954 for all time. Future extensions will need to use other namespaces. 955 In order to avoid having to write very long namespaces in DNS TXT 956 records, the namespace prefixes "m2" through "m5" are defined at this 957 time, even though their referents will only be defined in the future. 958 Their referents, the namespaces "urn:ietf:params:xml:schema:marid-2" 959 through "...-5" are of the form that they can only be defined by a 960 future IETF consensus process. 962 9. Applicability Statement 964 This section describes the actions that certain members of the 965 Internet email ecosystem must take to be compliant with this 966 specification. 968 << Be more precise and prescriptive about what header to insert 969 where. >> 971 9.1 Simple E-mailers 973 A domain that injects original email into the Internet, using its own 974 name in From headers, need do nothing to be compliant. However, such 975 domains SHOULD publish e-mail policy records in DNS. 977 9.2 E-mail Forwarders 979 A program that forwards received mail to other addresses MUST add an 980 appropriate header that contains an email address that it is 981 authorized to use. Such programs SHOULD use the Resent-From header 982 for this purpose. 984 Many of today's forwarders already add an appropriate header 985 (although most of them use Delivered-To or some other nonstandard 986 header rather than Resent-From.) 988 9.3 Mailing List Servers 990 A mailing list server MUST add an appropriate header that contains an 991 email address that it is authorized to use. Such programs SHOULD use 992 the Resent-From header for this purpose. 994 Most of today's mailing list software already adds an appropriate 995 header (although most of them use Sender rather than Resent-From). 997 9.4 Third-Party Mailers 999 A program that sends mail on behalf of another user MUST add an 1000 appropriate header than contains an email address that it is 1001 authorized to use. Such programs SHOULD use the Sender header for 1002 this purpose. 1004 Many, but not all, of today's third-party mailers are already 1005 compliant. 1007 9.5 MTA Implementers 1009 MTAs that are acting as SMTP servers SHOULD implement the checks 1010 described in this document. 1012 An MTA SHOULD limit the number of DNS lookups (or the time spent 1013 performing the lookup) that it will perform in the process of 1014 checking a message. Such a limit SHOULD permit at least 20 DNS 1015 lookups. 1017 9.6 MUA Implementers 1019 When displaying a received message, an MUA SHOULD display the 1020 purported responsible address as defined by this document whenever 1021 that address differs from the From address. This display SHOULD be 1022 in addition to the From address. 1024 When a received message contains multiple headers that might be used 1025 for the purported responsible address determination, an MUA should 1026 consider displaying all of them. That is, if a message contains 1027 several Resent-From's, a Sender and a From, an MUA should consider 1028 displaying all of them. 1030 10. IANA Considerations 1032 The IANA is requested to register the following URI: 1034 URI: urn:ietf:params:xml:schema:marid-1 1035 Registrant Contact: IESG. 1036 XML: The contents of Appendix A of this document 1038 11. Acknowledgements 1040 Variations on the idea of using a DNS record to check the legitimacy 1041 of an email address have occurred multiple times. The earliest known 1042 work is [RMX]; others include [SPF} and [CallerID]. 1044 The current document borrows heavily from each of the above, and 1045 incorporates many ideas proposed by many members of the MARID working 1046 group. 1048 12. References 1050 12.1 Normative References 1052 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1053 Requirement Levels", RFC 2119. 1055 [RFC2026] S. Bradner, "The Internet Standards Process � Revision 1056 3", RFC 2026. 1058 [RFC3275] D. Eastlake et al, "XML-Signature Syntax and Processing", 1059 RFC 3275. 1061 [XMLSchema] "XML Schema Part 1: Structures", W3C Recommendation 2 May 1062 2001, http://www.w3c.org/TR/2001/REC-xmlschema-1- 1063 20010502/ 1065 12.2 Informative References 1067 [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical 1068 Specification, 1069 http://www.microsoft.com/mscorp/twc/privacy/spam_callerid 1070 .mspx. 1072 [CSV] D. Crocker, "Client SMTP Validation (CSV)", draft- 1073 crocker-marid-smtp-validate-01. Work in progress. 1075 [DK] M. Delany, "Domain-based Email Authentication Using 1076 Public-Keys Advertised in the DNS (DomainKeys)", draft- 1077 delany-domainkeys-base-00. Work in progress. 1079 [MTAMARK] M. Stumpf, and S. Hoehne, "Marking Mail Transfer Agents 1080 in Reverse DNS with TXT RRs", draft-stumpf-dns-mtamark- 1081 02. Work in progress. 1083 [RMX] H. Danisch, "The RMX DNS RR and method for lightweight 1084 SMTP sender authorization", draft-danisch-dns-rr-smtp-04. 1085 Work in progress. 1087 [SMIME] B. Ramsdell (editor), "S/MIME Version 3 Message 1088 Specification", RFC 2633. 1090 [SPF] M. Lentczner and M. Weng, "Sender Policy Framework (SPF): 1091 A Convention to Describe Hosts Authorized to Send SMTP 1092 Traffic", draft-mengwong-spf-01. Work in progress. 1094 [Submitter] E. Allman and H. Katz, "SMTP Service Extension for 1095 Indicating the Responsible Submitter of an E-mail 1096 Message", draft-ietf-marid-submitter-00. Work in 1097 progress. 1099 13. Authors' Addresses 1101 Jim Lyon 1102 Microsoft Corporation 1103 One Microsoft Way 1104 Redmond, WA 98052 1105 USA 1106 jimlyon@microsoft.com 1108 Meng Weng Wong 1109 Singapore 1110 mengwong@dumbo.pobox.com 1112 14. Full Copyright Statement 1114 Copyright (C) The Internet Society (2004). All Rights Reserved. 1116 This document and translations of it may be copied and furnished to 1117 others, and derivative works that comment on or otherwise explain it 1118 or assist in its implementation may be prepared, copied, published 1119 and distributed, in whole or in part, without restriction of any 1120 kind, provided that the above copyright notice and this paragraph are 1121 included on all such copies and derivative works. However, this 1122 document itself may not be modified in any way, such as by removing 1123 the copyright notice or references to the Internet Society or other 1124 Internet organizations, except as needed for the purpose of 1125 developing Internet standards in which case the procedures for 1126 copyrights defined in the Internet Standards process must be 1127 followed, or as required to translate it into languages other than 1128 English. 1130 The limited permissions granted above are perpetual and will not be 1131 revoked by the Internet Society or its successors or assigns. 1133 This document and the information contained herein is provided on an 1134 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1135 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1136 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1137 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1138 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1140 Appendix A: XML Schema for urn:ietf:params:xml:schema:marid-1 1142 1143 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1158 1159 1160 1162 1164 1166 1168 1170 1172 1174 1175 1178 1179 1181 1183 1184 1185 1187 1188 1190 1192 1194 1195 1196 1198 1199 1201 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224