idnits 2.17.1 draft-kucherawy-sender-auth-header-00.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 12. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MAIL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '... of some debate, the header MAY appear...' RFC 2119 keyword, line 118: '...essage, or more than one result MAY be...' RFC 2119 keyword, line 119: '...ader, or a combination of these MAY be...' RFC 2119 keyword, line 209: '... The "method" MUST refer to an authe...' RFC 2119 keyword, line 217: '...ication test, it MUST add this header ...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. -- 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 (September 2004) is 7156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 364, but not defined ** Obsolete normative reference: RFC 2554 (ref. 'AUTH') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2822 (ref. 'MAIL') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. S. Kucherawy 2 Title: draft-kucherawy-sender-auth-header-00 Sendmail, Inc. 3 Expires: March 2005 September 2004 5 Message Header for Indicating Sender Authentication Status 7 Status of this Memo 9 By submitting this Internet-Draft, I certify that any applicable 10 patent or other IPR claims of which I am aware have been disclosed, 11 or will be disclosed, and any of which I become aware will be 12 disclosed, in accordance with RFC 3668. 14 This document may not be modified, and derivative works of it may not 15 be created, except to publish it as an RFC and to translate it into 16 languages other than English. 18 This document is an Internet-Draft and is subject to all provisions 19 of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This memo defines a new message header for use with [MAIL] messages 40 to indicate the results of sender authentication efforts to mail user 41 agents (MUAs) in order to equip them to relay that information in a 42 convenient way to users. 44 Table of Contents 45 1. Introduction 47 This memo defines a new message header for [MAIL] messages which 48 presents the results of a sender authentication effort in a machine- 49 readable format. The intent is to create a place to collect such 50 data when sender authentication mechanisms are in use so that an MUA 51 can provide a recommendation to the user as to the trustworthiness of 52 the message's origin and content. 54 This memo defines both the format of this new header, and discusses 55 the implications of its presence or absence. 57 At the time of publication of this draft, only [AUTH] is a published 58 sender authentication standard. However, several more are in the 59 Internet Draft stage. As various methods emerge, it is necessary to 60 prepare their appearance and encourage convergence in the area of 61 interfacing these filters to MUAs. 63 1.1. Purposes 65 The header defined in this memo is expected to serve several pur- 66 poses: 68 (1) Convey to MUAs from filters and MTAs the results of various sender 69 authentication checks being applied; 71 (2) Provide a common location for the presentation of this data; 73 (3) Create an extensible framework for specifying new authentication 74 methods as such emerge. 76 (4) Convey the results of sender authentication tests to later filter- 77 ing agents within the same "trust domain", as such agents might 78 apply more or less stringent checks based on sender authentication 79 results. 81 1.2. Requirements 83 This memo establishes no new requirements on existing protocols or 84 servers, as there is currently not a standard place for the described 85 data to be collected or presented. 87 1.3. Terminology 89 This document occasionally uses terms that appear in capital letters. 90 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 91 NOT", and "MAY" appear capitalized, they are being used to indicate 92 particular requirements of this specification. A discussion of the 93 meanings of these terms appears in RFC2119. 95 Generally it is assumed that the work of applying sender authentica- 96 tion schemes takes place at a border MTA, that is, an MTA which acts 97 as a gateway between the general Internet and the users within an 98 organizational boundary. This specification is written with that 99 assumption in mind. However, there are some sites at which the 100 entire mail infrastructure consists of a single host. In such cases, 101 such terms as "border MTA" and "delivery MTA" may well apply to the 102 same machine or even the very same agent. 104 2. Definition and Format of the Header 106 The new header being defined here is called "Authentication-Results". 107 It qualifies in [MAIL] terms as a Structured Header Field, and thus 108 all of the related definitions in that document apply. 110 The decommented value of the header consists of a hostname, some 111 whitespace, a "header=mailbox" statement indicating which header was 112 selected to determine who sent the message and what address was 113 extracted from that header, followed by zero or more authentication 114 method names and a result associated with each, returned by the code 115 that implements the method. 117 As it is currently a matter of some debate, the header MAY appear 118 more than once in a single message, or more than one result MAY be 119 represented in a single header, or a combination of these MAY be 120 applied. 122 Formally, the header is specified as follows: 124 header := "Authentication-Results" ":" hostname 1*LWSP headerspec 125 *(";" name "=" value) 127 hostname := Domain 128 ; as defined in [SMTP] 130 name := method 131 ; a method indicates which method's result is 132 ; is represented by "value", and is one of the methods 133 ; explicitly defined as valid in this document 134 ; or is an extension method as defined below 136 method := token 137 ; authentication method whose results are being relayed 139 value := result 141 result := "pass" / "fail" / "softfail" / "neutral" / 142 "temperror" / "permerror" 143 ; an indication of the results of the attempt to 144 ; authenticate the sender 146 token := ; As defined in Appendix A of [MIME] 148 LWSP := 0x20 (linear space) / 0x09 (horizontal tab) 150 addrspec := header "=" mailbox 151 ; an indication of which header was used to 152 ; determine the "true" sender of the message, 153 ; against which authentication tests were done 155 header := token 156 ; which header was used to determine the 157 ; "true" sender of the message being analyzed 159 mailbox := As defined in section 3.4 of [MAIL] 161 The six possible values of the "result" are: 163 pass 164 sending domain publishes an authentication policy of some kind, 165 and the message passed the authentication tests 167 fail 168 sending domain publishes an authentication policy of some kind, 169 and the message failed the authentication tests 171 softfail 172 sending domain publishes an authentication policy which doesn't 173 require authentication of all messages from that domain, and the 174 message failed the authentication tests 176 neutral 177 sending domain does not publish any sender authentication policy 179 temperror 180 a temporary (recoverable) error occurred attempting to authenti- 181 cate the sender; either the process couldn't be completed 182 locally because of some transient condition, or there was a tem- 183 porary failure retrieving the sending domain's policy; a later 184 attempt to re-authenticate this message might produce a more 185 final result 187 permerror 188 a permanent (unrecoverable) error occurred attempting to authen- 189 ticate the sender; either the process couldn't be completed 190 locally, or there was a permanent failure retrieving the sending 191 domain's policy 193 3. Definition Of The "auth" Method 195 As it is currently an existing standard for sender authentication, it 196 is appropriate to define an authentication method identifier for 197 [AUTH]. The authentication method identifier "auth" is thus defined 198 for MTAs applying that standard for sender authentication. 200 4. Adding The Header To A Message 202 This specification makes no attempt to evaluate the relative 203 strengths of various sender authentication methods that may become 204 available. As such, the order of the presented authentication meth- 205 ods and results are not relevant since ultimately the importance on 206 any given method over another is the decision of the MUA that is 207 interpreting the value of the header. 209 The "method" MUST refer to an authentication method declared in this 210 memo, or in a subsequent one, or to an authentication method name 211 assigned by IANA. 213 The three values of the "result" should be fairly self-evident; "yes" 214 indicates the sender was successfully authenticated, "no" indicates 215 the opposite, and "unknown" indicates no conclusion was possible. 217 If an MTA applies any authentication test, it MUST add this header to 218 indicate at which host the test was done, which test got applied, and 219 what the result was. If an MTA applies more than one such test, it 220 MUST either add this header once per test, or one header indicating 221 all of the results. An MTA MUST NOT add a result to an existing 222 header. 224 An MTA adding this header in either form MUST use its own hostname 225 only. It MUST be a fully-qualified domain name. 227 For security reasons, an MTA SHOULD remove any discovered instance of 228 this header for which the "hostname" is its own, i.e. headers which 229 claim to be from the MTA but were added before the mail arrived at 230 the MTA for processing. A border MTA MAY also delete any discovered 231 instance of this header which claims to have been added within its 232 trust boundary. For example, a border MTA at mx.example.com SHOULD 233 delete any instance of this header claiming to come from mx.exam- 234 ple.com and MAY delete any instance of this header claiming to come 235 from any host in example.com prior to adding its own headers. This 236 applies in both directions so that hosts outside the domain cannot 237 claim results MUAs inside the domain might trust. 239 An MTA compliant with this specification MUST add this header after 240 performing one or more sender authentication tests. An MTA MAY add 241 this header containing only the "hostname" portion to explicitly 242 indicate that no sender authentication schemes were applied prior to 243 delivery of this message. 245 4.1. Header Position and Interpretation 247 In order to ensure non-ambiguous results and avoid the impact of 248 false headers, an MUA SHOULD NOT interpret this header unless specif- 249 ically instructed to do so by the user. That is, this should not be 250 "on by default". Naturally then, users would not activate such a 251 feature unless they are certain the header will be added by the 252 receiving MTA that accepts the mail which is ultimately read by the 253 MUA, and instances of the header added by foreign MTAs will be 254 removed before delivery. 256 Furthermore, an MUA SHOULD NOT interpret this header unless the host- 257 name it bears appears to be one within its own trust domain as con- 258 figured by the user. 260 An MTA adding a header MUST add the header at the top of the message 261 so that there is generally some indication upon delivery of where in 262 the chain of handling MTAs the sender authentcation was done. 264 Further discussion of this can be found in the Security Considera- 265 tions section below. 267 4.2. Extension Fields 269 Additional authentication method identifiers may be defined in the 270 future by later revisions or extensions to this specification. 271 Extension identifiers beginning with "x-" will never be defined as 272 standard fields; such names are reserved for experimental use. 273 Method identifiers NOT beginning with "x-" MUST be registered with 274 the Internet Assigned Numbers Authority (IANA) and published in an 275 RFC. 277 Extension identifiers may be defined for the following reasons: 279 (a) To allow additional information from emergent authentication sys- 280 tems to be communicated to MUAs. The names of such identifiers 281 should reflect the name of the method being defined, but should not 282 be needlessly long. 284 (b) To allow the creation of "sub-identifiers" which indicate different 285 levels of authentication and differentiate between their relative 286 strengths, e.g. "auth1-weak" and "auth1-strong". 288 Authentication method implementors are encouraged to provide adequate 289 information, via [MAIL] comments if necessary, to allow an MUA devel- 290 oper to understand or relay ancilliary details of authentication 291 results. For example, if it might be of interest to relay what data 292 was used to perform an evaluation, such information could be relayed 293 as a comment in the header, such as: 295 Authentication-Results: mx.example.com; foo=yes (2 out of 3 tests 296 passed) 298 5. Discussion 300 This section discusses various implementation issues not specifically 301 related to security. Security issues are discussed in a later sec- 302 tion. 304 5.1. Legacy MUAs 306 Implementors of this proposal should be aware that many MUAs are 307 unlikely to be retrofit to support the new header and its semantics. 308 In the interests of convenience and quicker adaptation, a delivery 309 MTA might want to consider adding things that are processed by exist- 310 ing MUAs as well as the header defined by this specification. One 311 suggestion is to provide a Priority: header with a value that 312 reflects the strength of the authentication that was accomplished, 313 e.g. "low" for weak or no authentication, "normal" or "high" for good 314 authentication. 316 Certainly some modern MUAs can filter based on the content of this 317 header, but as there is keen interest in having MUAs make some kind 318 of graphical representation of this header's meaning, other interim 319 means of doing so may be necessary while this proposal is adopted. 321 5.2. Trusting The Header 323 Rather than the coding rigor of doing a digital signature on the con- 324 tent of this header, it may be sufficient to establish a maximum SMTP 325 path length between the addition of the header and final delivery. 326 The path length is defined as the count of Received headers above the 327 Authentication-Results header. If more than that maximum path length 328 is traversed between insertion of the header and delivery, the value 329 of the header should no longer be trusted to be valid. 331 This requires a configurable MUA setting to define this maximum path 332 length. The setting would need to take into account possible addi- 333 tional hops should the final delivery server be unavailable. 334 Although this approach likely bears a much shorter time to implement, 335 it is a less general solution than the proposed one and would proba- 336 bly require additional user education above the norm and thus lead to 337 more confusion on deployment. The MUA SHOULD trust this header if it 338 is trusting such headers and the path length after the addition of 339 the header is less than three. 341 6. Conformance and Usage Requirements 343 An MTA or gateway conforms to this specification if it applies one or 344 more sender authentication mechanisms and inserts a header corre- 345 sponding to this standard after doing so and prior to delivery. 347 MTAs that are relaying mail rather than delivering it MAY perform 348 sender authentication or even take actions based on the results 349 found, but MUST NOT add a "Authentication-Results" header if relaying 350 rather than rejecting or discarding at the gateway. Conversely, an 351 MTA doing local delivery MUST add this header prior to delivery the 352 message in order to be compliant. 354 A minimal implementation which does at least one sender authentica- 355 tion check will add the header defined by this memo prior to invoking 356 local delivery procedures. 358 This specification places no restrictions on the processing of the 359 header's contents by user agents or distribution lists. It is pre- 360 sented to those packages solely for their own information. 362 7. IANA Considerations 364 Following the policies outlined in [IANA-CONSIDERATIONS], names of 365 sender authentication methods supported by this specification must be 366 registered with IANA under the IETF Consensus method. 368 8. Security Considerations 370 The following security considerations apply when applying or process- 371 ing the "Authentication-Results" header: 373 8.1. Non-conformant MTAs 375 An MUA that is aware of this specification which accesses a mailbox 376 whose mail is handled by a non-conformant MTA is in a position to 377 make false conclusions based on forged headers. A malicious user or 378 agent could forge a header using the destination MX for a receiving 379 domain as the hostname token in the value of the header, and with the 380 rest of the value claim that the sender was properly authenticated. 381 The non-conformant MTA would fail to strip the forged header, and the 382 MUA could trust it. 384 It is for this reason an MUA SHOULD NOT have processing of the 385 "Authentication-Results" header enabled by default; instead it must 386 be ignored, at least for the purposes of enacting filtering deci- 387 sions, unless specifically enabled by the user after verifying that 388 the MTA is compliant. It is acceptable to have an MUA aware of this 389 standard, but have an explicit list of hostnames whose "Authentica- 390 tion-Results" headers are trustworthy, but this list SHOULD initially 391 be empty. 393 Proposed alternate solutions to this problem are nascent. Possibly 394 the simplest is a digital signature on the header which can be veri- 395 fied by a posted public key. Another would be a means to interrogate 396 the MTA that added the header to see if it is actually providing any 397 sender authentication services and saw the message in question. In 398 either case, a method needs to exist to verify that the host which 399 appears to have added the header (a) actually did so, and (b) is 400 legitimately adding that header for this delivery. 402 8.2. Header Position 404 Headers can sometimes be reordered enroute by intermediate MTAs. The 405 goal of requiring header addition only at the top of a message is an 406 acknowledgement that some MTAs do reorder headers, but most do not. 407 Thus, in the general case, there will be some indication of which 408 MTAs (if any) handled the message after the addition of the header 409 defined here. 411 However, this is not universally true. In an environment involving 412 an MTA that does reorder headers, the above-mentioned hop count test 413 for header validity may not be possible. 415 9. Appendix - Authentication-Results Examples 417 9.1. Trivial case; header not present 419 The trivial case: 421 From: sender@example.com 422 Received: from mail-router.example.com 423 (mail-router.example.com [1.2.3.4]) 425 by server.sendmail.com (8.11.6/8.11.6) 426 with ESMTP id g1G0r1kA003489; 427 Fri, Feb 15 2002 17:19:07 -0800 428 Date: Fri, Feb 15 2002 16:54:30 -0800 429 To: receiver@sendmail.com 430 Message-Id: <12345.abc@example.com> 431 Subject: here's a sample 433 Hello! Goodbye! 435 The "Authentication-Results" header is completely absent. The MUA 436 may make no conclusion about the validity of the message. This could 437 be the case because the sender authentication services were not 438 available at the time of delivery, or no service is provided, or the 439 MTA is not in compliance with this specification. 441 9.2. Nearly-trivial case; service provided, but no authentication done 443 A message that was delivered by an MTA which conforms to this stan- 444 dard but provides no actual sender authentication service: 446 Authentication-Results: mail-router.example.com 447 from=sender@example.com 448 From: sender@example.com 449 Received: from mail-router.example.com 450 (mail-router.example.com [1.2.3.4]) 451 by server.sendmail.com (8.11.6/8.11.6) 452 with ESMTP id g1G0r1kA003489; 453 Fri, Feb 15 2002 17:19:07 -0800 454 Date: Fri, Feb 15 2002 16:54:30 -0800 455 To: receiver@sendmail.com 456 Message-Id: <12345.abc@example.com> 457 Subject: here's a sample 459 Hello! Goodbye! 461 The "Authentication-Results" header is present, indicating the deliv- 462 ering MTA (which is named in the value of the header) conforms to 463 this specification. The absence of any method and result tokens 464 indicates no sender authentication was done. 466 9.3. Service provided, authentication done 468 A message that was delivered by an MTA which conforms to this 469 standard and applied some sender authentication: 471 Authentication-Results: mail-router.example.com 472 from=sender@example.com; auth=pass (cram-md5) 473 From: sender@example.com 474 Received: from dialup-1-2-3-4.example-isp.com 475 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 476 by mail-router.example.com (8.11.6/8.11.6) 477 with ESMTP id g1G0r1kA003489; 478 Fri, Feb 15 2002 17:19:07 -0800 479 Date: Fri, Feb 15 2002 16:54:30 -0800 480 To: receiver@sendmail.com 481 Message-Id: <12345.abc@example.com> 482 Subject: here's a sample 484 Hello! Goodbye! 486 The "Authentication-Results" header is present, indicating the deliv- 487 ering MTA (which is named in the value of the header) conforms to 488 this specification. Furthermore, the sender authenticated her- 489 self/himself to the MTA via a method specified in [AUTH]. The actual 490 method is identified in a header comment after the method's result is 491 indicated. The MUA could extract and relay this extra information if 492 desired. 494 9.4. Service provided, several authentications done, single MTA 496 A message that was relayed inbound via a single MTA which conforms to 497 this standard and applied two different sender authentication checks: 499 Authentication-Results: mail-router.example.com 500 from=sender@example.com; 501 auth=pass (cram-md5); spf=pass; sender-id=pass 502 From: sender@example.com 503 Received: from mail-router.example.com 504 (mail-router.example.com [1.2.3.4]) 505 by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6) 506 with ESMTP id g1G0r1kA003489; 507 Fri, Feb 15 2002 17:19:07 -0800 508 Date: Fri, Feb 15 2002 16:54:30 -0800 509 To: receiver@sendmail.com 510 Message-Id: <12345.abc@example.com> 511 Subject: here's a sample 513 Hello! Goodbye! 515 The "Authentication-Results" header is present, indicating the deliv- 516 ering MTA (which is named in the value of the header) conforms to 517 this specification. Furthermore, the sender authenticated her- 518 self/himself to the MTA via a method specified in [AUTH], and both 519 SPF and Sender-ID checks were done and passed. The MUA could extract 520 and relay this extra information if desired. 522 9.5. Service provided, several authentications done, same MTA 524 A message that was relayed inbound by a single MTA which conforms to 525 this standard and applied multiple sender authentication checks: 527 Authentication-Results: auth-checker.example.com 528 from=sender@example.com; sender-id=pass; 529 domainkeys=fail (signature) 530 Received: from mail-router.example.com 531 (mail-router.example.com [10.11.12.13]) 532 by auth-checker.example.com (8.11.6/8.11.6) 533 with ESMTP id i7PK0sH7021929; 534 Fri, Feb 15 2002 17:19:22 -0800 535 Authentication-Results: mail-router.example.com 536 from=sender@example.com; auth=yes (cram-md5); spf=yes 537 Received: from dialup-1-2-3-4.example-isp.com 538 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 539 by mail-router.example.com (8.11.6/8.11.6) 540 with ESMTP id g1G0r1kA003489; 541 Fri, Feb 15 2002 17:19:07 -0800 542 DomainKey-Signature: a=rsa-sha1; s=gatsby; d=sendmail.net; 543 c=simple; q=dns; 544 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 545 From: sender@example.com 546 Date: Fri, Feb 15 2002 16:54:30 -0800 547 To: receiver@sendmail.com 548 Message-Id: <12345.abc@example.com> 549 Subject: here's a sample 551 Hello! Goodbye! 553 The "Authentication-Results" header is present, indicating confor- 554 mance to this specification. It is present twice because two differ- 555 ent MTAs in the chain of delivery did authentication tests. The 556 first, "mail-router.example.com" reports that [AUTH] and SPF were 557 both used and passed. In the [AUTH] case, additional data is pro- 558 vided in the comment field, which the MUA can choose to render if 559 desired. The second MTA, "auth-checker.example.com", reports that it 560 did a Sender-ID test which passed, but a DomainKeys test failed 561 because the signature verification was not successful. 563 10. Acknowledgements 565 The author wishes to acknowledge the following for their review and 566 constructive criticism of this proposal: Mark Delany and Miles Libbey 567 of Yahoo! Inc., Jim Fenton of Cisco, and Rand Wacker of Sendmail, 568 Inc. 570 11. References 572 [AUTH] 573 Myers, J., "SMTP Service Extention for Authentication", RFC 2554, 574 Netscape Communications, March 1999. 576 [MAIL] 577 Resnick, P. (editor), "Internet Message Format", RFC 2822, Qual- 578 comm, Inc., April 2001. 580 [MIME] 581 N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions 582 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 583 November 1996 585 [SMTP] 586 J. Klensin, (editor), "Simple Mail Transfer Protocol", RFC 2821, 587 April 2001 589 12. Author's Address: 591 Murray S. Kucherawy 592 Sendmail, Inc. 593 6425 Christie Ave., 4th Floor 594 Emeryville, CA 595 94608 596 USA 598 Comments may be sent to msk+ietf@sendmail.com. 600 13. Copyright Notice 602 Copyright (C) The Internet Society (year). This document is subject 603 to the rights, licenses and restrictions contained in BCP 78, and 604 except as set forth therein, the authors retain all their rights. 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 609 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 610 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 611 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 612 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.