idnits 2.17.1 draft-katz-submitter-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 640. ** 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 Internet-Drafts being working documents -- 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 -- 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 6918 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'STD' is defined on line 511, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (ref. 'MSG-FORMAT') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2476 (ref. 'SUBMIT') (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 3668 (ref. 'STD') (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2554 (ref. 'SMTPAUTH') (Obsoleted by RFC 4954) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft E. Allman 3 Category: Experimental Sendmail, Inc 4 Document: draft-katz-submitter-01.txt H. Katz 5 Microsoft Corp 6 May 2005 8 SMTP Service Extension for 9 Indicating the Responsible Submitter of an E-mail Message 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-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 as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo defines an extension to the Simple Mail Transfer Protocol 35 (SMTP) service, which allows an SMTP client to specify the 36 responsible submitter of an e-mail message. The responsible 37 submitter is the e-mail address of the entity most recently 38 responsible for introducing a message into the transport stream. 39 This extension helps receiving e-mail servers efficiently determine 40 whether the SMTP client is authorized to transmit mail on behalf of 41 the responsible submitter's domain. 43 Conventions Used in This Document 45 In examples, "C:" and "S:" indicate lines sent by the client and 46 server respectively. 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 52 Table of Contents 54 1. Introduction...................................................2 55 2. The SUBMITTER Service Extension................................4 56 3. The SUBMITTER Keyword of the EHLO Command......................4 57 4. The SUBMITTER Parameter of the MAIL Command....................4 58 4.1 Setting the SUBMITTER Parameter Value......................5 59 4.2 Processing the SUBMITTER Parameter.........................5 60 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server..........6 61 5. Examples.......................................................6 62 5.1 Mail Submission............................................6 63 5.2 Mail Forwarding............................................7 64 5.3 Mobile User................................................8 65 5.4 Guest E-mail Service.......................................9 66 5.5 SUBMITTER Used on a Non-Delivery Report...................10 67 6. Security Considerations.......................................10 68 7. IANA Considerations...........................................11 69 8. References....................................................11 70 8.1 Normative References......................................11 71 8.2 Informative References....................................12 72 9. Acknowledgments...............................................12 73 10. Authors' Addresses...........................................12 74 11. Change History...............................................13 76 1. Introduction 78 The practice of falsifying the identity of the sender of an e-mail 79 message, commonly called "spoofing", is a prevalent tactic used by 80 senders of unsolicited commercial e-mail or "spam". This form of 81 abuse has highlighted the need to improve identification of the 82 "responsible submitter" of an e-mail message. 84 In this specification, the responsible submitter is the entity most 85 recently responsible for injecting a message into the e-mail 86 transport stream. The e-mail address of the responsible submitter 87 will be referred to as the "purported responsible address" (PRA) of 88 the message. The "purported responsible domain" (PRD) is the domain 89 portion of that address. 91 This specification codifies rules for encoding the purported 92 responsible address into the SMTP transport protocol. This will 93 permit receiving SMTP servers to efficiently validate whether or not 94 the SMTP client is authorized to transmit mail on behalf of the 95 responsible submitter's domain. 97 Broadly speaking, there are two possible approaches for determining 98 the purported responsible address; either from RFC 2821 [SMTP] 99 protocol data or from RFC 2822 [MSG-FORMAT] message headers. Each 100 approach has certain advantages and disadvantages. 102 Deriving the purported responsible domain from RFC 2821 data has the 103 advantage that validation can be performed before the SMTP client has 104 transmitted the message body. If spoofing is detected, then the SMTP 105 server has the opportunity, depending upon local policy, to reject 106 the message before it is ever transmitted. The disadvantage of this 107 approach is the risk of false positives, that is, incorrectly 108 concluding that the sender's e-mail address has been spoofed. There 109 are today legitimate reasons why the Internet domain names used in 110 RFC 2821 commands may be different from that of the sender of an e- 111 mail message. 113 Deriving the purported responsible domain from RFC 2822 headers has 114 the advantage that validation can usually be based on an identity 115 that is displayed to recipients by existing MUAs as the sender's 116 identity. This aids in detection of a particularly noxious form of 117 spoofing known as "phishing" in which a malicious sender attempts to 118 fool a recipient into believing that a message originates from an 119 entity well known to the recipient. This approach carries a lower 120 risk of false positives since there are fewer legitimate reasons for 121 RFC 2822 headers to differ from the true sender of the message. The 122 disadvantage of this approach is that it does require parsing and 123 analysis of message headers. In practice, much if not all the 124 message body is also transmitted since the SMTP protocol described in 125 RFC 2821 provides no mechanism to interrupt message transmission 126 after the DATA command has been issued. 128 It is desirable to unify these two approaches in a way that combines 129 the benefits of both while minimizing their respective disadvantages. 131 This specification describes just such a unified approach. It uses 132 the mechanism described in [SMTP] to describe an extension to the 133 SMTP protocol. Using this extension, an SMTP client can specify the 134 e-mail address of the entity most recently responsible for submitting 135 the message to the SMTP client in a new SUBMITTER parameter of the 136 SMTP MAIL command. SMTP servers can use this information to validate 137 that the SMTP client is authorized to transmit e-mail on behalf of 138 the Internet domain contained in the SUBMITTER parameter. 140 2. The SUBMITTER Service Extension 142 The following SMTP service extension is hereby defined: 144 (1) The name of this SMTP service extension is "Responsible 145 Submitter"; 147 (2) The EHLO keyword value associated with this extension is 148 "SUBMITTER"; 150 (3) The SUBMITTER keyword has no parameters; 152 (4) No additional SMTP verbs are defined by this extension; 154 (5) An optional parameter is added to the MAIL command using the 155 esmtp-keyword "SUBMITTER", and is used to specify the e-mail 156 address of the entity responsible for submitting the message for 157 delivery; 159 (6) This extension is appropriate for the submission protocol 160 [SUBMIT]. 162 3. The SUBMITTER Keyword of the EHLO Command 164 An SMTP server includes the SUBMITTER keyword in its EHLO response to 165 tell the SMTP client that the SUBMITTER service extension is 166 supported. 168 The SUBMITTER keyword has no parameters. 170 4. The SUBMITTER Parameter of the MAIL Command 172 The syntax of the SUBMITTER parameter is: 174 "SUBMITTER=" Mailbox 176 where Mailbox is the ABNF [ABNF] production defined in Section 4.1.2 177 of [SMTP]. Characters such as SP, "+" and "=" which may occur in 178 Mailbox but are not permitted in ESMTP parameter values MUST be 179 encoded as "xtext" as described in section 4 of [DSN]. 181 4.1 Setting the SUBMITTER Parameter Value 183 The purpose of the SUBMITTER parameter is to allow the SMTP client to 184 indicate to the server the purported responsible address of the 185 message directly in the RFC 2821 protocol. 187 Therefore, SMTP clients that support the Responsible Submitter 188 extension MUST include the SUBMITTER parameter on all messages. This 189 includes messages containing a null reverse-path in the MAIL command. 191 SMTP clients MUST set the SUBMITTER parameter value to the purported 192 responsible address of the message as defined in [PRA]. This also 193 applies to messages containing a null reverse-path. 195 In some circumstances, described in section 7 of [SENDER-ID], SMTP 196 clients may need to add RFC 2822 headers to the message in order to 197 ensure that the correct SUBMITTER parameter value can be set. 199 4.2 Processing the SUBMITTER Parameter 201 Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD 202 select the domain part of the SUBMITTER address value as the 203 purported responsible domain of the message, and SHOULD perform such 204 tests, including those defined in [SENDER-ID], as are deemed 205 necessary to determine whether the connecting SMTP client is 206 authorized to transmit e-mail messages on behalf of that domain. 208 If these tests indicate that the connecting SMTP client is not 209 authorized to transmit e-mail messages on behalf of the SUBMITTER 210 domain, the receiving SMTP server SHOULD reject the message and when 211 rejecting MUST use "550 5.7.1 Submitter not allowed." 213 If the receiving SMTP server allows the connecting SMTP client to 214 transmit message data, then the server SHOULD determine the purported 215 responsible address of the message by examining the RFC 2822 message 216 headers as described in [PRA]. If this purported responsible address 217 does not match the address appearing in the SUBMITTER parameter, the 218 receiving SMTP server MUST reject the message and when rejecting MUST 219 use "550 5.7.1 Submitter does not match header." 221 If no purported responsible address is found according to the 222 procedure defined in [PRA], the SMTP server SHOULD reject the message 223 and when rejecting MUST use "554 5.7.7 Cannot verify submitter 224 address." 226 Verifying MTAs are strongly urged to validate the SUBMITTER parameter 227 against the RFC 2822 headers; otherwise, an attacker can trivially 228 defeat the algorithm. 230 Note that the presence of the SUBMITTER parameter on the MAIL command 231 MUST NOT change the effective reverse-path of a message. Any 232 delivery status notifications must be sent to the reverse-path, if 233 one exists, as per section 3.7 of [SMTP] regardless of the presence 234 of a SUBMITTER parameter. If the reverse-path is null, delivery 235 status notifications MUST NOT be sent to the SUBMITTER address. 237 Likewise, the SUBMITTER parameter MUST NOT change the effective reply 238 address of a message. Replies MUST be sent to the From address or 239 the Reply-To address, if present, as described in section 3.6.2 of 240 [MSG-FORMAT] regardless of the presence of a SUBMITTER parameter. 242 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server 244 Notwithstanding the provisions of section 4.1 above, when an MTA 245 transmits a message to another MTA that does not support the 246 SUBMITTER extension, the forwarding MTA MUST transmit the message 247 without the SUBMITTER parameter. This should involve no information 248 loss, since the SUBMITTER parameter is required to contain 249 information derived from the message headers. 251 5. Examples 253 This section provides examples of how the SUBMITTER parameter would 254 be used. The following dramatis personae appear in the examples: 256 alice@example.com: the original sender of each e-mail message. 258 bob@company.com.example: the final recipient of each e-mail. 260 bob@almamater.edu.example: an email address used by Bob which he has 261 configured to forward mail to his office account at 262 bob@company.com.example. 264 alice@mobile.net.example: an e-mail account provided to Alice by her 265 mobile e-mail network carrier. 267 5.1 Mail Submission 269 Under normal circumstances, Alice would configure her MUA to submit 270 her message to the mail system using the SUBMIT protocol [SUBMIT]. 271 The MUA would transmit the message without the SUBMITTER parameter. 272 The SUBMIT server would validate that the MUA is allowed to submit a 273 message through some external scheme, perhaps SMTP Authentication 274 [SMTPAUTH]. Under most circumstances this would look like a normal, 275 authenticated SMTP transaction. The SUBMIT server would extract her 276 name from the RFC 2822 headers for use in the SUBMITTER parameters of 277 subsequent transmissions of the message. 279 5.2 Mail Forwarding 281 When Alice sends a message to Bob at his almamater.edu.example 282 account, the SMTP session from her SUBMIT server might look something 283 like this: 285 S: 220 almamater.edu.example ESMTP server ready 286 C: EHLO example.com 287 S: 250-almamater.edu.example 288 S: 250-DSN 289 S: 250-AUTH 290 S: 250-SUBMITTER 291 S: 250 SIZE 292 C: MAIL FROM: SUBMITTER=alice@example.com 293 S: 250 sender ok 294 C: RCPT TO: 295 S: 250 recipient ok 296 C: DATA 297 S: 354 okay, send message 298 C: (message body goes here) 299 C: . 300 S: 250 message accepted 301 C: QUIT 302 S: 221 goodbye 304 The almamater.edu.example MTA must now forward this message to 305 bob@company.com.example. Although the original sender of the message 306 is alice@example.com, Alice is not responsible for this most recent 307 retransmission of the message. That role is filled by 308 bob@almamater.edu.example who established the forwarding of mail to 309 bob@company.com.example. Therefore, the almamater.edu.example MTA 310 determines a new purported responsible address for the message, 311 namely bob@almamater.edu.example, and sets the SUBMITTER parameter 312 accordingly. The forwarding MTA also inserts a Resent-From header in 313 the message body to ensure the purported responsible address derived 314 from the RFC 2822 headers matches the SUBMITTER address. 316 S: 220 company.com.example ESMTP server ready 317 C: EHLO almamater.edu.example 318 S: 250-company.com.example 319 S: 250-DSN 320 S: 250-AUTH 321 S: 250-SUBMITTER 322 S: 250 SIZE 323 C: MAIL FROM: 324 SUBMITTER=bob@almamater.edu.example 325 S: 250 sender ok 326 C: RCPT TO: 327 S: 250 recipient ok 328 C: DATA 329 S: 354 okay, send message 330 C: Resent-From: bob@almamater.edu.example 331 C: Received By: ... 332 C: (message body goes here) 333 C: . 334 S: 250 message accepted 335 C: QUIT 336 S: 221 goodbye 338 5.3 Mobile User 340 Alice is at the airport and uses her mobile e-mail device to send a 341 message to Bob. The message travels through the carrier network 342 provided by mobile.net.example, but Alice uses her example.com 343 address on the From line of all her messages so that replies go to 344 her office mailbox. 346 Here is an example of the SMTP session between the MTAs at 347 mobile.net.example and almamater.edu.example. 349 S: 220 almamater.edu.example ESMTP server ready 350 C: EHLO mobile.net.example 351 S: 250-almamater.edu.example 352 S: 250-DSN 353 S: 250-AUTH 354 S: 250-SUBMITTER 355 S: 250 SIZE 356 C: MAIL FROM: 357 SUBMITTER=alice@mobile.net.example 358 S: 250 sender ok 359 C: RCPT TO: 360 S: 250 recipient ok 361 C: DATA 362 S: 354 okay, send message 363 C: Sender: alice@mobile.net.example 364 C: Received By: ... 365 C: (message body goes here) 366 C: . 367 S: 250 message accepted 368 C: QUIT 369 S: 221 goodbye 371 Note that mobile.net.example uses the SUBMITTER parameter to 372 designate alice@mobile.net.example as the responsible submitter for 373 this message. Further this MTA also inserts a Sender header to 374 ensure the purported responsible address derived from the RFC 2822 375 headers matches the SUBMITTER address. 377 Likewise, conventional ISPs may also choose to use the SUBMITTER 378 parameter to designate as the responsible submitter the user's 379 address on the ISP's network if that address is different from the 380 MAIL FROM address. This may be especially useful for ISPs that host 381 multiple domains or otherwise share MTAs among multiple domains. 383 When the message is subsequently forwarded by the 384 almamater.edu.example MTA, that MTA will replace the SUBMITTER 385 parameter with bob@almamater.edu.example as in section 5.2 and add 386 its own Resent-From header. 388 5.4 Guest E-mail Service 390 While on a business trip, Alice uses the broadband access facilities 391 provided by the Exemplar Hotel to connect to the Internet and send e- 392 mail. The hotel routes all outbound e-mail through its own SMTP 393 server, email.hotel.com.example. 395 The SMTP session for Alice's message to Bob from the Exemplar Hotel 396 would look like this: 398 S: 220 almamater.edu.example ESMTP server ready 399 C: EHLO email.hotel.com.example 400 S: 250-almamater.edu.example 401 S: 250-DSN 402 S: 250-AUTH 403 S: 250-SUBMITTER 404 S: 250 SIZE 405 C: MAIL FROM: 406 SUBMITTER=guest.services@email.hotel.com.example 407 S: 250 sender ok 408 C: RCPT TO: 409 S: 250 recipient ok 410 C: DATA 411 S: 354 okay, send message 412 C: Resent-From: guest.services@email.hotel.com.example 413 C: Received By: ... 414 C: (message body goes here) 415 C: . 416 S: 250 message accepted 417 C: QUIT 418 S: 221 goodbye 420 Note that email.hotel.com.example uses the SUBMITTER parameter to 421 designate a generic account guest.services@email.hotel.com.example as 422 the responsible submitter address for this message. A generic 423 account is used since Alice herself does not have an account at that 424 domain. Further this client also inserts a Resent-From header to 425 ensure the purported responsible address derived from the RFC 2822 426 headers with the SUBMITTER address. 428 As before, when the message is subsequently forwarded by the 429 almamater.edu.example MTA, that MTA will replace the SUBMITTER 430 parameter with bob@almamater.edu.example as in section 5.2 and add 431 its own Resent-From header. 433 5.5 SUBMITTER Used on a Non-Delivery Report 435 Alice sends an incorrectly addressed e-mail message and receives a 436 non-delivery report from a SUBMITTER-compliant server. 438 S: 220 example.com ESMTP server ready 439 C: EHLO almamater.edu.example 440 S: 250-example.com 441 S: 250-DSN 442 S: 250-AUTH 443 S: 250-SUBMITTER 444 S: 250 SIZE 445 C: MAIL FROM:<> SUBMITTER=mailer-daemon@almamater.edu.example 446 S: 250 OK 447 C: RCPT TO: 448 S: 250 OK 449 C: DATA 450 S: 354 OK, send message 451 C: (message body goes here) 452 C: . 453 S: 250 message accepted 454 C: QUIT 455 S: 221 goodbye 457 6. Security Considerations 459 This extension provides an optimization to allow an SMTP client to 460 identify the responsible submitter of an e-mail message in the SMTP 461 protocol, and to enable SMTP servers to perform efficient validation 462 of that identity before the message contents are transmitted. 464 It is, however, quite possible for an attacker to forge the value of 465 the SUBMITTER parameter. Furthermore, it is possible for an attacker 466 to transmit an e-mail message whose SUBMITTER parameter does not 467 match the purported responsible address of the message as derived 468 from the RFC 2822 headers. Therefore the presence of the SUBMITTER 469 parameter provides, by itself, no assurance of the authenticity of 470 the message or the responsible submitter. Rather, the SUBMITTER 471 parameter is intended to provide additional information to receiving 472 e-mail systems to enable then to efficiently determine the validity 473 of the responsible submitter, and specifically, whether the SMTP 474 client is authorized to transmit e-mail on behalf of the purported 475 responsible submitter's domain. Section 4.2 describes how receiving 476 e-mail systems should process the SUBMITTER parameter. 478 7. IANA Considerations 480 IANA is hereby requested to register the SUBMITTER SMTP service 481 extension. 483 8. References 485 8.1 Normative References 487 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 488 Specifications: ABNF", RFC 2234, November 1997. 490 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) 491 Service Extension for Delivery Status Notifications 492 (DSNs)", RFC 3461, January 2003. 494 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [MSG-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 498 2822, April 2001. 500 [PRA] Lyon, J., "Purported Responsible Address in E-mail 501 Messages", draft-lyon-senderid-pra-01, May 2005. 502 Work in progress. 504 [SENDER-ID] Lyon, J. and Meng Weng Wong, "Sender ID: 505 Authenticating E-mail", draft-lyon-senderid-core-01, 506 May 2005. Work in progress. 508 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 509 2476, December 1998. 511 [STD] Bradner, S., "Intellectual Property Rights in IETF 512 Technology", BCP 79, RFC 3668, February 2004. 514 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 515 2821, April 2001. 517 [SMTPAUTH] Meyers, J., "SMTP Service Extension for 518 Authentication", RFC 2554, March 1999. 520 8.2 Informative References 522 None. 524 9. Acknowledgments 526 The idea of an ESMTP extension to convey the identity of the 527 responsible sender of an e-mail message has many progenitors. Nick 528 Shelness suggested the idea in a private conversation with one of the 529 authors. Pete Resnick suggested a variant on the MARID mailing list. 530 The idea was also discussed on the Anti-Spam Research Group (ASRG) 531 mailing list. 533 The authors would also like to thank the participants of the MARID 534 working group and the following individuals for their comments and 535 suggestions, which greatly improved this document: 537 Robert Atkinson, Simon Attwell, Roy Badami, Greg Connor, Dave 538 Crocker, Matthew Elvey, Tony Finch, Ned Freed, Mark Lentczner, Jim 539 Lyon, Bruce McMillan, Sam Neely, Daryl Odnert, Margaret Olson, Pete 540 Resnick, Hector Santos, Nick Shelness, Rand Wacker, Meng Weng Wong 542 10. Authors' Addresses 544 Eric Allman 545 Sendmail, Inc. 546 6425 Christie Ave, Suite 400 547 Emeryville, CA 94608 548 USA 550 E-mail: eric@sendmail.com 552 Harry Katz 553 Microsoft Corp. 554 1 Microsoft Way 555 Redmond, WA 98052 556 USA 558 E-mail: hkatz@microsoft.com 560 11. Change History 562 The following changes were made in draft-katz-submitter-00: 564 - in 4.2, added a paragraph noting that the SUBMITTER parameter is 565 not to be used as a reply address. 566 - in 5.3, added wording to note that this example also applies to 567 ISPs hosting multiple domains. 568 - added more detail to Acknowledgements section. 569 - minor wording changes and corrections throughout. 571 The following changes were made in draft-ietf-marid-submitter-03: 573 - in 1, amended wording about the advantages of basing validation on 574 RFC 2822 headers. 575 - in 4.1, amended wording to use "null reverse-path" to conform with 576 RFC 2821 terminology. 577 - in 4.1, made SUBMITTER a MUST on all messages for conformance. 578 - in 4.2, changed SHOULD reject to MUST reject when SUBMITTER value 579 does not match PRA value derived from headers. 580 - in 4.2, added a paragraph noting that the SUBMITTER parameter is 581 not to be used as a reverse-path address. 582 - added 5.5, example of SUBMITTER usage when reverse path is null. 583 - changed several references from [SENDER-ID] to [PRA] to reflect 584 creation of separate [PRA] document. 585 - minor wording changes and corrections throughout. 587 The following changes were made in draft-ietf-marid-submitter-02: 589 - on title page, updated the intellectual property declaration to be 590 consistent with RFC 3668. 591 - in 1, reworked text removing references to various anti-spoofing 592 proposals and clarifying the definition of several terms used 593 herein. 594 - in 4, removed redundant text from the first paragraph 595 - in 4.1, strengthened the conformance requirements and added the 596 recommendation for inclusion of the SUBMITTER parameter even when 597 the MAIL FROM address is identical to the purported responsible 598 address. 599 - in 4.1, removed wording about making the SUBMITTER parameter 600 mandatory at some future time. 601 - in 4.1, moved the procedural descriptions for initial message 602 submission and subsequent message retransmission to the non- 603 normative Examples section. 604 - in 4.2, removed the wording about procedures to be used at some 605 future time when the SUBMITTER parameter becomes mandatory 606 - in 4.2, significant rewording to simplify and clarify the 607 verification process and error messages. 608 - in 4.3, clarified the wording to include all cases of message 609 transmission to a non-SUBMITTER aware server. 611 - in 5, changed example addresses to be compliant with RFC 2606 612 - in 6, rewording and focus on security considerations specific to 613 this proposal 614 - added 7, IANA Considerations 615 - in 8, removed unreferenced informative references 616 - minor wording changes throughout. 618 Intellectual Property Statement 620 The IETF takes no position regarding the validity or scope of any 621 Intellectual Property Rights or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; nor does it represent that it has 625 made any independent effort to identify any such rights. Information 626 on the procedures with respect to rights in RFC documents can be 627 found in BCP 78 and BCP 79. 629 Copies of IPR disclosures made to the IETF Secretariat and any 630 assurances of licenses to be made available, or the result of an 631 attempt made to obtain a general license or permission for the use of 632 such proprietary rights by implementers or users of this 633 specification can be obtained from the IETF on-line IPR repository at 634 http://www.ietf.org/ipr. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights that may cover technology that may be required to implement 639 this standard. Please address the information to the IETF at ietf- 640 ipr@ietf.org. 642 Disclaimer of Validity 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 648 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 649 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Copyright Statement 654 Copyright (C) The Internet Society (2005). This document is subject 655 to the rights, licenses and restrictions contained in BCP 78, and 656 except as set forth therein, the authors retain all their rights. 658 Acknowledgment 660 Funding for the RFC Editor function is currently provided by the 661 Internet Society.