idnits 2.17.1 draft-kucherawy-sender-auth-header-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 694. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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 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 122: '... of some debate, the header MAY appear...' RFC 2119 keyword, line 123: '...essage, or more than one result MAY be...' RFC 2119 keyword, line 124: '...ader, or a combination of these MAY be...' RFC 2119 keyword, line 187: '...then the "value" MUST be a "mailbox". ...' RFC 2119 keyword, line 188: '...ay be evaluated, but the property MUST...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 23, 2007) is 6272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'AUTH' on line 637 -- Looks like a reference, but probably isn't: 'MAIL' on line 315 -- Looks like a reference, but probably isn't: 'MIME' on line 148 -- Looks like a reference, but probably isn't: 'SMTP' on line 350 -- Looks like a reference, but probably isn't: 'IANA-CONSIDERATIONS' on line 390 ** Obsolete normative reference: RFC 2554 (ref. '1') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2821 (ref. '5') (Obsoleted by RFC 5321) Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Sendmail, Inc. 4 Intended status: Informational February 23, 2007 5 Expires: August 27, 2007 7 Message Header for Indicating Sender Authentication Status 8 draft-kucherawy-sender-auth-header-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 27, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo defines a new message header for use with electronic mail 44 messages to indicate the results of sender authentication efforts to 45 mail user agents (MUAs) in order to equip them to relay that 46 information in a convenient way to users or to make sorting and 47 filtering decisions. 49 1. Introduction 51 This memo defines a new message header for electronic mail messages 52 which presents the results of a sender authentication effort in a 53 machine-readable format. The intent is to create a place to collect 54 such data when sender authentication mechanisms are in use so that an 55 MUA can provide a recommendation to the user as to the 56 trustworthiness of the message's origin and content. 58 This memo defines both the format of this new header, and discusses 59 the implications of its presence or absence. 61 [REMOVE OR REWORD PRIOR TO FINAL VERSION] At the time of publication 62 of this draft, only [AUTH] is a published sender authentication 63 standard. However, several more are in the Internet Draft stage. As 64 various methods emerge, it is necessary to prepare for their 65 appearance and encourage convergence in the area of interfacing these 66 filters to MUAs. 68 1.1. Purpose 70 The header defined in this memo is expected to serve several 71 purposes: 73 1. Convey to MUAs from filters and MTAs the results of various 74 sender authentication checks being applied; 76 2. Provide a common location for the presentation of this data; 78 3. Create an extensible framework for specifying new authentication 79 methods as such emerge; 81 4. Convey the results of sender authentication tests to later 82 filtering agents within the same "trust domain", as such agents 83 might apply more or less stringent checks based on sender 84 authentication results. 86 1.2. Requirements 88 This memo establishes no new requirements on existing protocols or 89 servers, as there is currently not a standard place for the described 90 data to be collected or presented. 92 1.3. Definitions 94 This document occasionally uses terms that appear in capital letters. 95 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 96 NOT", and "MAY" appear capitalized, they are being used to indicate 97 particular requirements of this specification. A discussion of the 98 meanings of these terms appears in RFC2119. 100 Generally it is assumed that the work of applying sender 101 authentication schemes takes place at a border MTA, that is, an MTA 102 which acts as a gateway between the general Internet and the users 103 within an organizational boundary. This specification is written 104 with that assumption in mind. However, there are some sites at which 105 the entire mail infrastructure consists of a single host. In such 106 cases, such terms as "border MTA" and "delivery MTA" may well apply 107 to the same machine or even the very same agent. 109 2. Definition and Format of the Header 111 The new header being defined here is called "Authentication-Results". 112 It qualifies in [MAIL] [3] terms as a Structured Header Field, and 113 thus all of the related definitions in that document apply. 115 The decommented value of the header consists of a hostname, some 116 whitespace, a "property=value" statement indicating which property 117 was selected to determine who sent the message and what value was 118 extracted from that property, followed by zero or more authentication 119 method names and a result associated with each, returned by the code 120 that implements the method. 122 As it is currently a matter of some debate, the header MAY appear 123 more than once in a single message, or more than one result MAY be 124 represented in a single header, or a combination of these MAY be 125 applied. 127 Formally, the header is specified as follows: 129 header = "Authentication-Results:" CFWS hostname CFWS 130 headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result) 131 CFWS 133 hostname = domain 134 ; as defined in section 3.4.1 of [MAIL] 136 method = token 137 ; a method indicates which method's result is 138 ; is represented by "value", and is one of the methods 139 ; explicitly defined as valid in this document 140 ; or is an extension method as defined below 142 result = "pass" / "fail" / "softfail" / "neutral" / 143 "temperror" / "permerror" 144 ; an indication of the results of the attempt to 145 ; authenticate the sender 147 token = ; as defined in Appendix A of 148 [MIME] [4] 150 token = ; as defined in Appendix A of 152 CFWS = ; as defined in section 3.2.3 of [MAIL] 153 headerspec = ptype CWFS "." CWFS property CWFS "=" CFWS value 154 ; an indication of which property of the message 155 ; was evaluated by the authentication scheme being 156 ; applied to yield the reported result 158 ptype = "smtp" / "header" 159 ; indicates whether the property being evaluated was 160 ; a parameter to an 161 [SMTP] [5] 163 ptype = "smtp" / "header" 164 ; indicates whether the property being evaluated was 165 ; a parameter to an 167 property = token 168 ; if "ptype" is "smtp", this indicates which [SMTP] 169 ; command provided the value which was evaluated by the 170 ; authentication scheme being applied, or if "ptype" is 171 ; "header", this indicates from which header the value 172 ; being evaluated was extracted 174 value = token / mailbox 175 ; the value extracted from the message property defined 176 ; by the "ptype.property" construction; if the value is 177 ; intended ; to identify a mailbox, then it is a "mailbox" 178 ; as defined in section 3.4 of [MAIL] 180 The "ptype" and "property" used by each authentication method should 181 be defined in the specification for that method (or its amendments). 183 The "ptype" and "property" are case-insensitive. 185 If the parsed "ptype.property" construction clearly identifies a 186 mailbox (in particular, smtp.mail, smtp.rcpt, header.from, 187 header.sender), then the "value" MUST be a "mailbox". Other 188 properties (e.g. smtp.helo) may be evaluated, but the property MUST 189 still be expressed as a "token" for simplified parsing. 191 The six possible values of the "result" are: 193 pass: The message passed the authentication tests. (This may 194 require accessing an authentication policy of some kind published 195 by the sending domain.) 197 fail: The message failed the authentication tests. (This may 198 require accessing an authentication policy of some kind published 199 by the sending domain.) 201 softfail: The authentication method has either an explicit 202 (published by the sending domain) or implicit policy, but the 203 policy being used doesn't require successful authentication of all 204 messages from that domain, and the message failed the 205 authentication tests. 207 neutral: The authentication method completed without errors, but was 208 unable to reach either a positive or negative result about the 209 message. 211 temperror: A temporary (recoverable) error occurred attempting to 212 authenticate the sender; either the process couldn't be completed 213 locally, or (for methods requiring a policy to be accessed) there 214 was a temporary failure retrieving the sending domain's policy. A 215 later retry may produce a more final result. 217 permerror: A permanent (unrecoverable) error occurred attempting to 218 authenticate the sender; either the process couldn't be completed 219 locally, or (for methods requiring a policy to be accessed) there 220 was a permanent failure retrieving the sending domain's policy. 222 3. Definition Of The 'auth' Method 224 As it is currently an existing standard for sender authentication, it 225 is appropriate to define an authentication method identifier for 226 [AUTH] [1]. The authentication method identifier "auth" is thus 227 defined for MTAs applying that standard for sender authentication. 229 4. Adding The Header To A Message 231 This specification makes no attempt to evaluate the relative 232 strengths of various sender authentication methods that may become 233 available. As such, the order of the presented authentication 234 methods and results are not relevant since ultimately the importance 235 on any given method over another is the decision of the MUA that is 236 interpreting the value of the header. 238 The "method" MUST refer to an authentication method declared in this 239 memo, or in a subsequent one, or to an authentication method name 240 assigned by IANA. 242 If an MTA applies any authentication test, it MUST add this header to 243 indicate at which host the test was done, which test got applied, and 244 what the result was. If an MTA applies more than one such test, it 245 MUST either add this header once per test, or one header indicating 246 all of the results. An MTA MUST NOT add a result to an existing 247 header. 249 An MTA adding this header in either form MUST use its own hostname 250 only. It MUST be a fully-qualified domain name. 252 For security reasons, an MTA conforming to this specification MUST 253 remove any discovered instance of this header for which the 254 "hostname" is its own, i.e. headers which claim to be from the MTA 255 but were added before the mail arrived at the MTA for processing. A 256 border MTA SHOULD also delete any discovered instance of this header 257 which claims to have been added within its trust boundary. For 258 example, a border MTA at mx.example.com MUST delete any instance of 259 this header claiming to come from mx.example.com and SHOULD delete 260 any instance of this header claiming to come from any host in 261 example.com prior to adding its own headers. This applies in both 262 directions so that hosts outside the domain cannot claim results MUAs 263 inside the domain might trust. 265 An MTA compliant with this specification MUST add this header after 266 performing one or more sender authentication tests. An MTA MAY add 267 this header containing only the "hostname" portion to explicitly 268 indicate that no sender authentication schemes were applied prior to 269 delivery of this message. 271 4.1. Header Position and Interpretation 273 In order to ensure non-ambiguous results and avoid the impact of 274 false headers, an MUA SHOULD NOT interpret this header unless 275 specifically instructed to do so by the user. That is, this should 276 not be "on by default". Naturally then, users would not activate 277 such a feature unless they are certain the header will be added by 278 the receiving MTA that accepts the mail which is ultimately read by 279 the MUA, and instances of the header added by foreign MTAs will be 280 removed before delivery. 282 Furthermore, an MUA SHOULD NOT interpret this header unless the 283 hostname it bears appears to be one within its own trust domain as 284 configured by the user. 286 An MTA adding a header MUST add the header at the top of the message 287 so that there is generally some indication upon delivery of where in 288 the chain of handling MTAs the sender authentcation was done. 290 Further discussion of this can be found in the Security 291 Considerations section below. 293 4.2. Extension Fields 295 Additional authentication method identifiers may be defined in the 296 future by later revisions or extensions to this specification. 297 Extension identifiers beginning with "x-" will never be defined as 298 standard fields; such names are reserved for experimental use. 299 Method identifiers NOT beginning with "x-" MUST be registered with 300 the Internet Assigned Numbers Authority (IANA) and published in an 301 RFC. 303 Extension identifiers may be defined for the following reasons: 305 1. To allow additional information from emergent authentication 306 systems to be communicated to MUAs. The names of such 307 identifiers should reflect the name of the method being defined, 308 but should not be needlessly long. 310 2. To allow the creation of "sub-identifiers" which indicate 311 different levels of authentication and differentiate between 312 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 314 Authentication method implementors are encouraged to provide adequate 315 information, via [MAIL] comments if necessary, to allow an MUA 316 developer to understand or relay ancilliary details of authentication 317 results. For example, if it might be of interest to relay what data 318 was used to perform an evaluation, such information could be relayed 319 as a comment in the header, such as: 321 Authentication-Results: mx.example.com; foo=pass (2 of 3 tests OK) 323 5. Discussion 325 This section discusses various implementation issues not specifically 326 related to security. Security issues are discussed in a later 327 section. 329 5.1. Legacy MUAs 331 Implementors of this proposal should be aware that many MUAs are 332 unlikely to be retrofit to support the new header and its semantics. 333 In the interests of convenience and quicker adaptation, a delivery 334 MTA might want to consider adding things that are processed by 335 existing MUAs as well as the header defined by this specification. 336 One suggestion is to provide a Priority: header with a value that 337 reflects the strength of the authentication that was accomplished, 338 e.g. "low" for weak or no authentication, "normal" or "high" for good 339 authentication. 341 Certainly some modern MUAs can filter based on the content of this 342 header, but as there is keen interest in having MUAs make some kind 343 of graphical representation of this header's meaning, other interim 344 means of doing so may be necessary while this proposal is adopted. 346 5.2. Trusting The Header 348 Rather than the coding rigor of doing a digital signature on the 349 content of this header, it may be sufficient to establish a maximum 350 [SMTP] path length between the addition of the header and final 351 delivery. The path length is defined as the count of Received 352 headers above the Authentication-Results header. If more than that 353 maximum path length is traversed between insertion of the header and 354 delivery, the value of the header should no longer be trusted to be 355 valid. 357 This requires a configurable MUA setting to define this maximum path 358 length. The setting would need to take into account possible 359 additional hops should the final delivery server be unavailable. 360 Although this approach likely bears a much shorter time to implement, 361 it is a less general solution than the proposed one and would 362 probably require additional user education above the norm and thus 363 lead to more confusion on deployment. The MUA SHOULD trust this 364 header if it is trusting such headers and the path length after the 365 addition of the header is less than three. 367 6. Conformance and Usage Requirements 369 An MTA or gateway conforms to this specification if it applies one or 370 more sender authentication mechanisms and inserts a header 371 corresponding to this standard after doing so and prior to delivery. 373 MTAs that are relaying mail rather than delivering it MAY perform 374 sender authentication or even take actions based on the results 375 found, but MUST NOT add a "Authentication-Results" header if relaying 376 rather than rejecting or discarding at the gateway. Conversely, an 377 MTA doing local delivery MUST add this header prior to delivery the 378 message in order to be compliant. 380 A minimal implementation which does at least one sender 381 authentication check will add the header defined by this memo prior 382 to invoking local delivery procedures. 384 This specification places no restrictions on the processing of the 385 header's contents by user agents or distribution lists. It is 386 presented to those packages solely for their own information. 388 7. IANA Considerations 390 Following the policies outlined in [IANA-CONSIDERATIONS] [2] names of 391 sender authentication methods supported by this specification must be 392 registered with IANA under the IETF Consensus method, with the 393 exception of experimental names as described above. 395 8. Security Considerations 397 The following security considerations apply when applying or 398 processing the "Authentication-Results" header: 400 8.1. Non-conformant MTAs 402 An MUA that is aware of this specification which accesses a mailbox 403 whose mail is handled by a non-conformant MTA is in a position to 404 make false conclusions based on forged headers. A malicious user or 405 agent could forge a header using the destination MX for a receiving 406 domain as the hostname token in the value of the header, and with the 407 rest of the value claim that the sender was properly authenticated. 408 The non-conformant MTA would fail to strip the forged header, and the 409 MUA could trust it. 411 It is for this reason an MUA SHOULD NOT have processing of the 412 "Authentication-Results" header enabled by default; instead it must 413 be ignored, at least for the purposes of enacting filtering 414 decisions, unless specifically enabled by the user after verifying 415 that the MTA is compliant. It is acceptable to have an MUA aware of 416 this standard, but have an explicit list of hostnames whose 417 "Authentication-Results" headers are trustworthy, however this list 418 SHOULD initially be empty. 420 Proposed alternate solutions to this problem are nascent. Possibly 421 the simplest is a digital signature on the header which can be 422 verified by a posted public key. Another would be a means to 423 interrogate the MTA that added the header to see if it is actually 424 providing any sender authentication services and saw the message in 425 question. In either case, a method needs to exist to verify that the 426 host which appears to have added the header (a) actually did so, and 427 (b) is legitimately adding that header for this delivery. 429 8.2. Header Position 431 Headers can sometimes be reordered enroute by intermediate MTAs. The 432 goal of requiring header addition only at the top of a message is an 433 acknowledgement that some MTAs do reorder headers, but most do not. 434 Thus, in the general case, there will be some indication of which 435 MTAs (if any) handled the message after the addition of the header 436 defined here. 438 However, this is not universally true. In an environment involving 439 an MTA that does reorder headers, the above-mentioned hop count test 440 for header validity may not be possible. 442 9. References 444 [1] Myers, J., "SMTP Service Extension for Authentication", 445 RFC 2554, March 1999. 447 [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 448 Considerations Section in RFCs", RFC 2434, October 1998. 450 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 452 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 453 Extensions (MIME) Part One: Format of Internet Message Bodies", 454 RFC 2045, November 1996. 456 [5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 457 April 2001. 459 Appendix A. Acknowledgements 461 The author wishes to acknowledge the following for their review and 462 constructive criticism of this proposal: Mark Delany and Miles Libbey 463 of Yahoo! Inc., Jim Fenton of Cisco, and Rand Wacker and Eric Allman 464 of Sendmail, Inc. 466 Appendix B. Public Discussion 468 Public discussion of this proposed specification is handled via the 469 mail-vet-discuss@mipassoc.org mailing list. The list is open. 470 Access to subscription forms and to list archives can be found at 471 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 473 Appendix C. Authentication-Results Examples 475 This section presents some examples of the use of this header to 476 indicate authentication results. It makes use of some authentication 477 methods which are still in the draft phase, namely "domainkeys", 478 "sender-id" and "spf". These are not IANA-registered or otherwise 479 formally defined, but they are presented here under the assumption 480 that they eventually will be. 482 C.1. Trivial case; header not present 484 The trivial case: 486 From: sender@example.com 487 Received: from mail-router.example.com 488 (mail-router.example.com [1.2.3.4]) 489 by server.sendmail.com (8.11.6/8.11.6) 490 with ESMTP id g1G0r1kA003489; 491 Fri, Feb 15 2002 17:19:07 -0800 492 Date: Fri, Feb 15 2002 16:54:30 -0800 493 To: receiver@sendmail.com 494 Message-Id: <12345.abc@example.com> 495 Subject: here's a sample 497 Hello! Goodbye! 499 Example 1: Trivial case 501 The "Authentication-Results" header is completely absent. The MUA 502 may make no conclusion about the validity of the message. This could 503 be the case because the sender authentication services were not 504 available at the time of delivery, or no service is provided, or the 505 MTA is not in compliance with this specification. 507 C.2. Nearly-trivial case; service provided, but no authentication done 509 A message that was delivered by an MTA which conforms to this 510 standard but provides no actual sender authentication service: 512 Authentication-Results: mail-router.example.com 513 From: sender@example.com 514 Received: from mail-router.example.com 515 (mail-router.example.com [1.2.3.4]) 516 by server.sendmail.com (8.11.6/8.11.6) 517 with ESMTP id g1G0r1kA003489; 518 Fri, Feb 15 2002 17:19:07 -0800 519 Date: Fri, Feb 15 2002 16:54:30 -0800 520 To: receiver@sendmail.com 521 Message-Id: <12345.abc@example.com> 522 Subject: here's a sample 524 Hello! Goodbye! 526 Example 2: Header present but no authentication done 528 The "Authentication-Results" header is present, indicating the 529 delivering MTA (which is named in the value of the header) conforms 530 to this specification. The absence of any method and result tokens 531 indicates no sender authentication was done. 533 C.3. Service provided, authentication done 535 A message that was delivered by an MTA which conforms to this 536 standard and applied some sender authentication: 538 Authentication-Results: mail-router.example.com 539 smtp.auth=sender@example.com; auth=pass (cram-md5) 540 From: sender@example.com 541 Received: from dialup-1-2-3-4.example-isp.com 542 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 543 by mail-router.example.com (8.11.6/8.11.6) 544 with ESMTP id g1G0r1kA003489; 545 Fri, Feb 15 2002 17:19:07 -0800 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 Example 3: Header reporting results 554 The "Authentication-Results" header is present, indicating the 555 delivering MTA (which is named in the value of the header) conforms 556 to this specification. Furthermore, the sender authenticated 557 herself/himself to the MTA via a method specified in [AUTH]. The 558 actual method is identified in a header comment after the method's 559 result is indicated. The MUA could extract and relay this extra 560 information if desired. 562 C.4. Service provided, several authentications done, single MTA 564 A message that was relayed inbound via a single MTA which conforms to 565 this standard and applied two different sender authentication checks: 567 Authentication-Results: mail-router.example.com 568 smtp.mail=sender@example.com; 569 auth=pass (cram-md5); spf=pass 570 Authentication-Results: mail-router.example.com 571 header.from=sender@example.com; sender-id=pass 572 From: sender@example.com 573 Received: from mail-router.example.com 574 (mail-router.example.com [1.2.3.4]) 575 by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6) 576 with ESMTP id g1G0r1kA003489; 577 Fri, Feb 15 2002 17:19:07 -0800 578 Date: Fri, Feb 15 2002 16:54:30 -0800 579 To: receiver@sendmail.com 580 Message-Id: <12345.abc@example.com> 581 Subject: here's a sample 583 Hello! Goodbye! 585 Example 4: Headers reporting results from one MTA 587 The "Authentication-Results" header is present, indicating the 588 delivering MTA (which is named in the value of the header) conforms 589 to this specification. Furthermore, the sender authenticated 590 herself/himself to the MTA via a method specified in [AUTH], and both 591 SPF and Sender-ID checks were done and passed. The MUA could extract 592 and relay this extra information if desired. 594 Two "Authentication-Results" headers are required because the methods 595 applied did not all base their results on the same property of the 596 message. 598 C.5. Service provided, several authentications done, different MTAs 600 A message that was relayed inbound by two different MTAs which 601 conform to this standard and applied multiple sender authentication 602 checks: 604 Authentication-Results: auth-checker.example.com 605 header.from=sender@example.com; sender-id=pass; 606 domainkeys=pass (good signature) 607 Received: from mail-router.example.com 608 (mail-router.example.com [10.11.12.13]) 609 by auth-checker.example.com (8.11.6/8.11.6) 610 with ESMTP id i7PK0sH7021929; 611 Fri, Feb 15 2002 17:19:22 -0800 612 Authentication-Results: mail-router.example.com 613 smtp.mail=sender@example.com; auth=pass (cram-md5); 614 spf=fail 615 Received: from dialup-1-2-3-4.example-isp.com 616 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 617 by mail-router.example.com (8.11.6/8.11.6) 618 with ESMTP id g1G0r1kA003489; 619 Fri, Feb 15 2002 17:19:07 -0800 620 DomainKey-Signature: a=rsa-sha1; s=gatsby; d=sendmail.com; 621 c=simple; q=dns; 622 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 623 From: sender@example.com 624 Date: Fri, Feb 15 2002 16:54:30 -0800 625 To: receiver@sendmail.com 626 Message-Id: <12345.abc@example.com> 627 Subject: here's a sample 629 Hello! Goodbye! 631 Example 5: Headers reporting results from multiple MTAs 633 The "Authentication-Results" header is present, indicating 634 conformance to this specification. It is present twice because two 635 different MTAs in the chain of delivery did authentication tests. 636 The first, "mail-router.example.com" reports that [AUTH] and SPF were 637 both used and [AUTH] passed but SPF failed. In the [AUTH] case, 638 additional data is provided in the comment field, which the MUA can 639 choose to render if desired. The second MTA, "auth- 640 checker.example.com", reports that it did a Sender-ID test and a 641 DomainKeys test, both of which which passed. Again, additional data 642 about one of the tests is provided as a comment, which the MUA may 643 choose to render. 645 Author's Address 647 Murray S. Kucherawy 648 Sendmail, Inc. 649 6425 Christie Ave., Suite 400 650 Emeryville, CA 94608 651 US 653 Phone: +1 510 594 5400 654 Email: msk+ietf@sendmail.com 656 Full Copyright Statement 658 Copyright (C) The IETF Trust (2007). 660 This document is subject to the rights, licenses and restrictions 661 contained in BCP 78, and except as set forth therein, the authors 662 retain all their rights. 664 This document and the information contained herein are provided on an 665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 667 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 668 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 669 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 672 Intellectual Property 674 The IETF takes no position regarding the validity or scope of any 675 Intellectual Property Rights or other rights that might be claimed to 676 pertain to the implementation or use of the technology described in 677 this document or the extent to which any license under such rights 678 might or might not be available; nor does it represent that it has 679 made any independent effort to identify any such rights. Information 680 on the procedures with respect to rights in RFC documents can be 681 found in BCP 78 and BCP 79. 683 Copies of IPR disclosures made to the IETF Secretariat and any 684 assurances of licenses to be made available, or the result of an 685 attempt made to obtain a general license or permission for the use of 686 such proprietary rights by implementers or users of this 687 specification can be obtained from the IETF on-line IPR repository at 688 http://www.ietf.org/ipr. 690 The IETF invites any interested party to bring to its attention any 691 copyrights, patents or patent applications, or other proprietary 692 rights that may cover technology that may be required to implement 693 this standard. Please address the information to the IETF at 694 ietf-ipr@ietf.org. 696 Acknowledgment 698 Funding for the RFC Editor function is provided by the IETF 699 Administrative Support Activity (IASA).