idnits 2.17.1 draft-kucherawy-sender-auth-header-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 13. ** 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 118: '... of some debate, the header MAY appear...' RFC 2119 keyword, line 119: '...essage, or more than one result MAY be...' RFC 2119 keyword, line 120: '...ader, or a combination of these MAY be...' RFC 2119 keyword, line 175: '...evaluated, but the property MUST still...' RFC 2119 keyword, line 226: '... The "method" MUST refer to an authe...' (21 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 (May 2005) is 6915 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: 'SMTP' is defined on line 621, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2554 (ref. 'AUTH') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2822 (ref. 'MAIL') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 18 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. S. Kucherawy 3 Title: draft-kucherawy-sender-auth-header-02 Sendmail, Inc. 4 Expires: November 2005 May 2005 6 Message Header for Indicating Sender Authentication Status 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 15 This document may not be modified, and derivative works of it may not 16 be created, except to publish it as an RFC and to translate it into 17 languages other than English. 19 This document is an Internet-Draft and is subject to all provisions 20 of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This memo defines a new message header for use with [MAIL] messages 41 to indicate the results of sender authentication efforts to mail user 42 agents (MUAs) in order to equip them to relay that information in a 43 convenient way to users. 45 Table of Contents 46 1. Introduction 48 This memo defines a new message header for [MAIL] messages which 49 presents the results of a sender authentication effort in a machine- 50 readable format. The intent is to create a place to collect such 51 data when sender authentication mechanisms are in use so that an MUA 52 can provide a recommendation to the user as to the trustworthiness of 53 the message's origin and content. 55 This memo defines both the format of this new header, and discusses 56 the implications of its presence or absence. 58 At the time of publication of this draft, only [AUTH] is a published 59 sender authentication standard. However, several more are in the 60 Internet Draft stage. As various methods emerge, it is necessary to 61 prepare their appearance and encourage convergence in the area of 62 interfacing these filters to MUAs. 64 1.1. Purposes 66 The header defined in this memo is expected to serve several pur- 67 poses: 69 (1) Convey to MUAs from filters and MTAs the results of various sender 70 authentication checks being applied; 72 (2) Provide a common location for the presentation of this data; 74 (3) Create an extensible framework for specifying new authentication 75 methods as such emerge. 77 (4) Convey the results of sender authentication tests to later filter- 78 ing agents within the same "trust domain", as such agents might 79 apply more or less stringent checks based on sender authentication 80 results. 82 1.2. Requirements 84 This memo establishes no new requirements on existing protocols or 85 servers, as there is currently not a standard place for the described 86 data to be collected or presented. 88 1.3. Terminology 90 This document occasionally uses terms that appear in capital letters. 91 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 92 NOT", and "MAY" appear capitalized, they are being used to indicate 93 particular requirements of this specification. A discussion of the 94 meanings of these terms appears in RFC2119. 96 Generally it is assumed that the work of applying sender authentica- 97 tion schemes takes place at a border MTA, that is, an MTA which acts 98 as a gateway between the general Internet and the users within an 99 organizational boundary. This specification is written with that 100 assumption in mind. However, there are some sites at which the 101 entire mail infrastructure consists of a single host. In such cases, 102 such terms as "border MTA" and "delivery MTA" may well apply to the 103 same machine or even the very same agent. 105 2. Definition and Format of the Header 107 The new header being defined here is called "Authentication-Results". 108 It qualifies in [MAIL] terms as a Structured Header Field, and thus 109 all of the related definitions in that document apply. 111 The decommented value of the header consists of a hostname, some 112 whitespace, a "property=value" statement indicating which property 113 was selected to determine who sent the message and what value was 114 extracted from that property, followed by zero or more authentication 115 method names and a result associated with each, returned by the code 116 that implements the method. 118 As it is currently a matter of some debate, the header MAY appear 119 more than once in a single message, or more than one result MAY be 120 represented in a single header, or a combination of these MAY be 121 applied. 123 Formally, the header is specified as follows: 125 header = "Authentication-Results" CFWS ":" CFWS hostname CFWS 126 headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result) 127 CFWS 129 hostname = domain 130 ; as defined in section 3.4.1 of [MAIL] 132 method = token 133 ; a method indicates which method's result is 134 ; is represented by "value", and is one of the methods 135 ; explicitly defined as valid in this document 136 ; or is an extension method as defined below 138 result = "pass" / "fail" / "softfail" / "neutral" / 139 "temperror" / "permerror" 140 ; an indication of the results of the attempt to 141 ; authenticate the sender 143 token = ; as defined in Appendix A of [MIME] 145 CFWS = ; as defined in section 3.2.3 of [MAIL] 147 headerspec = ptype CWFS "." CWFS property CWFS "=" CFWS value 148 ; an indication of which property of the message 149 ; was evaluated by the authentication scheme being 150 ; applied to yield the reported result 152 ptype = "smtp" / "header" 153 ; indicates whether the property being evaluated was 154 ; a parameter to an SMTP command or was a value taken 155 ; from a message header 157 property = token 158 ; if "ptype" is "smtp", this indicates which SMTP command 159 ; provided the value which was evaluated by the 160 ; authentication scheme being applied, or if "ptype" is 161 ; "header", this indicates from which header the value 162 ; being evaluated was extracted 164 value = token / mailbox 165 ; the value extracted from the message property defined 166 ; by the "ptype.property" construction; if the value is 167 ; intended ; to identify a mailbox, then it is a "mailbox" 168 ; as defined in section 3.4 of [MAIL] 170 The "ptype" and "property" are case-insensitive. 172 If the parsed "ptype.property" construction clearly identifies a 173 mailbox (in particular, smtp.mail, smtp.rcpt, header.from, 174 header.sender), then the "value" must be a "mailbox". Other proper- 175 ties (e.g. smtp.helo) may be evaluated, but the property MUST still 176 be expressed as a "token" for simplified parsing. 178 The six possible values of the "result" are: 180 pass 181 sending domain publishes an authentication policy of some kind, 182 and the message passed the authentication tests 184 fail 185 sending domain publishes an authentication policy of some kind, 186 and the message failed the authentication tests 188 softfail 189 sending domain publishes an authentication policy which doesn't 190 require authentication of all messages from that domain, and the 191 message failed the authentication tests 193 neutral 194 sending domain does not publish any sender authentication policy 196 temperror 197 a temporary (recoverable) error occurred attempting to authenti- 198 cate the sender; either the process couldn't be completed 199 locally because of some transient condition, or there was a tem- 200 porary failure retrieving the sending domain's policy; a later 201 attempt to re-authenticate this message might produce a more 202 final result 204 permerror 205 a permanent (unrecoverable) error occurred attempting to authen- 206 ticate the sender; either the process couldn't be completed 207 locally, or there was a permanent failure retrieving the sending 208 domain's policy 210 3. Definition Of The "auth" Method 212 As it is currently an existing standard for sender authentication, it 213 is appropriate to define an authentication method identifier for 214 [AUTH]. The authentication method identifier "auth" is thus defined 215 for MTAs applying that standard for sender authentication. 217 4. Adding The Header To A Message 219 This specification makes no attempt to evaluate the relative 220 strengths of various sender authentication methods that may become 221 available. As such, the order of the presented authentication meth- 222 ods and results are not relevant since ultimately the importance on 223 any given method over another is the decision of the MUA that is 224 interpreting the value of the header. 226 The "method" MUST refer to an authentication method declared in this 227 memo, or in a subsequent one, or to an authentication method name 228 assigned by IANA. 230 If an MTA applies any authentication test, it MUST add this header to 231 indicate at which host the test was done, which test got applied, and 232 what the result was. If an MTA applies more than one such test, it 233 MUST either add this header once per test, or one header indicating 234 all of the results. An MTA MUST NOT add a result to an existing 235 header. 237 An MTA adding this header in either form MUST use its own hostname 238 only. It MUST be a fully-qualified domain name. 240 For security reasons, an MTA SHOULD remove any discovered instance of 241 this header for which the "hostname" is its own, i.e. headers which 242 claim to be from the MTA but were added before the mail arrived at 243 the MTA for processing. A border MTA MAY also delete any discovered 244 instance of this header which claims to have been added within its 245 trust boundary. For example, a border MTA at mx.example.com SHOULD 246 delete any instance of this header claiming to come from mx.exam- 247 ple.com and MAY delete any instance of this header claiming to come 248 from any host in example.com prior to adding its own headers. This 249 applies in both directions so that hosts outside the domain cannot 250 claim results MUAs inside the domain might trust. 252 An MTA compliant with this specification MUST add this header after 253 performing one or more sender authentication tests. An MTA MAY add 254 this header containing only the "hostname" portion to explicitly 255 indicate that no sender authentication schemes were applied prior to 256 delivery of this message. 258 4.1. Header Position and Interpretation 260 In order to ensure non-ambiguous results and avoid the impact of 261 false headers, an MUA SHOULD NOT interpret this header unless specif- 262 ically instructed to do so by the user. That is, this should not be 263 "on by default". Naturally then, users would not activate such a 264 feature unless they are certain the header will be added by the 265 receiving MTA that accepts the mail which is ultimately read by the 266 MUA, and instances of the header added by foreign MTAs will be 267 removed before delivery. 269 Furthermore, an MUA SHOULD NOT interpret this header unless the host- 270 name it bears appears to be one within its own trust domain as con- 271 figured by the user. 273 An MTA adding a header MUST add the header at the top of the message 274 so that there is generally some indication upon delivery of where in 275 the chain of handling MTAs the sender authentcation was done. 277 Further discussion of this can be found in the Security Considera- 278 tions section below. 280 4.2. Extension Fields 282 Additional authentication method identifiers may be defined in the 283 future by later revisions or extensions to this specification. 284 Extension identifiers beginning with "x-" will never be defined as 285 standard fields; such names are reserved for experimental use. 286 Method identifiers NOT beginning with "x-" MUST be registered with 287 the Internet Assigned Numbers Authority (IANA) and published in an 288 RFC. 290 Extension identifiers may be defined for the following reasons: 292 (a) To allow additional information from emergent authentication sys- 293 tems to be communicated to MUAs. The names of such identifiers 294 should reflect the name of the method being defined, but should not 295 be needlessly long. 297 (b) To allow the creation of "sub-identifiers" which indicate different 298 levels of authentication and differentiate between their relative 299 strengths, e.g. "auth1-weak" and "auth1-strong". 301 Authentication method implementors are encouraged to provide adequate 302 information, via [MAIL] comments if necessary, to allow an MUA devel- 303 oper to understand or relay ancilliary details of authentication 304 results. For example, if it might be of interest to relay what data 305 was used to perform an evaluation, such information could be relayed 306 as a comment in the header, such as: 308 Authentication-Results: mx.example.com; foo=yes (2 out of 3 tests 309 passed) 311 5. Discussion 313 This section discusses various implementation issues not specifically 314 related to security. Security issues are discussed in a later sec- 315 tion. 317 5.1. Legacy MUAs 319 Implementors of this proposal should be aware that many MUAs are 320 unlikely to be retrofit to support the new header and its semantics. 321 In the interests of convenience and quicker adaptation, a delivery 322 MTA might want to consider adding things that are processed by exist- 323 ing MUAs as well as the header defined by this specification. One 324 suggestion is to provide a Priority: header with a value that 325 reflects the strength of the authentication that was accomplished, 326 e.g. "low" for weak or no authentication, "normal" or "high" for good 327 authentication. 329 Certainly some modern MUAs can filter based on the content of this 330 header, but as there is keen interest in having MUAs make some kind 331 of graphical representation of this header's meaning, other interim 332 means of doing so may be necessary while this proposal is adopted. 334 5.2. Trusting The Header 336 Rather than the coding rigor of doing a digital signature on the con- 337 tent of this header, it may be sufficient to establish a maximum SMTP 338 path length between the addition of the header and final delivery. 339 The path length is defined as the count of Received headers above the 340 Authentication-Results header. If more than that maximum path length 341 is traversed between insertion of the header and delivery, the value 342 of the header should no longer be trusted to be valid. 344 This requires a configurable MUA setting to define this maximum path 345 length. The setting would need to take into account possible addi- 346 tional hops should the final delivery server be unavailable. 347 Although this approach likely bears a much shorter time to implement, 348 it is a less general solution than the proposed one and would proba- 349 bly require additional user education above the norm and thus lead to 350 more confusion on deployment. The MUA SHOULD trust this header if it 351 is trusting such headers and the path length after the addition of 352 the header is less than three. 354 6. Conformance and Usage Requirements 356 An MTA or gateway conforms to this specification if it applies one or 357 more sender authentication mechanisms and inserts a header corre- 358 sponding to this standard after doing so and prior to delivery. 360 MTAs that are relaying mail rather than delivering it MAY perform 361 sender authentication or even take actions based on the results 362 found, but MUST NOT add a "Authentication-Results" header if relaying 363 rather than rejecting or discarding at the gateway. Conversely, an 364 MTA doing local delivery MUST add this header prior to delivery the 365 message in order to be compliant. 367 A minimal implementation which does at least one sender authentica- 368 tion check will add the header defined by this memo prior to invoking 369 local delivery procedures. 371 This specification places no restrictions on the processing of the 372 header's contents by user agents or distribution lists. It is pre- 373 sented to those packages solely for their own information. 375 7. IANA Considerations 377 Following the policies outlined in [IANA-CONSIDERATIONS], names of 378 sender authentication methods supported by this specification must be 379 registered with IANA under the IETF Consensus method, with the excep- 380 tion of experimental names as defined above. 382 8. Security Considerations 384 The following security considerations apply when applying or process- 385 ing the "Authentication-Results" header: 387 8.1. Non-conformant MTAs 389 An MUA that is aware of this specification which accesses a mailbox 390 whose mail is handled by a non-conformant MTA is in a position to 391 make false conclusions based on forged headers. A malicious user or 392 agent could forge a header using the destination MX for a receiving 393 domain as the hostname token in the value of the header, and with the 394 rest of the value claim that the sender was properly authenticated. 395 The non-conformant MTA would fail to strip the forged header, and the 396 MUA could trust it. 398 It is for this reason an MUA SHOULD NOT have processing of the 399 "Authentication-Results" header enabled by default; instead it must 400 be ignored, at least for the purposes of enacting filtering deci- 401 sions, unless specifically enabled by the user after verifying that 402 the MTA is compliant. It is acceptable to have an MUA aware of this 403 standard, but have an explicit list of hostnames whose "Authentica- 404 tion-Results" headers are trustworthy, but this list SHOULD initially 405 be empty. 407 Proposed alternate solutions to this problem are nascent. Possibly 408 the simplest is a digital signature on the header which can be veri- 409 fied by a posted public key. Another would be a means to interrogate 410 the MTA that added the header to see if it is actually providing any 411 sender authentication services and saw the message in question. In 412 either case, a method needs to exist to verify that the host which 413 appears to have added the header (a) actually did so, and (b) is 414 legitimately adding that header for this delivery. 416 8.2. Header Position 418 Headers can sometimes be reordered enroute by intermediate MTAs. The 419 goal of requiring header addition only at the top of a message is an 420 acknowledgement that some MTAs do reorder headers, but most do not. 421 Thus, in the general case, there will be some indication of which 422 MTAs (if any) handled the message after the addition of the header 423 defined here. 425 However, this is not universally true. In an environment involving 426 an MTA that does reorder headers, the above-mentioned hop count test 427 for header validity may not be possible. 429 9. Appendix - Authentication-Results Examples 431 This section presents some examples of the use of this header to 432 indicate authentication results. It makes use of some authentication 433 methods which are still in the draft phase, namely "domainkeys", 434 "sender-id" and "spf". These are not IANA-registered or otherwise 435 formally defined, but they are presented here under the assumption 436 that they eventually will be. 438 9.1. Trivial case; header not present 440 The trivial case: 442 From: sender@example.com 443 Received: from mail-router.example.com 444 (mail-router.example.com [1.2.3.4]) 445 by server.sendmail.com (8.11.6/8.11.6) 446 with ESMTP id g1G0r1kA003489; 447 Fri, Feb 15 2002 17:19:07 -0800 448 Date: Fri, Feb 15 2002 16:54:30 -0800 449 To: receiver@sendmail.com 450 Message-Id: <12345.abc@example.com> 451 Subject: here's a sample 453 Hello! Goodbye! 455 The "Authentication-Results" header is completely absent. The MUA 456 may make no conclusion about the validity of the message. This could 457 be the case because the sender authentication services were not 458 available at the time of delivery, or no service is provided, or the 459 MTA is not in compliance with this specification. 461 9.2. Nearly-trivial case; service provided, but no authentication done 463 A message that was delivered by an MTA which conforms to this stan- 464 dard but provides no actual sender authentication service: 466 Authentication-Results: mail-router.example.com 467 header.from=sender@example.com 468 From: sender@example.com 469 Received: from mail-router.example.com 470 (mail-router.example.com [1.2.3.4]) 471 by server.sendmail.com (8.11.6/8.11.6) 472 with ESMTP id g1G0r1kA003489; 474 Fri, Feb 15 2002 17:19:07 -0800 475 Date: Fri, Feb 15 2002 16:54:30 -0800 476 To: receiver@sendmail.com 477 Message-Id: <12345.abc@example.com> 478 Subject: here's a sample 480 Hello! Goodbye! 482 The "Authentication-Results" header is present, indicating the deliv- 483 ering MTA (which is named in the value of the header) conforms to 484 this specification. The absence of any method and result tokens 485 indicates no sender authentication was done. 487 9.3. Service provided, authentication done 489 A message that was delivered by an MTA which conforms to this stan- 490 dard and applied some sender authentication: 492 Authentication-Results: mail-router.example.com 493 smtp.mail=sender@example.com; auth=pass (cram-md5) 494 From: sender@example.com 495 Received: from dialup-1-2-3-4.example-isp.com 496 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 497 by mail-router.example.com (8.11.6/8.11.6) 498 with ESMTP id g1G0r1kA003489; 499 Fri, Feb 15 2002 17:19:07 -0800 500 Date: Fri, Feb 15 2002 16:54:30 -0800 501 To: receiver@sendmail.com 502 Message-Id: <12345.abc@example.com> 503 Subject: here's a sample 505 Hello! Goodbye! 507 The "Authentication-Results" header is present, indicating the deliv- 508 ering MTA (which is named in the value of the header) conforms to 509 this specification. Furthermore, the sender authenticated her- 510 self/himself to the MTA via a method specified in [AUTH]. The actual 511 method is identified in a header comment after the method's result is 512 indicated. The MUA could extract and relay this extra information if 513 desired. 515 9.4. Service provided, several authentications done, single MTA 517 A message that was relayed inbound via a single MTA which conforms to 518 this standard and applied two different sender authentication checks: 520 Authentication-Results: mail-router.example.com 521 smtp.mail=sender@example.com; 522 auth=pass (cram-md5); spf=pass 523 Authentication-Results: mail-router.example.com 524 header.from=sender@example.com; sender-id=pass 525 From: sender@example.com 526 Received: from mail-router.example.com 527 (mail-router.example.com [1.2.3.4]) 528 by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6) 529 with ESMTP id g1G0r1kA003489; 530 Fri, Feb 15 2002 17:19:07 -0800 531 Date: Fri, Feb 15 2002 16:54:30 -0800 532 To: receiver@sendmail.com 533 Message-Id: <12345.abc@example.com> 534 Subject: here's a sample 536 Hello! Goodbye! 538 The "Authentication-Results" header is present, indicating the deliv- 539 ering MTA (which is named in the value of the header) conforms to 540 this specification. Furthermore, the sender authenticated her- 541 self/himself to the MTA via a method specified in [AUTH], and both 542 SPF and Sender-ID checks were done and passed. The MUA could extract 543 and relay this extra information if desired. 545 Two "Authentication-Results" headers are required because the methods 546 applied did not all base their results on the same property of the 547 message. 549 9.5. Service provided, several authentications done, different MTAs 551 A message that was relayed inbound by two different MTAs which con- 552 form to this standard and applied multiple sender authentication 553 checks: 555 Authentication-Results: auth-checker.example.com 556 header.from=sender@example.com; sender-id=pass; 557 domainkeys=pass (good signature) 558 Received: from mail-router.example.com 559 (mail-router.example.com [10.11.12.13]) 560 by auth-checker.example.com (8.11.6/8.11.6) 561 with ESMTP id i7PK0sH7021929; 562 Fri, Feb 15 2002 17:19:22 -0800 563 Authentication-Results: mail-router.example.com 564 smtp.mail=sender@example.com; auth=pass (cram-md5); 565 spf=fail 566 Received: from dialup-1-2-3-4.example-isp.com 567 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 568 by mail-router.example.com (8.11.6/8.11.6) 569 with ESMTP id g1G0r1kA003489; 570 Fri, Feb 15 2002 17:19:07 -0800 571 DomainKey-Signature: a=rsa-sha1; s=gatsby; d=sendmail.com; 572 c=simple; q=dns; 573 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 574 From: sender@example.com 575 Date: Fri, Feb 15 2002 16:54:30 -0800 576 To: receiver@sendmail.com 577 Message-Id: <12345.abc@example.com> 578 Subject: here's a sample 580 Hello! Goodbye! 582 The "Authentication-Results" header is present, indicating confor- 583 mance to this specification. It is present twice because two differ- 584 ent MTAs in the chain of delivery did authentication tests. The 585 first, "mail-router.example.com" reports that [AUTH] and SPF were 586 both used and [AUTH] passed but SPF failed. In the [AUTH] case, 587 additional data is provided in the comment field, which the MUA can 588 choose to render if desired. The second MTA, "auth-checker.exam- 589 ple.com", reports that it did a Sender-ID test and a DomainKeys test, 590 both of which which passed. Again, additional data about one of the 591 tests is provided as a comment, which the MUA may choose to render. 593 10. Acknowledgements 595 The author wishes to acknowledge the following for their review and 596 constructive criticism of this proposal: Mark Delany and Miles Libbey 597 of Yahoo! Inc., Jim Fenton of Cisco, and Rand Wacker and Eric Allman 598 of Sendmail, Inc. 600 11. References 602 Normative: 604 [AUTH] 605 Myers, J., "SMTP Service Extention for Authentication", RFC 2554, 606 Netscape Communications, March 1999. 608 [IANA-CONSIDERATIONS] 609 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Con- 610 siderations Section in RFCs", RFC 2434, October 1998. 612 [MAIL] 613 Resnick, P. (editor), "Internet Message Format", RFC 2822, Qual- 614 comm, Inc., April 2001. 616 [MIME] 617 N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions 618 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 619 November 1996 621 [SMTP] 622 J. Klensin, (editor), "Simple Mail Transfer Protocol", RFC 2821, 623 April 2001 625 12. Author's Address: 627 Murray S. Kucherawy 628 Sendmail, Inc. 629 6425 Christie Ave., 4th Floor 630 Emeryville, CA 631 94608 632 USA 634 Comments may be sent to msk+ietf@sendmail.com. 636 13. Copyright Notice 638 Copyright (C) The Internet Society (year). This document is subject 639 to the rights, licenses and restrictions contained in BCP 78, and 640 except as set forth therein, the authors retain all their rights. 642 This document and the information contained herein are provided on an 643 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 644 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 645 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 646 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 647 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 648 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.