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