idnits 2.17.1 draft-lyon-senderid-core-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 783. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 773. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When performing the Sender-ID test after accepting an e-mail message for delivery, an MTA receiving this result SHOULD not deliver the message. Instead, it should create a DSN message, consistent with the usual rules for DSN messages. -- 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 (May 2005) is 6920 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'DMP' is mentioned on line 689, but not defined == Missing Reference: 'Green' is mentioned on line 693, but not defined == Unused Reference: 'CallerID' is defined on line 721, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-schlitt-spf-classic-00 == Outdated reference: A later version (-01) exists of draft-katz-submitter-00 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Lyon 3 Category: Experimental Microsoft Corp 4 Document: draft-lyon-senderid-core-01.txt M. Wong 5 pobox.com 6 May 2005 8 Sender ID: Authenticating E-Mail 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 Internet mail suffers from the fact that much unwanted mail is sent 36 using spoofed addresses -- "spoofed" in this case means the address 37 is used without the permission of the domain owner. This document 38 describes a family of tests by which SMTP servers can determine 39 whether an e-mail address in a received message was used with the 40 permission of the owner of the domain contained in that e-mail 41 address. 43 Table of Contents 45 1. Introduction...................................................3 46 2. Problem Statement..............................................3 47 3. SPF Records....................................................4 48 3.1 Version and Scope..........................................4 49 3.2 Multiple Records...........................................5 50 3.3 Positional Modifiers.......................................4 51 3.4 Compatibility..............................................7 52 4. Decision Model.................................................7 53 4.1 Arguments..................................................8 54 4.2 Results....................................................8 55 4.3 Record Lookup..............................................8 56 4.4 Record Selection...........................................8 57 5. Actions Based on the Decision..................................9 58 5.1 Neutral, None, SoftFail or PermError.......................9 59 5.2 Pass.......................................................9 60 5.3 Fail......................................................10 61 5.4 TempError.................................................10 62 6. Security Considerations.......................................11 63 6.1 DNS Attacks...............................................11 64 6.2 TCP Attacks...............................................11 65 6.3 Forged Sender Attacks.....................................11 66 6.4 Address Space Hijacking...................................12 67 6.5 Malicious DNS attacks on third-parties....................12 68 7. Implementation Guidance.......................................13 69 7.1 Simple E-mailers..........................................13 70 7.2 E-Mail Forwarders.........................................13 71 7.3 Mailing List Servers......................................14 72 7.4 Third-Party Mailers.......................................14 73 7.5 MUA Implementers..........................................15 74 8. IANA Considerations...........................................15 75 9. Acknowledgements..............................................16 76 10. References...................................................16 77 10.1 Normative References.....................................16 78 10.2 Informative References...................................16 79 11. Authors' Addresses...........................................17 81 Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 1. Introduction 89 Today, a huge majority of unwanted e-mail contains headers that lie 90 about the origin of the mail. This is true of most spam and 91 substantially all of the virus e-mail that is sent. 93 This document describes a mechanism such that receiving MTAs, MDAs 94 and/or MUAs can recognize mail in the above category and take 95 appropriate action. For example, an MTA might refuse to accept a 96 message, an MDA might discard a message rather than placing it into a 97 mailbox, and an MUA might render that message in some distinctive 98 fashion. 100 In order to avoid further fragmentation of the Internet e-mail 101 system, it is desirable that the Internet community as a whole come 102 to a consensus as to what mail senders should do to make their mail 103 appear non-spoofed, and how mail receivers should determine whether 104 mail is spoofed. On the other hand, it is not necessary to reach a 105 consensus regarding the actions that various parties take once a 106 message has been determined to be spoofed. This can be done one 107 unilaterally -- agent might decide to discard a spoofed message while 108 another decides to add a disclaimer. 110 This document defines a pair of closely-related tests. One validates 111 a message's Purported Responsible Address (PRA) as defined in [PRA]. 112 The other validates a message's Reverse-Path (also known as MAIL-FROM 113 address) as defined in [SPF]. 115 An e-mail sender complying with this specification SHOULD publish 116 information for both tests, and SHOULD arrange that any mail that is 117 sent will pass both tests. An e-mail receiver complying with this 118 specification SHOULD perform at least one of these tests. 120 2. Problem Statement 122 Briefly stated, the mechanisms of this document allow one to answer 123 the following question: 125 When a message is transferred via SMTP between two unrelated 126 parties, does the SMTP client host have permission to send mail 127 on behalf of a mailbox referenced by the message? 129 As seen from the question, this mechanism applies to unrelated 130 parties: it is useful at the point where a message passes across the 131 Internet from one organization to another. It is beyond the scope of 132 this document to describe authentication mechanisms that can be 133 deployed within an organization. 135 The PRA version of the test seeks to authenticate the mailbox 136 associated with the most recent introduction of a message into the 137 mail delivery system. In simple cases, this is who the mail is from. 138 However, in the case of a third-party mailer, a forwarder or a 139 mailing list server, the address being authenticated is that of the 140 third party, the forwarder or the mailing list. 142 On the other hand, the MAIL-FROM version of the test seeks to 143 authenticate the mailbox that would receive Delivery Status 144 Notifications (DSNs, or bounces) for the message. In simple cases, 145 this too is who the mail is from. However, third-party mailers, 146 forwarders and mailing list servers MUST specify an address under 147 their control, and SHOULD arrange that DSNs received at this address 148 are forwarded to the original bounce address. 150 In both cases, the domain associated with an e-mail address is what 151 is authenticated; no attempt is made to authenticate the local-part. 152 A domain owner gets to determine which SMTP clients speak on behalf 153 of addresses within the domain; a responsible domain owner should not 154 authorize SMTP clients that will lie about local parts. 156 In the long run, once the domain of the sender is authenticated, it 157 will be possible to use that domain as part of a mechanism to 158 determine the likelihood that a given message is spam, using, for 159 example, reputation and accreditation services. (These services are 160 not the subject of the present mechanism, but it should enable them.) 162 3. SPF 2.0 Records 164 Domains declare which hosts are and are not authorized to transmit 165 e-mail messages on their behalf by publishing Sender Policy Framework 166 records in the Domain Name System. [SPF] defines a format for these 167 records identified by the version prefix "v=spf1". This section 168 defines an amended format, identified by the version prefix 169 "spf2.0", that allows sending domains to explicitly specify how their 170 records should be interpreted, and provides for additional 171 extensibility. Sending domains MAY publish either or both formats. 173 Since the two formats are identical in most respects, the following 174 sub-sections define the "spf2.0" format relative to [SPF]. 176 3.1 Version and Scope 178 Under Sender ID, receiving domains may perform a check of either the 179 PRA identity or the MAIL-FROM identity. Sending domains therefore 180 require a method for declaring whether their published list of 181 authorized outbound e-mail servers can be used for the PRA check, 182 the MAIL-FROM check or both. 184 This section replaces section 4.5 of [SPF] and adds the concept of 185 SPF record scopes. 187 SPF records begin with a version identifier and may also include a 188 scope: 190 record = version terms *SP 191 version = "v=spf1" | ( "spf2." ver-minor scope) 192 ver-minor = 1*DIGIT 193 scope = "/" scope-id *( "," scope-id ) 194 scope-id = "mfrom" / "pra" / name 196 For example, the SPF record: 198 spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all 200 defines an SPF record that can be used for either MAIL FROM or PRA 201 checks. 203 This document only defines the existence of two scopes: "mfrom" and 204 "pra". The details of these two scopes are defined in other 205 documents: "mfrom" is defined in [SPF], "pra" is defined in [PRA]. 207 Other scopes may be defined by future documents only. There is no 208 registry for scopes. A scope definition must define what it 209 identifies as the sending mailbox for a message, how to extract that 210 information from a message, how to determine the initial arguments 211 for the check_host() function, and what the compliant responses to 212 the result are. This ensures that domains with published records and 213 mail receiver agree on the semantics of the scope. 215 A compliant domain SHOULD publish authorizations for every defined 216 scope. 218 3.1.1 Minor Version 220 All published records that use the "spf2" version identifier MUST 221 start with "spf2.0". This document only specifies records with a 222 minor version of "0". 224 Future versions of this document may define other minor versions to 225 be used. 227 3.2 Multiple Records 229 A domain MAY publish multiple SPF 2.0 records, provided that each 230 scope appears in at most one SPF 2.0 record. In addition, a domain 231 MAY also publish an SPF record that uses the "v=spf1" version 232 identifier defined in [SPF]. The selection rules in Section 4.4 233 define the precedence of these records. 235 3.3 Positional Modifiers 237 This section replaces section 4.6.3 of [SPF] and adds the concept of 238 positional modifiers. 240 Modifiers are key/value pairs that affect the evaluation of the 241 check_host() function. 243 Modifiers are either global or positional: 245 Global modifiers MAY appear anywhere in the record, but SHOULD 246 appear at the end, after all mechanisms and positional modifiers. 248 Positional modifiers apply only to the mechanism they follow. It 249 is a syntax error for a positional modifier to appear before the 250 first mechanism. 252 Modifiers of either type are also either singular or multiple: 254 Singular modifiers may appear only once in the record if they are 255 global, or once after each mechanism if they are positional. 257 Multiple modifiers may appear multiple times in the record if they 258 are global or multiple times after each mechanism if they are 259 positional. 261 A modifier is not allowed to be defined as both global and 262 positional. 264 The modifiers "redirect" and "exp" described in section 5 of [SPF] 265 are global and singular. 267 Ordering of modifiers does not matter, except: 268 1) positional modifiers must appear after the mechanism they 269 affect and before any subsequent mechanisms. 270 and 2) when a multiple modifier appears more than one time, the 271 ordering of the appearances may be significant to the 272 modifier. 273 Other than these constraints, implementations MUST treat different 274 orders of modifiers the same. An intended side effect of these rules 275 is modifiers cannot be defined that modify other modifiers. 277 These rules allow an implementation to correctly pre-parse a record. 278 Furthermore, they are crafted to allow the parsing algorithm to be 279 stable, even when new modifiers are introduced. 281 Modifiers which are unrecognized MUST be ignored. This allows older 282 implementations to handle records with modifiers that were defined 283 after they were written. 285 3.4 Compatibility 287 Domain administrators complying with this specification are required 288 to publish information in DNS regarding their authorized outbound 289 e-mail servers. [SPF] describes a format for this information 290 identified by the version prefix "v=spf1". Many domains have 291 published information in DNS using this format. In order to 292 provide compatibility for these domains, Sender ID implementations 293 SHOULD interpret the version prefix "v=spf1" as equivalent to 294 "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists. 296 Administrators who have already published "v=spf1" records SHOULD 297 review these records to determine whether they are also valid for use 298 with PRA checks. If the information in a "v=spf1" record is not 299 correct for a PRA check, administrators SHOULD publish either an 300 "spf2.0/pra" record with correct information, or an "spf2.0/pra ?all" 301 record indicating that the result of a PRA check is explicitly 302 inconclusive. 304 4. Decision Model 306 Sender ID enables receiving e-mail systems to answer the question: 308 Given an e-mail message, and given an IP address from which it has 309 been (or will be) received, is the SMTP client at that IP address 310 authorized to send that e-mail message? 312 This question will usually be asked by an SMTP server as part of 313 deciding whether to accept an incoming mail message. However, this 314 question could also be asked later by a different party. An MUA, for 315 example, could use the result of this question to determine how to 316 file or present a message. 318 There are three steps to answering this question: 320 (1) From an e-mail message, extract the address to verify. The PRA 321 variant of this test does so as specified in [PRA], or 322 alternatively, using the submitter address as specified in 323 [Submitter]. The MAIL FROM variant of this test does so as 324 specified in [SPF]. 326 (2) Extract the domain part of the address determined in step (1). 328 (3) Call the check_host() function defined in [SPF] and modified by 329 the following sub-sections. 331 If the Sender ID check is being performed by an MTA as part of 332 receiving an e-mail message, and it cannot determine an address in 333 step (1) above (because the message or address is malformed), then 334 the message SHOULD be rejected with error "550 5.7.1 Missing 335 Purported Responsible Address" or error "550 5.7.1 Missing Reverse- 336 Path address". 338 4.1 Arguments 340 Sender ID modifies the check_host() function by the addition of a 341 scope parameter. Thus, for Sender ID the check_host() function is 342 called passing the following parameters: 343 a. A scope of "pra" (for the PRA variant of the test), or 344 "mfrom" (for the MAIL FROM variant of the test). 345 b. The IP address (either IPv4 or IPv6) from which the message 346 is being or has been received. 347 c. The domain from step (2) above. 348 d. The address from step (1) above. 350 4.2 Results 352 The result of the check_host() function is one of the values 353 "Neutral", "Pass", "Fail", "SoftFail", "None", "TempError" or 354 "PermError". Section 5 describes how these results are used by MTAs 355 receiving messages. This specification imposes no requirements on 356 parties performing this test in other environments. 358 4.3 Record Lookup 360 SPF records are looked up in DNS in accordance with section 4.4 of 361 [SPF}. 363 When performing the PRA version of the test, if the DNS query returns 364 "non-existent domain" (RCODE 3), then check_host() exits immediately 365 with the result "Fail". 367 4.4 Record Selection 369 This section replaces the record selection steps described in section 370 4.5 of [SPF]. 372 Starting with the set of records that were returned by the lookup, 373 record selection proceeds in these steps: 375 1. If any records of type SPF are in the set, then all records of 376 type TXT are discarded. 378 2. Records that do not begin with proper version and scope sections 379 are discarded. The version section for "spf2" records contains a 380 ver-minor field that is for backward compatible future 381 extensions. This field must be well-formed for a record to be 382 retained, but is otherwise ignored. 384 3. Records that use the "spf2" version identifier and do not have a 385 scope-id that matches are discarded. Note that this is a 386 complete string match on the scope-id tokens: If is "pra", 387 then the record starting "spf2.0/mfrom,prattle,fubar" would be 388 discarded, but a record starting "spf2.0/mfrom,pra,fubar" would be 389 retained. 391 4. If the lookup returned two records, one containing the "v=spf1" 392 version identifier and the other containing the "spf2" 393 version identifier, the "spf2" version takes precedence for the 394 desired scope-id. If the "spf2" record does not contain the 395 desired scope-id, then the "v=spf1" record is selected. 397 5. If an "spf2" record does not contain the desired scope-id and 398 there is no "v=spf1" record for the domain, then no record is 399 selected. 401 After the above steps, there should be one record remaining and 402 evaluation can proceed. If there are two or more records remaining, 403 then check_host() exits immediately with the error "PermError". 405 If the PRA version of the test is being performed and no records 406 remain, the requirement in [SPF] to find the Zone Cut and repeat the 407 above steps is OPTIONAL. 409 If there are no matching records remaining after the initial DNS 410 query or any subsequent optional DNS queries, then check_host() 411 exits immediately with the result "None". 413 5. Actions Based on the Decision 415 When the Sender ID test is used by an SMTP server as part of 416 receiving a message, the server should take the actions described by 417 this section. 419 The check_host() function returns one of the following results. See 420 [SPF] for the meaning of these results. 422 5.1 Neutral, None, SoftFail or PermError 424 An SMTP server receiving one of these results SHOULD NOT reject the 425 message for this reason alone, but MAY subject the message to 426 heightened scrutiny by other measures, and MAY reject the message as 427 a result of this heightened scrutiny. 429 Such additional security measures MAY take into account that a 430 message for which the result is "SoftFail" is less likely to be 431 authentic than a message for which the result is "Neutral". 433 5.2 Pass 435 An SMTP server receiving this result SHOULD treat the message as 436 authentic. It may accept or reject the message depending on other 437 policies. 439 5.3 Fail 441 When performing the Sender-ID test during an SMTP transaction, an MTA 442 receiving this result SHOULD reject the message with a "550 5.7.1 443 Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with 444 "PRA" or "MAIL FROM", "yyy" is replaced with the additional reason 445 returned by the check_host() function and "zzz" is replaced with the 446 explanation string returned by the check_host() function. 448 When performing the Sender-ID test after accepting an e-mail message 449 for delivery, an MTA receiving this result SHOULD not deliver the 450 message. Instead, it should create a DSN message, consistent with the 451 usual rules for DSN messages. 453 5.4 TempError 455 An SMTP server receiving this result MAY reject the message with a 456 "450 4.4.3 Sender ID check is temporarily unavailable" error code. 457 Alternatively, an SMTP server receiving this result MAY accept a 458 message and optionally subject it to heightened scrutiny by other 459 anti-spam measures. 461 6. Security Considerations 463 This entire document describes a new mechanism for mitigating spoofed 464 e-mail, which is today a pervasive security problem in the Internet. 466 Assuming that this mechanism is widely deployed, the following 467 sections describe counter-attacks that could be used to defeat this 468 mechanism. 470 6.1 DNS Attacks 472 The new mechanism is entirely dependent on DNS lookups, and is 473 therefore only as secure as DNS. An attacker bent on spoofing 474 messages could attempt to get his messages accepted by sending forged 475 answers to DNS queries. 477 An MTA could largely defeat such an attack by using a properly 478 paranoid DNS resolver. DNSSEC may ultimately provide a way to 479 completely neutralize this class of attacks. 481 6.2 TCP Attacks 483 This mechanism is designed to be used in conjunction with SMTP over 484 TCP. A sufficiently resourceful attacker might be able to send TCP 485 packets with forged from-addresses, and thus execute an entire SMTP 486 session that appears to come from somewhere other than its true 487 origin. 489 Such an attack requires guessing what TCP sequence numbers an SMTP 490 server will use. It also requires transmitting completely in the 491 blind - the attack will be unable hear any of the server's side of 492 the conversation. 494 Attacks of this sort can be ameliorated if IP gateways refuse to 495 forward packets when the source address is clearly bogus. 497 6.3 Forged Sender Attacks 499 This mechanism chooses an address to validate either from one of a 500 number of message headers or from the RFC2821 MAIL command, and then 501 uses that address for validation. A message with a true Resent-From 502 header or Return-Path, but a forged From header will be accepted. 503 Since many MUAs do not display all of the headers of received 504 messages, the message will appear to be forged when displayed. 506 In order to neutralize this attack, MUAs will need to start 507 displaying at least the address that was verified. In addition MTAs 508 could subject messages to heightened scrutiny when the validated 509 address differs from the From header. 511 6.4 Address Space Hijacking 513 This mechanism assumes the integrity of IP address space for 514 determining whether a given client is authorized to send messages 515 from a given PRA. In addition to the TCP attack given in section 516 6.2, a sufficiently resourceful attacker might be able to alter the 517 IP routing structure to permit two-way communication using a 518 specified IP address. It would then be possible to execute an SMTP 519 session that appears to come from an authorized address, without the 520 need to guess TCP sequence numbers or transmit in the blind. 522 Such an attack might occur if the attacker obtained access to a 523 router which participates in external BGP routing. Such a router 524 could advertise a more specific route to a rogue SMTP client, 525 temporarily overriding the legitimate owner of the address. 527 6.5 Malicious DNS attacks on third-parties 529 There is class of attacks in which an attacker A can entice a 530 participant P to send a malicious message to a victim V. 532 These attacks are undertaken by A citing the address of V in the SMTP 533 MAIL FROM request and then by causing P to generate (or invoke the 534 generation of) a Delivery Status Notification 'bounce' message 535 (RFC3464), which is sent to the victim V. 537 The attacker relies upon it being common practice to copy the 538 original message into the 'bounce' report, thereby causing the malice 539 to be sent onwards to V. 541 This mode of attack has the advantages (to the attacker) of 542 obfuscating the location of the host from which the attack was 543 mounted, and of possibly damaging the reputation of P by making it 544 appear that P originated or was an active participant in the sending 545 of the malicious message. 547 In current practice, A causes P to cause the 'bounce' by addressing 548 the original message to a non-existent recipient. 550 Sender-ID enables a new variant of this attack. 552 In this variant the attacker A sends a message whose PRA (section 4) 553 is selected by the attacker to be such that, when P undertakes the 554 Sender-ID test, a 'Fail' will result (section 5.3). 556 The message will be rejected (as the attacker intended) and a 557 malicious 'bounce' message may be generated and sent to the victim V. 559 7. Implementation Guidance 561 This section describes the actions that certain members of the 562 Internet e-mail ecosystem must take to be compliant with this 563 specification. 565 7.1 Simple E-mailers 567 A domain that injects original e-mail into the Internet, using its 568 own name in From headers, need do nothing to be compliant. However, 569 such domains SHOULD publish records in DNS as defined by [SPF] and 570 this specification. 572 In the majority of cases, the domain's published information will be 573 the same for both the PRA and MAIL FROM variants of this test. In 574 this case, domains SHOULD publish their information using an SPF 575 record with the prefix "v=spf1". Doing so will render their 576 published information usable by the older SPF protocol, too. (See 577 [SPF] for information on the SPF protocol.) 579 7.2 E-Mail Forwarders 581 In order to pass the PRA variant of the test, a program that forwards 582 received mail to other addresses MUST add an appropriate header that 583 contains an e-mail address that it is authorized to use. Such 584 programs SHOULD use the Resent-From header for this purpose. 586 In order to pass the MAIL FROM variant of the test, a program that 587 forwards received mail to other addresses MUST alter the MAIL FROM 588 address to an address under its control. Should that address 589 eventually receive a DSN relating to the original message, that DSN 590 SHOULD be forwarded to the original MAIL FROM address. However, if 591 this altered address receives any messages other than DSNs related to 592 the original message, these messages MUST NOT be forwarded to the 593 original MAIL FROM address; they SHOULD be refused during an SMTP 594 transaction. 596 Additionally, e-mail forwarders SHOULD publish Sender ID records for 597 their domains, and SHOULD use MTAs for which the Sender ID check 598 yields a "pass" result. 600 Some of today's forwarders already add an appropriate header 601 (although many of them use Sender rather than Resent-From.) Most of 602 them do not perform the address-rewriting specified above. 604 Note that an e-mail forwarder might receive a single message for two 605 or more recipients, each of whom requests forwarding to a new 606 address. In this case, the forwarder's MTA SHOULD transmit the 607 message to each new recipient individually, with each copy of the 608 message containing a different newly inserted Resent-From header 609 field. 611 7.3 Mailing List Servers 613 In order to pass the PRA variant of the test, a mailing list server 614 MUST add an appropriate header that contains an e-mail address that 615 it is authorized to use. Such programs SHOULD use the Resent-From 616 header for this purpose. 618 In order to pass the MAIL FROM variant of the test, a mailing list 619 server MUST alter the MAIL FROM address to an address under its 620 control. 622 Additionally, mailing list servers SHOULD publish Sender ID records 623 for their domains, and SHOULD use MTAs for which the Sender ID check 624 yields a "pass" result. 626 Most of today's mailing list software already adds an appropriate 627 header (although most of them use Sender rather than Resent-From), 628 and most of them already alter the MAIL FROM address. 630 7.4 Third-Party Mailers 632 In order to pass the PRA variant of this test, a program that sends 633 mail on behalf of another user MUST add an appropriate header that 634 contains an e-mail address that it is authorized to use. Such 635 programs SHOULD use the Sender header for this purpose. 637 In order to pass the MAIL FROM variant of this test, a program that 638 sends mail on behalf of another user MUST use a MAIL FROM address 639 that is under its control. Defining what the program does with any 640 mail received at that address is beyond the scope of this document. 642 Additionally, third-party mailers servers SHOULD publish Sender ID 643 records for their domains, and SHOULD use MTAs for which the Sender 644 ID check yields a "pass" result. 646 Many, but not all, of today's third-party mailers are already 647 compliant with the PRA variant of the test. The extent to which 648 mailers are already compliant with the MAIL FROM variant of this test 649 is unknown. 651 7.5 MUA Implementers 653 When displaying a received message, an MUA SHOULD display the 654 purported responsible address as defined by this document whenever 655 that address differs from the RFC 2822 From address. This display 656 SHOULD be in addition to the RFC 2822 From address. 658 When a received message contains multiple headers that might be used 659 for the purported responsible address determination, an MUA should 660 consider displaying all of them. That is, if a message contains 661 several Resent-From's, a Sender and a From, an MUA should consider 662 displaying all of them. 664 Sender ID also does not validate the display name that may be 665 transmitted along with an e-mail address. The display name is also 666 vulnerable to spoofing and other forms of attacks. In order to 667 reduce the occurrence and effectiveness of such attacks, MUA 668 implementers should consider methods to safeguard the display name. 669 This could include: 671 * Not presenting the display name to the user at all, or not 672 presenting the display name unless the corresponding e-mail 673 address is listed in the user's address book. 675 * Treating as suspicious any e-mail where the display name is itself 676 in the form of an e-mail address, especially when it differs from 677 the actual e-mail address in the header. 679 * Making it clear to users that the e-mail address has been checked 680 rather than the display name. 682 8. IANA Considerations 684 This document contains no actions for IANA. 686 9. Acknowledgements 688 This design is based on earlier work published in 2003 in [RMX] and 689 [DMP] drafts (by Hadmut Danisch and Gordon Fecyk respectively). The 690 idea of using a DNS record to check the legitimacy of an e-mail 691 address traces its ancestry to "Repudiating Mail From" draft by Paul 692 Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain- 693 Authorized SMTP Mail" draft by David Green [Green] who first 694 introduced this idea on namedroppers mailing list in 2002. 696 The current document borrows heavily from each of the above, and 697 incorporates ideas proposed by many members of the MARID working 698 group. The contributions of each of the above are gratefully 699 acknowledged. 701 10. References 703 10.1 Normative References 705 [PRA] J. Lyon, "Purported Responsible Address in E-Mail 706 Messages", draft-lyon-senderid-pra-01. Work in progress. 708 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 709 Requirement Levels", RFC 2119. 711 [SPF] M. Wong and W. Schlitt, "Sender Policy Framework: 712 Authorizing Use of Domains in E-Mail", draft- 713 schlitt-spf-classic-00. Work in progress. 715 [Submitter] E. Allman and H. Katz, "SMTP Service Extension for 716 Indicating the Responsible Submitter of an E-mail 717 Message", draft-katz-submitter-00. Work in progress. 719 10.2 Informative References 721 [CallerID] Microsoft Corporation, Caller ID for E-Mail Technical 722 Specification, 723 http://www.microsoft.com/mscorp/twc/privacy/spam_callerid 724 .mspx. 726 [Green} David Green, "Mail-Transmitter RR", 727 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ 728 msg00656.html, June 2002. 730 [RMX] H. Danisch, "The RMX DNS RR and method for lightweight 731 SMTP sender authorization", draft-danisch-dns-rr-smtp-04. 732 Work in progress. 734 [Vixie] Paul Vixie, "Repudiating Mail From", 735 http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ 736 msg00658.html, June 2002. 738 11. Authors' Addresses 740 Jim Lyon 741 Microsoft Corporation 742 One Microsoft Way 743 Redmond, WA 98052 744 USA 745 jimlyon@microsoft.com 747 Meng Weng Wong 748 Singapore 749 mengwong@dumbo.pobox.com 751 Intellectual Property Statement 753 The IETF takes no position regarding the validity or scope of any 754 Intellectual Property Rights or other rights that might be claimed to 755 pertain to the implementation or use of the technology described in 756 this document or the extent to which any license under such rights 757 might or might not be available; nor does it represent that it has 758 made any independent effort to identify any such rights. Information 759 on the procedures with respect to rights in RFC documents can be 760 found in BCP 78 and BCP 79. 762 Copies of IPR disclosures made to the IETF Secretariat and any 763 assurances of licenses to be made available, or the result of an 764 attempt made to obtain a general license or permission for the use of 765 such proprietary rights by implementers or users of this 766 specification can be obtained from the IETF on-line IPR repository at 767 http://www.ietf.org/ipr. 769 The IETF invites any interested party to bring to its attention any 770 copyrights, patents or patent applications, or other proprietary 771 rights that may cover technology that may be required to implement 772 this standard. Please address the information to the IETF at ietf- 773 ipr@ietf.org. 775 Disclaimer of Validity 777 This document and the information contained herein are provided on an 778 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 779 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 780 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 781 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 782 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 783 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 785 Copyright Statement 787 Copyright (C) The Internet Society (2005). This document is subject 788 to the rights, licenses and restrictions contained in BCP 78, and 789 except as set forth therein, the authors retain all their rights. 791 Acknowledgment 793 Funding for the RFC Editor function is currently provided by the 794 Internet Society.