idnits 2.17.1 draft-ietf-marid-core-00.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 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 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 7253 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: 'RFC2822' is mentioned on line 272, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'RFC3513' is mentioned on line 542, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Missing Reference: 'RFC2396' is mentioned on line 577, 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: 4 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MARID Working Group J. Lyon 3 Internet Draft Microsoft Corp 4 Document: draft-ietf-marid-core-00.txt M. Wong 5 pobox.com 6 Expires: November 2004 June 2004 8 MTA Authentication Records in DNS 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 Internet mail suffers from the fact that much unwanted mail is sent 33 using spoofed addresses �- "spoofed" in this case means the address 34 is used without the permission of the domain owner. This document 35 describes mechanisms by which a domain owner can publish its set of 36 outgoing MTAs, and mechanisms by which SMTP servers can determine 37 what email address is allegedly responsible for most proximately 38 introducing a message into the Internet mail system, and whether that 39 introduction is authorized by the owner of the domain contained in 40 that email address. 42 The specification is carefully tailored to ensure that the 43 overwhelming majority of legitimate emailers, remailers and mailing 44 list operators are already compliant. 46 Table of Contents 48 1. Introduction...................................................3 49 2. Problem Statement..............................................3 50 2.1 Positive Problem Statement.................................3 51 2.2 Negative Problem Statement.................................4 52 3. Decision Model.................................................5 53 4. Determining the Purported Responsible Address..................6 54 5. E-mail Policy Document.........................................7 55 5.1 Elements of the Infoset....................................7 56 5.1.1 "root" element.......................................7 57 5.1.2 "ep" element.........................................7 58 5.1.3 "out" element........................................8 59 5.1.4 "m" element..........................................9 60 5.1.5 "exists" element.....................................9 61 5.1.6 "include" element...................................10 62 5.1.7 "mx" element........................................10 63 5.1.8 "r" element.........................................10 64 5.2 Macro Expansion...........................................11 65 5.2.1 Macro definitions...................................11 66 5.2.2 Expansion Examples..................................13 67 5.3 Determining the EMail Policy Document for a Domain........14 68 5.3.1 From an XML TXT Record..............................14 69 5.3.2 From an SPF TXT Record..............................15 70 6. Actions Based on the Decision.................................16 71 7. Security Considerations.......................................16 72 7.1 DNS Attacks...............................................16 73 7.2 TCP Attacks...............................................17 74 7.3 Forged Resent-From Attacks................................17 75 8. Extensibility Considerations..................................17 76 9. Applicability Statement.......................................18 77 9.1 Simple EMailers...........................................18 78 9.2 EMail Forwarders..........................................18 79 9.3 Mailing List Servers......................................19 80 9.4 Third-Party Mailers.......................................19 81 9.5 MTA Implementers..........................................19 82 9.6 MUA Implementers..........................................19 83 10. IANA Considerations..........................................20 84 11. Patent Disclosure............................................20 85 12. Acknowledgements.............................................20 86 13. References...................................................20 87 13.1 Normative References.....................................20 88 13.2 Informative References...................................21 89 14. Authors' Addresses...........................................21 90 15. Full Copyright Statement.....................................22 91 Appendix A: A Brief Introduction to XML.........................22 92 Appendix B: XML Schema for urn:ietf:params:xml:schema:marid-1...23 94 Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 << Text contained in double angle brackets describes actions that are 101 yet to be taken and decisions that are yet to be made. No such text 102 should survive in the final version of this draft. >> 104 1. Introduction 106 Today, a huge majority of the unwanted email contains headers that 107 lie about the origin of the mail. This is true of most spam and 108 substantially all of the virus email that is sent. 110 This document describes a mechanism such that receiving MTAs, MDAs 111 and/or MUAs can recognize mail in this category and take appropriate 112 action. For example, an MTA might refuse to accept a message, an MDA 113 might discard a message rather than placing it into a mailbox, and an 114 MUA might render that message in some distinctive fashion. 116 In order to avoid further fragmentation of the Internet email system, 117 it is necessary that the Internet community as a whole come to a 118 consensus as to what mail senders should do to make their mail appear 119 non-spoofed, and how mail receivers should determine whether mail is 120 spoofed. On the other hand, it is not necessary to reach a consensus 121 regarding the actions that various parties take once a message has 122 been determined to be spoofed. This can be done unilaterally -- one 123 agent might decide to discard a spoofed message while another decides 124 to add a disclaimer. 126 2. Problem Statement 128 2.1 Positive Problem Statement 130 Briefly stated, the mechanisms of this document allow one to answer 131 the following question: 133 When a message is transferred via SMTP between two UNRELATED parties, 134 does the SMTP client host have permission to send mail on behalf of 135 the mailbox that allegedly caused the most recent introduction of the 136 message into the mail delivery system? 138 As seen from the question, this mechanism applies to unrelated 139 parties: it is useful at the point where a message passes across the 140 Internet from one organization to another. It is beyond the scope of 141 this document to describe authentication mechanisms that can be 142 deployed within an organization. 144 The mechanism of this document also seeks to authenticate the mailbox 145 associated with the MOST RECENT introduction of a message into the 146 mail delivery system. In simple cases, this is who the mail is from. 147 However, in the case of a third-party mailer, a forwarder or a 148 mailing list server, the address being authenticated is that of the 149 third party, the forwarder or the mailing list. 151 This document provides means to authenticate the DOMAIN of the 152 appropriate email address; it makes no attempt to authenticate the 153 local-part. A domain owner gets to determine which SMTP clients 154 speak on behalf of addresses within the domain; a responsible domain 155 owner should not authorize SMTP clients that will lie about local 156 parts. 158 In the long run, once the domain of the sender is authenticated, it 159 will be possible to use that domain as part of a mechanism to 160 determine the likelihood that a given message is spam, using 161 reputation and accreditation services. (These services are not the 162 subject of the present mechanism, but it should enable them.) 164 2.2 Negative Problem Statement 166 This section describes alternate questions, which this document makes 167 no attempt to solve. 169 Is the host at a particular IP address authorized to act as an SMTP 170 client? [MTAMARK] attempts to answer this question using a reverse 171 DNS lookup. It suffers from the fact that reverse DNS lookups are 172 poorly implemented in major fractions of the IP address space, from 173 the fact that many ISPs refuse to reverse-delegate to small domains, 174 and from the fact that it's all or nothing: authority to act as an 175 SMTP client conveys authority to send absolutely any email, 176 legitimate or otherwise. 178 Is an SMTP client authorized to use a particular domain name in its 179 SMTP EHLO command? [CSV] attempts to answer this question. It 180 suffers from the fact that the EHLO name has a tenuous relationship, 181 at best, with the contents of any mail message. 183 Is an SMTP client authorized to use a particular email address in an 184 SMTP "MAIL FROM:" command? [RMX] and [SPF] attempt to answer this 185 question. These suffer from the fact that the MAIL FROM address 186 really describes where to send NDRs to, and in many third-party and 187 forwarder situations this address is unrelated to the domain that is 188 resending the message. 190 Was a message really authored by who it claims to be authored by? 191 [SMIME] and [DK] attempt to answer the question of original 192 authorship. While this is a useful question to answer, these 193 approaches suffer from severe deployment issues. 195 3. Decision Model 197 The essence of this specification is: 199 Given an email message, and given an IP address from which it has 200 been (or will be) received, is the SMTP client at that host address 201 authorized to send that email message? 203 There are four steps to answering this question: 205 (1) From the headers of the email message, extract the "purported 206 responsible address". This is the mailbox that the message 207 claims is responsible for the most recent introduction of the 208 message into the delivery system. This step is described in 209 detail in section 4 below. A separate specification, 210 [Submitter], describes an SMTP extension that allows an SMTP 211 server to perform this check at the time of the SMTP MAIL 212 command instead of the SMTP DATA command. 214 (2) Extract the domain part of the purported responsible address. 215 Call this the "purported responsible domain". 217 << TODO: The below is confusing. Clarify it. >> 218 (3) Find the E-mail Policy Document for the purported responsible 219 domain. Section 5.1 below describes the semantics of an EMail 220 Policy Document. Section 5.2 below describes how to find the 221 document for a domain. The EMail Policy Document contains a 222 description of a "client authorization function". This function 223 that takes four arguments and returns a four-valued result. The 224 arguments are: 225 a. The local-part of an email address. 226 b. A domain name, called the "original domain". 227 c. A domain name, called the "current domain". 228 d. An IP address (either IPv4 or IPv6). 229 The result of the function is one of the four values "unknown", 230 "pass", "fail" or "softFail". 232 (4) Execute the function, passing: 233 the local-part of the Purported Responsible Address, 234 the Purported Responsible Domain (as "original domain"), 235 the Purported Responsible Domain (as "current domain"), 236 and the IP address from which the mail was received. 238 A "Pass" result from this check means that the domain has authorized 239 the sending of the message in question. An SMTP server receiving this 240 result SHOULD accept the message. 242 A "Fail" result from this check means that the domain disclaims 243 authorization of the message. An SMTP server receiving this result 244 SHOULD reject the message with a 550 SMTP error code. 246 A "SoftFail" result from this check means that the message did not 247 originate from the domain's primary mail servers, but the domain is 248 unable to definitively state that the message was not authorized. An 249 SMTP server receiving this result SHOULD NOT reject the message for 250 this reason alone, but MAY subject the message to heightened scrutiny 251 by other anti-spam measures, and MAY reject the message as a result 252 of this heightened scrutiny. 254 An "Unknown" result from this check means that either the domain is 255 unable to determine whether the message is authorized, or that the 256 domain's EMail policy record is absent, malformed, or otherwise 257 unusable. An SMTP server receiving this result SHOULD NOT reject the 258 message for this reason alone, but MAY subject the message to 259 heightened scrutiny by other anti-spam measures, and MAY reject the 260 message as a result of this heightened scrutiny. 262 Note that steps 1, 2 and 4 may fail to complete successfully. In 263 this case, the result of the check is "Unknown". 265 4. Determining the Purported Responsible Address 267 The purported responsible address of a message is taken to be the 268 first from the following list of items that is present, non-empty, 269 and is a syntactically valid e-mail address: 271 (1) The first Resent-Sender header in the message, unless (per the 272 rules of [RFC2822]) it is preceded by a Resent-From header and 273 one or more Received or Return-Path headers occur after said 274 Resent-From header and before the Resent-Sender header (see 275 section 3.6.6. of RFC2822 for further information on Resent 276 headers). 278 (2) The first mailbox in the first Resent-From header in the 279 message, 281 (3) The first of either the Delivered-To, X-Envelope-To or Envelope- 282 To headers in the message. These headers are added to forwarded 283 messages by some well-known MTAs. 285 (4) The Sender header in the message, 287 (5) The first mailbox in the From header in the message, 289 The purported responsible domain of the message is the domain part of 290 the purported responsible address. 292 If a message contains none of the above headers, an MTA SHOULD reject 293 is as hopelessly malformed. 295 5. E-mail Policy Document 297 An E-mail Policy Document is modeled by an XML infoset that contains, 298 among other things, a definition of the function described in section 299 3 above. This function can be used to determine whether a domain 300 owner is willing to take responsibility for e-mail that is sent by a 301 particular SMTP client. 303 This document describes those parts of the XML infoset that define 304 the mail acceptance function. The infoset may contain other 305 information relating to e-mail; this other information may be the 306 subject of future IETF consensus processes. Any program that 307 interprets the XML Infoset SHOULD ignore any elements whose tags are 308 not understood by the program. 310 Section 5.1 below contains a detailed definition of the XML infoset. 311 Section 5.2 contains a description of the macro expansion performed 312 on the character data in some of the elements. Section 5.3 below 313 contains the algorithm by which the XML infoset may be obtained. 315 5.1 Elements of the Infoset 317 The root of the infoset is always a "root" element. 319 5.1.1 "root" element 321 Attributes: none 322 Child elements: A single "ep" element. 324 The "root" element carries no semantic information -- it's an 325 artifact of the manner in which the infoset is constructed. 327 5.1.2 "ep" element 329 Attributes: "testing" (Boolean) 330 Child elements: A single optional "out" element. 332 The "ep" element is intended to describe a domain's EMail policy. At 333 the present writing, this is limited to describing the client 334 authorization function, but other information may be added in the 335 future. 337 If the "testing" attribute is "true", then programs SHOULD behave as 338 if the EMail policy is absent, except by prior arrangement with the 339 owner of the domain. 341 If the "out" element is present, it describes the client 342 authorization function. If "out" is absent, the client authorization 343 function always returns "unknown". 345 5.1.3 "out" element 347 Attributes: "default" (one of "pass", "fail", "softFail", "unknown") 348 "redirect" (a domain name with macro expansion) 349 Child elements: A sequence of zero or more "m" elements. 351 The "out" element describes the client authorization function. To 352 evaluate this function, evaluate each of the "m" elements in sequence 353 as described below, until one of them returns a definite result. 354 That result is the result of the client authorization function. 356 If no child "m" element returns a definite result, then: 358 1. If the "redirect" attribute is present, extract the domain name 359 from it with macro expansion, obtain that domain's EMail policy 360 document, and return the result of evaluating that document's 361 client authorization function, passing: 362 the local-part that was passed to this function, 363 the original domain name that was passed to this function, 364 the domain name from the "redirect" attribute 365 (after macro expansion), and 366 the IP address that was passed to this function. 368 2. Otherwise, if the "default" attribute is present, the result of 369 the client authorization function is the value of this 370 attribute. 372 3. Otherwise, the result of the client authorization function is 373 "fail". 375 5.1.4 "m" element 377 Attributes: "result" (one of "pass", "fail", "softFail", "unknown") 378 Child Elements: A sequence of zero or more "a", "exists", "include", 379 "mx" and "r" elements. 381 Each "m" element describes a portion of the client authorization 382 function. To evaluate the client authorization function, evaluate 383 each of the child elements in sequence, until one of them returns a 384 match. If one of them returns a match, the result of the client 385 authorization function is the value of the "result" attribute. If no 386 child element returns a match, evaluation will continue with the next 387 "m" element. 389 "a" element 391 Attributes: None 392 Child Elements: None 393 Character Data: An optional domain name or IPv4 or IPv6 address, 394 with macro expansion. 396 If the character data is empty, replace it with "%D". 398 If an "a" element contains an IPv4 or IPv6 address, it matches iff 399 that address exactly equals the IP address passed to the client 400 authorization function. 402 Otherwise, obtain the A or AAAA records for the given domain name 403 (after macro expansion). The "a" element matches if the IP address 404 in any of these records exactly equals the IP address that was passed 405 to the client authorization function. 407 If the specified name does not exist in DNS, or if no A or AAAA 408 records (as appropriate) exist, the "a" element does not match. If 409 any other error occurs during lookup, the result of the client 410 authorization function is "unknown". 412 5.1.5 "exists" element 414 Attributes: None 415 Child Elements: None 416 Character Data: A domain name, with macro expansion. 418 This element matches iff the domain given by the character data 419 (after macro expansion) exists in DNS. If the DNS lookup fails for 420 any reason other than nonexistence, the client authorization function 421 returns "unknown". 423 5.1.6 "include" element 425 Attributes: None 426 Child Elements: None 427 Character Data: A domain name, with macro expansion. 429 In order to determine whether this element matches, obtain the EMail 430 policy record for the specified domain (after macro expansion), and 431 evaluate its client authorization function, passing 432 the original local-part 433 the original domain-name 434 the domain name from the character data (after macro expansion), 435 the original IP address. 437 The "include" element matches iff that domain's client authorization 438 function returns "pass". 440 If any error occurs in obtaining the domain's EMail policy record, 441 the current client authorization function evaluation returns 442 "unknown". 444 5.1.7 "mx" element 446 Attributes: None 447 Child Elements: None 448 Character Data: An optional domain name, with macro expansion. 450 If the character data is empty, replace it with "%D". 452 This element matches iff the IP address is listed as a mail server 453 for the specified domain. This can occur for either of two reasons: 455 1. One or more MX records exists for the domain, and one of the MX 456 records references a domain that contains an A or AAAA record 457 that exactly matches the input IP address. 459 2. No MX records exist for the domain, and an A or AAAA record for 460 the domain exactly matches the input IP address. 462 If any DNS lookup error other than domain not found occurs, the 463 client authorization function returns "unknown". 465 5.1.8 "r" element 467 Attributes: None 468 Child Elements: None 469 Character Data: IP address '/' count 471 This element matches iff the IP address in the character data is of 472 the same form as the input IP address (IPv4 or IPv6), and the two 473 addresses are equal when comparing only the most significant 'count' 474 bits. 476 5.2 Macro Expansion 478 This section defines the macro expansion that occurs on many of the 479 domain names in the EMail policy document. 481 5.2.1 Macro definitions 483 macro-string = *( macro-char / VCHAR ) 484 macro-char = ( "%{" ALPHA transformer *delimiter "}" ) 485 / "%%" / "%_" / "%-" 486 transformer = [ *DIGIT ] [ "r" ] 487 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 489 A literal "%" is expressed by "%%". 490 %_ expands to a single " " space. 491 %- expands to a URL-encoded space, viz. "%20". 493 The following macro letters are expanded in directive arguments: 495 l = local-part passed to the client authorization function. 496 s = Same as "%{l}@%{o}". 497 o = original domain passed to the client authorization function. 498 d = current domain passed to the client authorization function. 499 i = SMTP client IP (nibble format when an IPv6 address). 500 p = SMTP client domain name 501 v = client IP version string: "in-addr" for ipv4 or "ip6" for ipv6 502 r = domain name of the SMTP server. 504 The uppercase versions of all these macros are URL-encoded. 506 A '%' character not followed by a '{', '%', '-', or '_' character 507 MUST be interpreted as a literal. SPF publishers SHOULD NOT rely on 508 this feature; they MUST escape % literals. 510 Legal optional transformers are: 512 *DIGIT ; zero or more digits 513 'r' ; reverse value, splitting on dots by default 515 If transformers or delimiters are provided, the macro strings are 516 split into parts. After performing any reversal operation or removal 517 of left-hand parts, the parts are rejoined using "." and not the 518 original splitting characters. 520 By default, strings are split on "." (dots). Macros may specify 521 delimiter characters which are used instead of ".". Delimiters MUST 522 be one or more of the characters: 523 "." / "-" / "+" / "," / "/" / "_" / "=" 525 The 'r' transformer indicates a reversal operation: if the client IP 526 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 527 and the macro %{ir} would expand to "1.2.0.192". 529 The DIGIT transformer indicates the number of right-hand parts to use 530 after optional reversal. If a DIGIT is specified, it MUST be 531 nonzero. If no DIGITs are specified, or if the value specifies more 532 parts than are available, all the available parts are used. If the 533 DIGIT was 5, and only 3 parts were available, the macro interpreter 534 would pretend the DIGIT was 3. Implementations MAY limit the number, 535 but MUST support at least a value of 9. 537 For IPv4 addresses, both the "i" and "c" macros expand to the 538 standard dotted-quad format. 540 For IPv6 addresses, the "i" macro expands to dot-format address; it 541 is intended for use in %{ir}. The "c" macro may expand to any of the 542 hexadecimal colon-format addresses specified in [RFC3513] section 543 2.2. It is intended for humans to read. 545 Use of the "t" macro in DNS lookups would greatly reduce the 546 effectiveness of DNS caching. The "t" macro is only allowed in 547 explanation records. The value of the "t" macro SHOULD NOT change 548 during the evaluation of a given SPF record. 550 The "p" macro expands to the validated domain name of the SMTP 551 client. The validation procedure is described in section 4.6. If 552 there are no validated domain names, the word "unknown" is 553 substituted. If multiple validated domain names exist, the first one 554 returned in the PTR result is chosen. 556 The "r" macro expands to the name of the receiving MTA. This SHOULD 557 be a fully qualified domain name, but if one does not exist (as when 558 the checking is done by a script) or if policy restrictions dictate 559 otherwise, the word "unknown" SHOULD be substituted. The domain name 560 MAY be different than the name found in the MX record that the client 561 MTA used to locate the receiving MTA. 563 The "s" macro expands to the sender email address: a localpart, an @ 564 sign, and a domain. The "o" macro is the domain part of the "s". 566 They remain the same during a recursive "include" or "redirect" 567 subquery. 569 When the result of macro expansion is used in a domain name query, if 570 the expanded domain name exceeds 255 characters (the maximum length 571 of a domain name), the left side is truncated to fit, by removing 572 successive subdomains until the total length falls below 255 573 characters. 575 Uppercased macros are URL escaped. 577 URL encoding is described in [RFC2396]. 579 5.2.2 Expansion Examples 581 The is internet-draft@email.example.com. 582 The IPv4 SMTP client IP is 192.0.2.3. 583 The IPv6 SMTP client IP is 5f05:2000:80ad:5800::1. 584 The PTR domain name of the client IP is mx.example.org. 586 macro expansion 587 ------------------------------- 588 %{s} strong-bad@email.example.com 589 %{o} email.example.com 590 %{d} email.example.com 591 %{d4} email.example.com 592 %{d3} email.example.com 593 %{d2} example.com 594 %{d1} com 595 %{p} mx.example.org 596 %{p2} example.org 597 %{dr} com.example.email 598 %{d2r} example.email 599 %{l} internet-draft 600 %{l-} internet.draft 601 %{lr} internet-draft 602 %{lr-} draft-internet 603 %{l1r-} draft 605 macro-string expansion 606 --------------------------------------------------------------------- 607 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 608 %{lr-}.lp._spf.%{d2} draft.internet.lp._spf.example.com 610 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 611 Draft.internet.lp.3.2.0.192.in-addr._spf.example.com 613 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 614 3.2.0.192.in-addr.strong.lp._spf.example.com 616 %{p2}.trusted-domains.example.net 617 example.org.trusted-domains.example.net 619 IPv6: 620 %{ir}.example.org 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8. 621 5.d.a.0.8.0.0.0.2.5.0.f.5.example.org 623 5.3 Determining the EMail Policy Document for a Domain 625 In order to find the EMail policy document for a domain, the 626 following algorithm (or an algorithm that always yields the same 627 result) MUST be used. In this algorithm, "$DOMAIN" stands for the 628 domain whose EMail policy document is desired. 630 1. From DNS, obtain the set of TXT records for domain "_ep.$DOMAIN". 631 If the set contains exactly one TXT record, apply the 632 transformations in section 5.2.1 to that record. If the set is 633 empty, or if the domain "_ep.$DOMAIN" does not exist, continue to 634 step 2. If the set contains more than one record, or if any 635 other error occurs on the DNS lookup, the EMail policy document 636 cannot be obtained. 638 2. From DNS, obtain the set of TXT records for domain "$DOMAIN". If 639 the set contains exactly one record whose first string starts 640 with the characters "v=spf1 ", apply the transformations in 641 section 5.2.2 to that record to obtain the EMail policy document. 642 Otherwise, if domain "$DOMAIN" does not exist, continue to step 643 3. Otherwise, the EMail policy document cannot be obtained. 645 3. Any domain that does not exist is defined to have an EMail policy 646 document containing the XML Infoset described by the following 647 XML text: 649 650 651 652 653 654 656 5.3.1 From an XML TXT Record 658 Given a DNS TXT record from the "_ep" subdomain of the desired 659 domain, the EMail policy document is obtained as follows: 661 1. Append a CRLF to each string in the DNS record. 663 2. Concatenate all of the resulting strings together, in order. 664 3. Prefix the resulting string with the following: 665 666 674 4. Suffix the resulting string with the following: 675 677 5. If the resulting string is a well-formed and valid XML document, 678 the Infoset corresponding to that string is the domain's EMail 679 policy document. 681 6. If the resulting string is either not well-formed or not valid, 682 the EMail policy document for the domain cannot be determined. 684 XML namespace "urn:ietf:params:xml:schema:marid-1" is defined by this 685 specification, the "...:marid-2" through "...:marid-5" namespaces are 686 reserved for definition by future IETF consensus processes, and the 687 namespaces "http://www.w3.org/2001/XMLSchema" and 688 "http://www.w3.org/2000/09/xmldsig#" are defined by [XMLSchema] and 689 [RFC3275], respectively. 691 5.3.2 From an SPF TXT Record 693 << This text really needs to be rewritten. What follows gives the 694 concept, but isn't legalistic enough. It probably needs to stand 695 alone instead of referencing the SPF spec. >> 697 Given a TXT record from the desired domain that starts with the 698 characters "v=spf1 ", the EMail policy document is obtained via the 699 following algorithm. The namespace of all elements and attributes in 700 the resulting XML infoset is "urn:ietf:params:xml:schema:marid-1". 702 1. Start with the infoset described by the following XML text: 703 704 705 706 707 708 710 2. For each SPF mechanism in the input, create a new "m" node under 711 the "out" node. The "result" attribute of the "m" node is "pass", 712 "fail", "softFail" or "unknown", depending on whether the 713 mechanism's prefix is "+", "-", "~", or "?". 715 3. Unless the mechanism name is "all", create a new element under 716 the new "m" node, of a type as follows: 718 mechanism element 719 --------- ------- 720 a a 721 exists exists 722 include include 723 ip4 without "/" a 724 ip4 with "/" r 725 ip6 without "/" a 726 ip6 with "/" r 727 mx mx 728 ptr ptr 730 Place everything after the ":" (if any) into the character data 731 of the new element. 733 4. Treat any unknown mechanism as if it said "?all". 735 5. If there's a "redirect" modifier, set the "redirect" attribute of 736 the "out" node. 738 The resulting infoset is now complete. 740 6. Actions Based on the Decision 742 << To be written. >> 744 7. Security Considerations 746 This entire document describes a new mechanism for mitigating spoofed 747 email, which is today a pervasive security problem in the Internet. 749 Assuming that this mechanism is widely deployed, the following 750 sections describe counter-attacks that could be used to defeat this 751 mechanism. 753 7.1 DNS Attacks 754 The new mechanism is entirely dependent of DNS lookups, and is 755 therefore only as secure as DNS. An attacker bent on spoofing 756 messages could attempt to get his messages accepted by sending forged 757 answers to DNS queries. 759 An MTA could largely defeat such an attack by using a properly 760 paranoid DNS resolver. DNSSEC may ultimately provide a way to 761 completely neutralize this attack. 763 7.2 TCP Attacks 765 This mechanism is designed to be used in conjunction with SMTP over 766 TCP. A sufficiently resourceful attacker might be able to send TCP 767 packets with forged from-addresses, and thus execute an entire SMTP 768 session that appears to come from somewhere other than its true 769 origin. 771 Such an attack requires guessing what TCP sequence numbers an SMTP 772 server will use. It also requires transmitting completely in the 773 blind � the attack will be unable hear any of the server's side of 774 the conversation. 776 Attacks of this sort can be ameliorated if IP gateways refuse to 777 forward packets when the source address is clearly bogus. 779 7.3 Forged Resent-From Attacks 781 This mechanism chooses a purported responsible address from one of a 782 number of message headers, and then uses that address for validation. 783 A message with a true Resent-From header (for example), but a forged 784 From header will be accepted. Since many MUAs do not display all of 785 the headers of received messages, the message will appear to be 786 forged when displayed. 788 In order to avoid this attack, MUAs will need to start displaying at 789 least the header that was verified. 791 8. Extensibility Considerations 793 Many of the XML elements are defined to allow any attribute and any 794 child element. A program MUST ignore any element or attribute whose 795 meaning it does not understand. It will be easy to use new elements 796 and attributes to describe other pieces of email policy that are not 797 currently specified. For example, it may become appropriate to 798 define elements that allow a domain to specify how to complain about 799 spam from that domain, which accreditation agencies can vouch for the 800 domain, whether the domain is interested in answering challenges in 801 challenge / response systems, and so forth. 803 While it will be easy to add new kinds of information to the EMail 804 policy document, future implementers must proceed with extreme care 805 if they attempt to modify the semantics of the client authorization 806 function. Code that is not aware of the new semantics will 807 completely ignore any newly invented elements. 809 It is anticipated that extensions will only be defined for the XML 810 version of the DNS record, not for the SPF version. 812 With the final draft of this document, the 813 "urn:ietf:params:xml:schema:marid-1" namespace schema becomes frozen 814 for all time. Future extensions will need to use other namespaces. 815 In order to avoid avoid having to write very long namespaces in DNS 816 TXT records, the namespace prefixes "m2" through "m5" are defined at 817 this time, even though their referents will only be defined in the 818 future. Their referents, the namespaces 819 "urn:ietf:params:xml:schema:marid-2" through "...-5" are of the form 820 that they can only be defined by a future IETF consensus process. 822 9. Applicability Statement 824 This section describes the actions that certain members of the 825 Internet email ecosystem must take to be compliant with this 826 specification. 828 << Be more precise and prescriptive about what header to insert 829 where. >> 831 9.1 Simple EMailers 833 A domain that injects original email into the Internet, using its own 834 name in From headers, need do nothing to be compliant. However, such 835 domains SHOULD publish EMail policy records in DNS. 837 9.2 EMail Forwarders 839 A program that forwards received mail to other addresses MUST add an 840 appropriate header that contains an email address that it is 841 authorized to use. Such programs SHOULD use the Resent-From header 842 for this purpose. 844 Most of today's forwarders already add an appropriate header 845 (although most of them use Delivered-To or some other nonstandard 846 header rather than Resent-From.) 848 9.3 Mailing List Servers 850 A mailing list server MUST add an appropriate header that contains an 851 email address that it is authorized to use. Such programs SHOULD use 852 the Resent-From header for this purpose. 854 Most of today's mailing list software already adds an appropriate 855 header (although most of them use Sender rather than Resent-From). 857 9.4 Third-Party Mailers 859 A program that sends mail on behalf of another user MUST add an 860 appropriate header than contains an email address that it is 861 authorized to use. Such programs SHOULD use the Sender header for 862 this purpose. 864 Many, but not all, of today's third-party mailers are already 865 compliant. 867 9.5 MTA Implementers 869 MTAs that are acting as SMTP servers SHOULD implement the checks 870 described in this document. 872 An MTA SHOULD limit the number of DNS lookups (or the time spent 873 performing the lookup) that it will perform in the process of 874 checking a message. Such a limit SHOULD permit at least 20 DNS 875 lookups. 877 9.6 MUA Implementers 879 When displaying a received message, an MUA SHOULD display the 880 purported responsible address as defined by this document whenever 881 that address differs from the From address. This display SHOULD be 882 in addition to the From address. 884 When a received message contains multiple headers that might be used 885 for the purported responsible address determination, an MUA should 886 consider displaying all of them. 888 10. IANA Considerations 890 The IANA is requested to register the following URI: 892 URI: urn:ietf:params:xml:schema:marid-1 893 Registrant Contact: IESG. 894 XML: The contents of Appendix B of this document 896 11. Patent Disclosure 898 << Write a statement to the effect that Microsoft has pending patents 899 whose claims cover some of this. Get appropriate wording about 900 licensing from the lawyers. The current intent is to retain the 901 commitment to RAND/RF (reasonable and nondiscriminatory, royalty- 902 free) licensing. >> 904 12. Acknowledgements 906 Variations on the idea of using a DNS record to check the legitimacy 907 of an email address have occurred multiple times. The earliest known 908 work is [RMX]; others include [SPF} and [CallerID]. 910 The current document borrows heavily from each of the above, and 911 incorporates many ideas proposed by many members of the MARID working 912 group. 914 13. References 916 13.1 Normative References 918 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 919 Requirement Levels", RFC 2119. 921 [RFC2026] S. Bradner, "The Internet Standards Process � Revision 922 3", RFC 2026. 924 [RFC3275] D. Eastlake et al, "XML-Signature Syntax and Processing", 925 RFC 3275. 927 [XMLSchema] "XML Schema Part 1: Structures", W3C Recommendation 2 May 928 2001, http://www.w3c.org/TR/2001/REC-xmlschema-1- 929 20010502/ 931 13.2 Informative References 933 [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical 934 Specification, 935 http://www.microsoft.com/mscorp/twc/privacy/spam_callerid 936 .mspx. 938 [CSV] D. Crocker, "Client SMTP Validation (CSV)", draft- 939 crocker-marid-smtp-validate-01. Work in progress. 941 [DK] M. Delany, "Domain-based Email Authentication Using 942 Public-Keys Advertised in the DNS (DomainKeys)", draft- 943 delany-domainkeys-base-00. Work in progress. 945 [MTAMARK] M. Stumpf, and S. Hoehne, "Marking Mail Transfer Agents 946 in Reverse DNS with TXT RRs", draft-stumpf-dns-mtamark- 947 02. Work in progress. 949 [RMX] H. Danisch, "The RMX DNS RR and method for lightweight 950 SMTP sender authorization", draft-danisch-dns-rr-smtp-04. 951 Work in progress. 953 [SMIME] B. Ramsdell (editor), "S/MIME Version 3 Message 954 Specification", RFC 2633. 956 [SPF] M. Lentczner and M. Weng, "Sender Policy Framework (SPF): 957 A Convention to Describe Hosts Authorized to Send SMTP 958 Traffic", draft-mengwong-spf-01. Work in progress. 960 [Submitter] E. Allman and H. Katz, "SMTP Service Extension for 961 Indicating the Responsible Submitter of an E-mail 962 Message", draft-ietf-marid-submitter-00. Work in 963 progress. 965 14. Authors' Addresses 967 Jim Lyon 968 Microsoft Corporation 969 One Microsoft Way 970 Redmond, WA 98052 971 USA 972 jimlyon@microsoft.com 974 Meng Weng Wong 975 Singapore 976 mengwong@dumbo.pobox.com 978 15. Full Copyright Statement 980 Copyright (C) The Internet Society (2004). All Rights Reserved. 982 This document and translations of it may be copied and furnished to 983 others, and derivative works that comment on or otherwise explain it 984 or assist in its implementation may be prepared, copied, published 985 and distributed, in whole or in part, without restriction of any 986 kind, provided that the above copyright notice and this paragraph are 987 included on all such copies and derivative works. However, this 988 document itself may not be modified in any way, such as by removing 989 the copyright notice or references to the Internet Society or other 990 Internet organizations, except as needed for the purpose of 991 developing Internet standards in which case the procedures for 992 copyrights defined in the Internet Standards process must be 993 followed, or as required to translate it into languages other than 994 English. 996 The limited permissions granted above are perpetual and will not be 997 revoked by the Internet Society or its successors or assigns. 999 This document and the information contained herein is provided on an 1000 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1001 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1002 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1004 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1006 Appendix A: A Brief Introduction to XML 1008 << To be written. >> 1010 Appendix B: XML Schema for urn:ietf:params:xml:schema:marid-1 1012 1013 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1028 1029 1030 1032 1034 1036 1038 1040 1042 1044 1045 1048 1049 1051 1053 1054 1055 1057 1058 1060 1062 1064 1065 1066 1068 1069 1071 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094