idnits 2.17.1 draft-ietf-marid-submitter-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 553), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** 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 (July 2004) is 7218 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 475, 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) == Outdated reference: A later version (-03) exists of draft-ietf-marid-core-02 -- 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 (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MARID Working Group E. Allman 2 Internet Draft Sendmail, Inc 3 Document: draft-ietf-marid-submitter-02.txt H. Katz 4 Microsoft Corp 5 Expires: January 2005 July 2004 7 SMTP Service Extension for 8 Indicating the Responsible Submitter of an E-mail Message 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. [STD] 17 Internet-Drafts are working documents of Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo defines an extension to the Simple Mail Transfer Protocol 38 (SMTP) service, which allows an SMTP client to specify the 39 responsible submitter of an e-mail message. The responsible 40 submitter is the e-mail address of the entity most recently 41 responsible for introducing a message into the transport stream. 42 This extension helps receiving e-mail servers efficiently determine 43 whether the SMTP client is authorized to transmit mail on behalf of 44 the responsible submitter's domain. 46 Conventions Used in This Document 48 In examples, "C:" and "S:" indicate lines sent by the client and 49 server respectively. 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 55 Table of Contents 57 1. Introduction...................................................2 58 2. The SUBMITTER Service Extension................................4 59 3. The SUBMITTER Keyword of the EHLO Command......................4 60 4. The SUBMITTER Parameter of the MAIL Command....................4 61 4.1 Setting the SUBMITTER Parameter Value......................4 62 4.2 Processing the SUBMITTER Parameter.........................5 63 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server..........5 64 5. Examples.......................................................6 65 5.1 Mail Submission............................................6 66 5.2 Mail Forwarding............................................6 67 5.3 Mobile User................................................7 68 5.4 Guest E-mail Service.......................................8 69 6. Security Considerations........................................9 70 7. IANA Considerations...........................................10 71 8. References....................................................10 72 8.1 Normative References......................................10 73 8.2 Informative References....................................11 74 9. Acknowledgments...............................................11 75 10. Authors' Addresses...........................................11 76 11. Change History...............................................12 77 12. Full Copyright Statement.....................................13 79 1. Introduction 81 The practice of falsifying the identity of the sender of an e-mail 82 message, commonly called "spoofing", is a prevalent tactic used by 83 senders of unsolicited commercial e-mail or "spam". This form of 84 abuse has highlighted the need to improve identification of the 85 "responsible submitter" of an e-mail message. 87 In this specification, the responsible submitter is the entity most 88 recently responsible for injecting a message into the e-mail 89 transport stream. The e-mail address of the responsible submitter 90 will be referred to as the "purported responsible address" (PRA) of 91 the message. The "purported responsible domain" (PRD) is the domain 92 portion of that address. 94 This specification codifies rules for encoding the purported 95 responsible address into the SMTP transport protocol. This will 96 permit receiving SMTP servers to efficiently validate whether or not 97 the SMTP client is authorized to transmit mail on behalf of the 98 responsible submitter's domain. 100 Broadly speaking, there are two possible approaches for determining 101 the purported responsible address; either from RFC 2821 [SMTP] 102 protocol data or from RFC 2822 [MSG-FORMAT] message headers. Each 103 approach has certain advantages and disadvantages. 105 Deriving the purported responsible domain from RFC 2821 data has the 106 advantage that validation can be performed before the SMTP client has 107 transmitted the message body. If spoofing is detected, then the SMTP 108 server has the opportunity, depending upon local policy, to reject 109 the message before it is ever transmitted. The disadvantage of this 110 approach is the risk of false positives, that is, incorrectly 111 concluding that the sender's e-mail address has been spoofed. There 112 are today legitimate reasons why the Internet domain names used in 113 RFC 2821 commands may be different from that of the sender of an e- 114 mail message. 116 Deriving the purported responsible domain from RFC 2822 headers has 117 the advantage of basing the sender validation on an identity that can 118 be made visible to the end recipient of the message. This aids in 119 detection of a particularly noxious form of spoofing known as 120 "phishing" in which a malicious sender attempts to fool a recipient 121 into believing that a message originates from an entity well known to 122 the recipient. This approach carries a lower risk of false positives 123 since there are fewer legitimate reasons for RFC 2822 headers to 124 differ from the true sender of the message. The disadvantage of this 125 approach is that it does require parsing and analysis of message 126 headers. In practice, much if not all the message body is also 127 transmitted since the SMTP protocol described in RFC 2821 provides no 128 mechanism to interrupt message transmission after the DATA command 129 has been issued. 131 It is desirable to unify these two approaches in a way that combines 132 the benefits of both while minimizing their respective disadvantages. 134 This specification describes just such a unified approach. It uses 135 the mechanism described in [SMTP] to describe an extension to the 136 SMTP protocol. Using this extension, an SMTP client can specify the 137 e-mail address of the entity most recently responsible for submitting 138 the message to the SMTP client in a new SUBMITTER parameter of the 139 SMTP MAIL command. SMTP servers can use this information to validate 140 that the SMTP client is authorized to transmit e-mail on behalf of 141 the Internet domain contained in the SUBMITTER parameter. 143 2. The SUBMITTER Service Extension 145 The following SMTP service extension is hereby defined: 147 (1) The name of this SMTP service extension is "Responsible 148 Submitter"; 150 (2) The EHLO keyword value associated with this extension is 151 "SUBMITTER"; 153 (3) The SUBMITTER keyword has no parameters; 155 (4) No additional SMTP verbs are defined by this extension; 157 (5) An optional parameter is added to the MAIL command using the 158 esmtp-keyword "SUBMITTER", and is used to specify the e-mail 159 address of the entity responsible for submitting the message for 160 delivery; 162 (6) This extension is appropriate for the submission protocol 163 [SUBMIT]. 165 3. The SUBMITTER Keyword of the EHLO Command 167 An SMTP server includes the SUBMITTER keyword in its EHLO response to 168 tell the SMTP client that the SUBMITTER service extension is 169 supported. 171 The SUBMITTER keyword has no parameters. 173 4. The SUBMITTER Parameter of the MAIL Command 175 The syntax of the SUBMITTER parameter is: 177 "SUBMITTER=" Mailbox 179 where Mailbox is the ABNF [ABNF] production defined in Section 4.1.2 180 of [SMTP]. Characters such as SP, "+" and "=" which may occur in 181 Mailbox but are not permitted in ESMTP parameter values MUST be 182 encoded as "xtext" as described in section 4 of [DSN]. 184 4.1 Setting the SUBMITTER Parameter Value 186 The purpose of the SUBMITTER parameter is to allow the SMTP client to 187 indicate to the server the purported responsible address of the 188 message directly in the RFC 2821 protocol. 190 Therefore, SMTP clients that support the Responsible Submitter 191 extension MUST include the SUMBITTER parameter on all messages where 192 the purported responsible address, as defined in section 4 of 193 [SENDER-ID] differs from the MAIL FROM address. This includes 194 messages where the MAIL FROM address is empty or "<>". SMTP clients 195 SHOULD include the SUBMITTER parameter on messages where the 196 purported responsible address is the same as the MAIL FROM address. 198 Furthermore, SMTP clients MUST, if necessary, insert such RFC 2822 199 headers as defined in section 4 of [SENDER-ID] in order to ensure 200 that the purported responsible address determined from the RFC 2822 201 headers by the receiving SMTP server will match the SUBMITTER 202 address. 204 4.2 Processing the SUBMITTER Parameter 206 Receivers of e-mail messages sent with the SUBMITTER parameter SHOULD 207 select the domain part of the SUBMITTER address value as the 208 purported responsible domain of the message, and SHOULD perform such 209 tests, including those defined in [SENDER-ID], as are deemed 210 necessary to determine whether the connecting SMTP client is 211 authorized to transmit e-mail messages on behalf of that domain. 213 If these tests indicate that the connecting SMTP client is not 214 authorized to transmit e-mail messages on behalf of the SUBMITTER 215 domain, the receiving SMTP server SHOULD reject the message and when 216 rejecting MUST use "550 5.7.1 Submitter not allowed." 218 If the receiving SMTP server allows the connecting SMTP client to 219 transmit message data, then the server SHOULD determine the purported 220 responsible address of the message by examining the RFC 2822 message 221 headers as described in [SENDER-ID]. If this purported responsible 222 address does not match the address appearing in the SUBMITTER 223 parameter, the receiving SMTP server SHOULD reject the message and 224 when rejecting MUST use "550 5.7.1 Submitter does not match header." 226 If no purported responsible address is found according to the 227 procedure defined in [SENDER-ID], the SMTP server SHOULD reject the 228 message and when rejecting MUST use "554 5.7.7 Cannot verify 229 submitter address." 231 Verifying MTAs are strongly urged to validate the SUBMITTER parameter 232 against the RFC 2822 headers; otherwise, an attacker can trivially 233 defeat the algorithm. 235 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server 237 Notwithstanding the provisions of section 4.1 above, when an MTA 238 transmits a message to another MTA that does not support the 239 SUBMITTER extension, the forwarding MTA MUST transmit the message 240 without the SUBMITTER parameter. This should involve no information 241 loss, since the SUBMITTER parameter is required to contain 242 information derived from the message headers. 244 5. Examples 246 This section provides examples of how the SUBMITTER parameter would 247 be used. The following dramatis personae appear in the examples: 249 alice@example.com: the original sender of each e-mail message. 251 bob@company.com.example: the final recipient of each e-mail. 253 bob@almamater.edu.example: an email address used by Bob which he has 254 configured to forward mail to his office account at 255 bob@company.com.example. 257 alice@mobile.net.example: an e-mail account provided to Alice by her 258 mobile e-mail network carrier. 260 5.1 Mail Submission 262 Under normal circumstances, Alice would configure her MUA to submit 263 her message to the mail system using the SUBMIT protocol [SUBMIT]. 264 The MUA would transmit the message without the SUBMITTER parameter. 265 The SUBMIT server would validate that the MUA is allowed to submit a 266 message through some external scheme, perhaps SMTP Authentication 267 [SMTPAUTH]. Under most circumstances this would look like a normal, 268 authenticated SMTP transaction. The SUBMIT server would extract her 269 name from the RFC 2822 headers for use in the SUBMITTER parameters of 270 subsequent transmissions of the message. 272 5.2 Mail Forwarding 274 When Alice sends a message to Bob at his almamater.edu.example 275 account, the SMTP session from her SUBMIT server might look something 276 like this: 278 S: 220 almamater.edu.example ESMTP server ready 279 C: EHLO example.com 280 S: 250-almamater.edu.example 281 S: 250-DSN 282 S: 250-AUTH 283 S: 250-SUBMITTER 284 S: 250 SIZE 285 C: MAIL FROM: SUBMITTER=alice@example.com 286 S: 250 sender ok 287 C: RCPT TO: 288 S: 250 recipient ok 289 C: DATA 290 S: 354 okay, send message 291 C: (message body goes here) 292 C: . 293 S: 250 message accepted 294 C: QUIT 295 S: 221 goodbye 297 The almamater.edu.example MTA must now forward this message to 298 bob@company.com.example. Although the original sender of the message 299 is alice@example.com, Alice is not responsible for this most recent 300 retransmission of the message. That role is filled by 301 bob@almamater.edu.example who established the forwarding of mail to 302 bob@company.com.example. Therefore, the almamater.edu.example MTA 303 determines a new purported responsible address for the message, 304 namely bob@almamater.edu.example, and sets the SUBMITTER parameter 305 accordingly. The forwarding MTA also inserts a Resent-From header in 306 the message body to ensure the purported responsible address derived 307 from the RFC 2822 headers matches the SUBMITTER address. 309 S: 220 company.com.example ESMTP server ready 310 C: EHLO almamater.edu.example 311 S: 250-company.com.example 312 S: 250-DSN 313 S: 250-AUTH 314 S: 250-SUBMITTER 315 S: 250 SIZE 316 C: MAIL FROM: 317 SUBMITTER=bob@almamater.edu.example 318 S: 250 sender ok 319 C: RCPT TO: 320 S: 250 recipient ok 321 C: DATA 322 S: 354 okay, send message 323 C: Resent-From: bob@almamater.edu.example 324 C: Received By: ... 325 C: (message body goes here) 326 C: . 327 S: 250 message accepted 328 C: QUIT 329 S: 221 goodbye 331 5.3 Mobile User 333 Alice is at the airport and uses her mobile e-mail device to send a 334 message to Bob. The message travels through the carrier network 335 provided by mobile.net.example, but Alice uses her example.com 336 address on the From line of all her messages so that replies go to 337 her office mailbox. 339 Here is an example of the SMTP session between the MTAs at 340 consolidatedmessanger.net and almamater.edu.example. 342 S: 220 almamater.edu.example ESMTP server ready 343 C: EHLO mobile.net.example 344 S: 250-almamater.edu.example 345 S: 250-DSN 346 S: 250-AUTH 347 S: 250-SUBMITTER 348 S: 250 SIZE 349 C: MAIL FROM: 350 SUBMITTER=alice@mobile.net.example 351 S: 250 sender ok 352 C: RCPT TO: 353 S: 250 recipient ok 354 C: DATA 355 S: 354 okay, send message 356 C: Sender: alice@mobile.net.example 357 C: Received By: ... 358 C: (message body goes here) 359 C: . 360 S: 250 message accepted 361 C: QUIT 362 S: 221 goodbye 364 Note that mobile.net.example uses the SUBMITTER parameter to 365 designate alice@mobile.net.example as the responsible submitter for 366 this message. Further this MTA also inserts a Sender header to 367 ensure the purported responsible address derived from the RFC 2822 368 headers matches the SUBMITTER address. 370 Likewise, conventional ISPs may also choose to use the SUBMITTER 371 parameter to designate as the responsible submitter the user's 372 address on the ISP's network if that address is different from the 373 MAIL FROM address. 375 When the message is subsequently forwarded by the 376 almamater.edu.example MTA, that MTA will replace the SUBMITTER 377 parameter with bob@almamater.edu.example as in section 5.2 and add 378 its own Resent-From header. 380 5.4 Guest E-mail Service 382 While on a business trip, Alice uses the broadband access facilities 383 provided by the Exemplar Hotel to connect to the Internet and send e- 384 mail. The hotel routes all outbound e-mail through its own SMTP 385 server, email.hotel.com.example. 387 The SMTP session for Alice's message to Bob from the Exemplar Hotel 388 would look like this: 390 S: 220 almamater.edu.example ESMTP server ready 391 C: EHLO email.hotel.com.example 392 S: 250-almamater.edu.example 393 S: 250-DSN 394 S: 250-AUTH 395 S: 250-SUBMITTER 396 S: 250 SIZE 397 C: MAIL FROM: 398 SUBMITTER=guest.services@email.hotel.com.example 399 S: 250 sender ok 400 C: RCPT TO: 401 S: 250 recipient ok 402 C: DATA 403 S: 354 okay, send message 404 C: Resent-From: guest.services@email.hotel.com.example 405 C: Received By: ... 406 C: (message body goes here) 407 C: . 408 S: 250 message accepted 409 C: QUIT 410 S: 221 goodbye 412 Note that email.hotel.com.example uses the SUBMITTER parameter to 413 designate a generic account guest.services@email.hotel.com.example as 414 the responsible submitter address for this message. A generic 415 account is used since Alice herself does not have an account at that 416 domain. Further this client also inserts a Resent-From header to 417 ensure the purported responsible address derived from the RFC 2822 418 headers with the SUBMITTER address. 420 As before, when the message is subsequently forwarded by the 421 almamater.edu.example MTA, that MTA will replace the SUBMITTER 422 parameter with bob@almamater.edu.example as in section 5.2 and add 423 its own Resent-From header. 425 6. Security Considerations 427 This extension provides an optimization to allow an SMTP client to 428 identify the responsible submitter of an e-mail message in the SMTP 429 protocol, and to enable SMTP servers to perform efficient validation 430 of that identity before the message contents are transmitted. 432 It is, however, quite possible for an attacker to forge the value of 433 the SUBMITTER parameter. Furthermore, it is possible for an attacker 434 to transmit an e-mail message whose SUBMITTER parameter does not 435 match the purported responsible address of the message as derived 436 from the RFC 2822 headers. Therefore the presence of the SUBMITTER 437 parameter provides, by itself, no assurance of the authenticity of 438 the message or the responsible submitter. Rather, the SUBMITTER 439 parameter is intended to provide additional information to receiving 440 e-mail systems to enable then to efficiently determine the validity 441 of the responsible submitter, and specifically, whether the SMTP 442 client is authorized to transmit e-mail on behalf of the purported 443 responsible submitter's domain. Section 4.2 describes how receiving 444 e-mail systems should process the SUBMITTER parameter. 446 7. IANA Considerations 448 IANA is hereby requested to register the SUBMITTER SMTP service 449 extension. 451 8. References 453 8.1 Normative References 455 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 456 Specifications: ABNF", RFC 2234, November 1997. 458 [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) 459 Service Extension for Delivery Status Notifications 460 (DSNs)", RFC 3461, January 2003. 462 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 [MSG-FORMAT] Resnick, P., Ed., "Internet Message Format", RFC 466 2822, April 2001. 468 [SENDER-ID] Lyon, J. and Meng Weng Wong, "MTA Authentication 469 Records in DNS", draft-ietf-marid-core-02, July 2004. 470 Work in progress. 472 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 473 2476, December 1998. 475 [STD] Bradner, S., "Intellectual Property Rights in IETF 476 Technology", BCP 79, RFC 3668, February 2004. 478 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 479 2821, April 2001. 481 [SMTPAUTH] Meyers, J., "SMTP Service Extension for 482 Authentication", RFC 2554, March 1999. 484 8.2 Informative References 486 None. 488 9. Acknowledgments 490 The authors would like to thank the participants of the MARID working 491 group and the following individuals for their comments and 492 suggestions, which greatly improved this document: 494 Robert Atkinson, Simon Attwell, Roy Badami, Greg Connor, Dave 495 Crocker, Matthew Elvey, Tony Finch, Mark Lentczner, Jim Lyon, Bruce 496 McMillan, Sam Neely, Margaret Olson, Pete Resnick, Hector Santos, 497 Nick Shelness, Rand Wacker, Meng Weng Wong 499 10. Authors' Addresses 501 Eric Allman 502 Sendmail, Inc. 503 6425 Christie Ave, Suite 400 504 Emeryville, CA 94608 505 USA 507 E-mail: eric@sendmail.com 509 Harry Katz 510 Microsoft Corp. 511 1 Microsoft Way 512 Redmond, WA 98052 513 USA 515 E-mail: hkatz@microsoft.com 517 11. Change History 519 The following changes were made to this document in the -02 revision: 521 - on title page, updated the intellectual property declaration to be 522 consistent with RFC 3668. 523 - in 1, reworked text removing references to various anti-spoofing 524 proposals and clarifying the definition of several terms used 525 herein. 526 - in 4, removed redundant text from the first paragraph 527 - in 4.1, strengthened the conformance requirements and added the 528 recommendation for inclusion of the SUBMITTER parameter even when 529 the MAIL FROM address is identical to the purported responsible 530 address. 531 - in 4.1, removed wording about making the SUBMITTER parameter 532 mandatory at some future time. 533 - in 4.1, moved the procedural descriptions for initial message 534 submission and subsequent message retransmission to the non- 535 normative Examples section. 536 - in 4.2, removed the wording about procedures to be used at some 537 future time when the SUBMITTER parameter becomes mandatory 538 - in 4.2, significant rewording to simplify and clarify the 539 verification process and error messages. 540 - in 4.3, clarified the wording to include all cases of message 541 transmission to a non-SUBMITTER aware server. 542 - in 5, changed example addresses to be compliant with RFC 2606 543 - in 6, rewording and focus on security considerations specific to 544 this proposal 545 - added 7, IANA Considerations 546 - in 8, removed unreferenced informative references 547 - minor wording changes throughout. 549 12. Full Copyright Statement 551 Copyright (C) The Internet Society (2004). This document is subject 552 to the rights, licenses and restrictions contained in BCP 78 and 553 except as set forth therein, the authors retain all their rights. 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Intellectual Property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed 567 to pertain to the implementation or use of the technology described 568 in this document or the extent to which any license under such rights 569 might or might not be available; nor does it represent that it has 570 made any independent effort to identify any such rights. Information 571 on the procedures with respect to rights in RFC documents can be 572 found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use of 577 such proprietary rights by implementers or users of this 578 specification can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at ietf- 585 ipr@ietf.org. 587 Acknowledgement 589 Funding for the RFC Editor function is currently provided by the 590 Internet Society.