idnits 2.17.1 draft-kucherawy-sender-auth-header-05.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 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 747. -- 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 114: '... This new header SHOULD be added at th...' RFC 2119 keyword, line 127: '... of some debate, the header MAY appear...' RFC 2119 keyword, line 128: '...essage, or more than one result MAY be...' RFC 2119 keyword, line 129: '...ader, or a combination of these MAY be...' RFC 2119 keyword, line 205: '...then the "value" MUST be a "mailbox". ...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: This header field SHOULD be treated as though it were a trace header field as defined in section 3.6 of [MAIL] [6], and hence SHOULD not be reordered and SHOULD be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the sender authentcation was done. -- 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 19, 2007) is 6186 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) -- Looks like a reference, but probably isn't: 'AUTH' on line 690 -- Looks like a reference, but probably isn't: 'SENDERID' on line 249 -- Looks like a reference, but probably isn't: 'SPF' on line 248 -- Looks like a reference, but probably isn't: 'DKIM' on line 248 -- Looks like a reference, but probably isn't: 'MAIL' on line 474 -- Looks like a reference, but probably isn't: 'SMTP' on line 187 -- Looks like a reference, but probably isn't: 'MIME' on line 184 -- Looks like a reference, but probably isn't: 'IANA-HEADERS' on line 398 -- Looks like a reference, but probably isn't: 'RFC2822' on line 403 -- Looks like a reference, but probably isn't: 'TBD' on line 406 -- Looks like a reference, but probably isn't: 'IANA-CONSIDERATIONS' on line 413 ** Obsolete normative reference: RFC 2554 (ref. '1') (Obsoleted by RFC 4954) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2434, mentioned in '5', was also mentioned in '4'. ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2822 (ref. '6') (Obsoleted by RFC 5322) ** Downref: Normative reference to an Historic RFC: RFC 4406 (ref. '8') ** Obsolete normative reference: RFC 2821 (ref. '9') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4408 (ref. '10') (Obsoleted by RFC 7208) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 22 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: Standards Track May 19, 2007 5 Expires: November 20, 2007 7 Message Header for Indicating Sender Authentication Status 8 draft-kucherawy-sender-auth-header-05 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 November 20, 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. 45 Mail user agents (MUAs) may use this message header 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, [AUTH], [SENDERID], [SPF] and [DKIM] are the published 63 e-mail authentication methods in common use. As various methods 64 emerge, it is necessary to prepare for their appearance and encourage 65 convergence in the area of interfacing these filters to MUAs. 67 1.1. Purpose 69 The header defined in this memo is expected to serve several 70 purposes: 72 1. Convey to MUAs from filters and MTAs the results of various 73 sender authentication checks being applied; 75 2. Provide a common location for the presentation of this data; 77 3. Create an extensible framework for specifying new authentication 78 methods as such emerge; 80 4. Convey the results of sender authentication tests to later 81 filtering agents within the same "trust domain", as such agents 82 might apply more or less stringent checks based on sender 83 authentication results. 85 1.2. Requirements 87 This memo establishes no new requirements on existing protocols or 88 servers, as there is currently no standard place for the described 89 data to be collected or presented. 91 1.3. Definitions 93 This document occasionally uses terms that appear in capital letters. 94 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 95 NOT", and "MAY" appear capitalized, they are being used to indicate 96 particular requirements of this specification. A discussion of the 97 meanings of these terms appears in RFC2119. 99 Generally it is assumed that the work of applying sender 100 authentication schemes takes place at a border MTA, that is, an MTA 101 which acts as a gateway between the general Internet and the users 102 within an organizational boundary. This specification is written 103 with that assumption in mind. However, there are some sites at which 104 the entire mail infrastructure consists of a single host. In such 105 cases, such terms as "border MTA" and "delivery MTA" may well apply 106 to the same machine or even the very same agent. 108 2. Definition and Format of the Header 110 The new header being defined here is called "Authentication-Results". 111 It qualifies in [MAIL] [6] terms as a Structured Header Field, and 112 thus all of the related definitions in that document apply. 114 This new header SHOULD be added at the top of the message as it 115 transits MTAs which do authentication checks so that some idea of how 116 far away the checks were done can be inferred. It therefore also 117 qualifies in [MAIL] [6] terms as a Trace Header Field, and thus all 118 of the related definitions in that document apply. 120 The decommented value of the header consists of a hostname, some 121 whitespace, a "property=value" statement indicating which property 122 was selected to determine who sent the message and what value was 123 extracted from that property, followed by zero or more authentication 124 method names and a result associated with each, returned by the code 125 that implements the method. 127 As it is currently a matter of some debate, the header MAY appear 128 more than once in a single message, or more than one result MAY be 129 represented in a single header, or a combination of these MAY be 130 applied. 132 Formally, the header is specified as follows: 134 header = "Authentication-Results:" hostname CFWS 135 headerspec *(CFWS ";" CFWS method CFWS "=" CFWS result) 136 CFWS 138 hostname = domain 139 ; as defined in section 3.4.1 of [MAIL] 141 method = token [ "-" version ] 142 ; a method indicates which method's result is 143 ; is represented by "value", and is one of the methods 144 ; explicitly defined as valid in this document 145 ; or is an extension method as defined below 147 version = ( ALPHA / DIGIT ) 1*( "." ALPHA / DIGIT ) 148 ; indicates which version of the method was applied 150 result = "pass" / "fail" / "softfail" / "neutral" / 151 "temperror" / "permerror" 152 ; an indication of the results of the attempt to 153 ; authenticate the sender 155 headerspec = ptype CWFS "." CWFS property CWFS "=" CFWS value 156 ; an indication of which property of the message 157 ; was evaluated by the authentication scheme being 158 ; applied to yield the reported result 160 ptype = "smtp" / "header" / "body" / "policy" 161 ; indicates whether the property being evaluated was 162 ; a parameter to an [SMTP] command, or was a value taken 163 ; from a message header, or was some property of the 164 ; message body, or some other property evaluated by 165 ; the receiving MTA 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; if "ptype" is 171 ; "header", this indicates from which header the value 172 ; being evaluated was extracted; if "ptype" is 173 ; "body", this indicates the offset into the body at which 174 ; content of interest was detected; if "ptype" is "policy" 175 ; then this indicates the name of the policy which caused 176 ; this header to be added (see below) 178 value = token / mailbox 179 ; the value extracted from the message property defined 180 ; by the "ptype.property" construction; if the value is 181 ; intended ; to identify a mailbox, then it is a "mailbox" 182 ; as defined in section 3.4 of [MAIL] 184 The "token" is as defined in Appendix A of [MIME] [7]. 186 The list of commands eligible for use with the "smtp" ptype can be 187 found in [SMTP] [9] and subsequent amendments. 189 "CFWS" is as defined in section 3.2.3 of [MAIL] [6]. 191 The "ptype" and "property" used by each authentication method should 192 be defined in the specification for that method (or its amendments). 194 The "ptype" and "property" are case-insensitive. 196 A "ptype" of "policy" indicates a policy decision about the message 197 not specific to a property of the message that could be extracted. 198 For example, if a method would normally report a "ptype.property" of 199 "header.From" and no From: header was present, the method can use 200 "policy" to indicate that no conclusion about the authenticity of the 201 message could be reached. 203 If the parsed "ptype.property" construction clearly identifies a 204 mailbox (in particular, smtp.mail, smtp.rcpt, header.from, 205 header.sender), then the "value" MUST be a "mailbox". Other 206 properties (e.g. smtp.helo) may be evaluated, but the property MUST 207 still be expressed as a "token" for simplified parsing. 209 The six possible values of the "result" are: 211 pass: The message passed the authentication tests. (This may 212 require accessing an authentication policy of some kind published 213 by the sending domain.) 215 fail: The message failed the authentication tests. (This may 216 require accessing an authentication policy of some kind published 217 by the sending domain.) 219 softfail: The authentication method has either an explicit 220 (published by the sending domain) or implicit policy, but the 221 policy being used doesn't require successful authentication of all 222 messages from that domain, and the message failed the 223 authentication tests. 225 neutral: The authentication method completed without errors, but was 226 unable to reach either a positive or negative result about the 227 message. 229 temperror: A temporary (recoverable) error occurred attempting to 230 authenticate the sender; either the process couldn't be completed 231 locally, or (for methods requiring a policy to be accessed) there 232 was a temporary failure retrieving the sending domain's policy. A 233 later retry may produce a more final result. 235 permerror: A permanent (unrecoverable) error occurred attempting to 236 authenticate the sender; either the process couldn't be completed 237 locally, or (for methods requiring a policy to be accessed) there 238 was a permanent failure retrieving the sending domain's policy. 240 New methods not specified in this document MUST indicate which of 241 these should be returned when exceptions such as syntax errors are 242 detected. 244 3. Definition Of Initial Methods 246 As they are currently existing specifications for sender 247 authentication, it is appropriate to define an authentication method 248 identifier for each of [AUTH] [1], [DKIM] [3], [SPF] [10] and 249 [SENDERID] [8]. Therefore, the authentication method identifiers 250 "auth", "dkim", "spf" and "senderid" are hereby defined for MTAs 251 applying those specifications for e-mail sender authentication. 253 4. Adding The Header To A Message 255 This specification makes no attempt to evaluate the relative 256 strengths of various sender authentication methods that may become 257 available. As such, the order of the presented authentication 258 methods and results are not relevant since ultimately the importance 259 on any given method over another is the decision of the MUA that is 260 interpreting the value of the header. 262 The "method" MUST refer to an authentication method declared in this 263 memo, or in a subsequent one, or to an authentication method name 264 assigned by IANA. 266 An MTA compliant with this specification MUST add this header (after 267 performing one or more sender authentication tests) to indicate at 268 which host the test was done, which test got applied and what the 269 result was. If an MTA applies more than one such test, it MUST 270 either add this header once per test, or one header indicating all of 271 the results. An MTA MUST NOT add a result to an existing header. 273 An MTA adding this header in either form MUST use its own hostname 274 only. It MUST be a fully-qualified domain name. 276 For security reasons, an MTA conforming to this specification MUST 277 remove any discovered instance of this header for which the 278 "hostname" is its own, i.e. headers which claim to be from the MTA 279 but were added before the mail arrived at the MTA for processing. A 280 border MTA SHOULD also delete any discovered instance of this header 281 which claims to have been added within its trust boundary. For 282 example, a border MTA at mx.example.com MUST delete any instance of 283 this header claiming to come from mx.example.com and SHOULD delete 284 any instance of this header claiming to come from any host in 285 example.com prior to adding its own headers. This applies in both 286 directions so that hosts outside the domain cannot claim results MUAs 287 inside the domain might trust. However, care must be taken not to 288 remove headers added on messages which remain entirely within the 289 originator's trust boundary (i.e. local-to-local mail). 291 An MTA MAY add this header containing only the "hostname" portion to 292 explicitly indicate that no sender authentication schemes were 293 applied prior to delivery of this message. 295 4.1. Header Position and Interpretation 297 In order to ensure non-ambiguous results and avoid the impact of 298 false headers, an MUA SHOULD NOT interpret this header unless 299 specifically instructed to do so by the user. That is, this should 300 not be "on by default". Naturally then, users would not activate 301 such a feature unless they are certain the header will be added by 302 the receiving MTA that accepts the mail which is ultimately read by 303 the MUA, and instances of the header added by foreign MTAs will be 304 removed before delivery. 306 Furthermore, an MUA SHOULD NOT interpret this header unless the 307 hostname it bears appears to be one within its own trust domain as 308 configured by the user. 310 This header field SHOULD be treated as though it were a trace header 311 field as defined in section 3.6 of [MAIL] [6], and hence SHOULD not 312 be reordered and SHOULD be prepended to the message, so that there is 313 generally some indication upon delivery of where in the chain of 314 handling MTAs the sender authentcation was done. 316 Further discussion of this can be found in the Security 317 Considerations section below. 319 4.2. Extension Fields 321 Additional authentication method identifiers may be defined in the 322 future by later revisions or extensions to this specification. 323 Extension identifiers beginning with "x-" will never be defined as 324 standard fields; such names are reserved for experimental use. 325 Method identifiers NOT beginning with "x-" MUST be registered with 326 the Internet Assigned Numbers Authority (IANA) and published in an 327 RFC. 329 Extension identifiers may be defined for the following reasons: 331 1. To allow additional information from emergent authentication 332 systems to be communicated to MUAs. The names of such 333 identifiers should reflect the name of the method being defined, 334 but should not be needlessly long. 336 2. To allow the creation of "sub-identifiers" which indicate 337 different levels of authentication and differentiate between 338 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 340 Authentication method implementors are encouraged to provide adequate 341 information, via [MAIL] comments if necessary, to allow an MUA 342 developer to understand or relay ancilliary details of authentication 343 results. For example, if it might be of interest to relay what data 344 was used to perform an evaluation, such information could be relayed 345 as a comment in the header, such as: 347 Authentication-Results: mx.example.com; foo=pass (2 of 3 tests OK) 349 5. Discussion 351 This section discusses various implementation issues not specifically 352 related to security. Security issues are discussed in a later 353 section. 355 5.1. Legacy MUAs 357 Implementors of this proposal should be aware that many MUAs are 358 unlikely to be retrofit to support the new header and its semantics. 359 In the interests of convenience and quicker adaptation, a delivery 360 MTA might want to consider adding things that are processed by 361 existing MUAs as well as the header defined by this specification. 362 One suggestion is to provide a Priority: header with a value that 363 reflects the strength of the authentication that was accomplished, 364 e.g. "low" for weak or no authentication, "normal" or "high" for good 365 authentication. 367 Certainly some modern MUAs can filter based on the content of this 368 header, but as there is keen interest in having MUAs make some kind 369 of graphical representation of this header's meaning, other interim 370 means of doing so may be necessary while this proposal is adopted. 372 6. Conformance and Usage Requirements 374 An MTA or gateway conforms to this specification if it applies one or 375 more sender authentication mechanisms and inserts a header 376 corresponding to this specification after doing so and prior to 377 delivery. 379 MTAs that are relaying mail rather than delivering it MAY perform 380 sender authentication or even take actions based on the results 381 found, but MUST NOT add a "Authentication-Results" header if relaying 382 rather than rejecting or discarding at the gateway. Conversely, an 383 MTA doing local delivery MUST add this header prior to delivery the 384 message in order to be compliant. 386 A minimal implementation which does at least one sender 387 authentication check will add the header defined by this memo prior 388 to invoking local delivery procedures. 390 This specification places no restrictions on the processing of the 391 header's contents by user agents or distribution lists. It is 392 presented to those packages solely for their own information. 394 7. IANA Considerations 396 7.1. The Authentication-Results: header 398 Per [IANA-HEADERS] [5], the "Authentication-Results:" header field is 399 added to the IANA Permanent Message Header Field Registry. The 400 following is the registration template: 402 Header field name: Authentication-Results 403 Applicable protocol: mail ([RFC2822]) 404 Status: Standard 405 Author/Change controller: IETF 406 Specification document(s): [TBD] 407 Related information: 408 Requesting review of any proposed changes and additions to 409 this field is recommended. 411 7.2. Method Registry 413 Following the policies outlined in [IANA-CONSIDERATIONS] [4], names 414 of sender authentication methods supported by this specification must 415 be registered with IANA under the IETF Consensus method, with the 416 exception of experimental names as described above. 418 Each method must register a name, the RFC which defines it, which 419 "ptype" is appropriate for use with that method, and which "property" 420 should be reported by that method. 422 The initial set of entries in this registry is as follows: 424 +------------+------+--------+----------------------------+ 425 | Method | RFC | ptype | property | 426 +------------+------+--------+----------------------------+ 427 | auth | 2554 | smtp | auth | 428 +------------+------+--------+----------------------------+ 429 | domainkeys | TBD | header | From or Sender | 430 +------------+------+--------+----------------------------+ 431 | dkim | 4871 | header | i | 432 +------------+------+--------+----------------------------+ 433 | senderid | 4406 | header | name of header used by PRA | 434 +------------+------+--------+----------------------------+ 435 | spf | 4408 | smtp | from | 436 +------------+------+--------+----------------------------+ 438 8. Security Considerations 440 The following security considerations apply when applying or 441 processing the "Authentication-Results" header: 443 8.1. Non-conformant MTAs 445 An MUA that is aware of this specification which accesses a mailbox 446 whose mail is handled by a non-conformant MTA is in a position to 447 make false conclusions based on forged headers. A malicious user or 448 agent could forge a header using the destination MX for a receiving 449 domain as the hostname token in the value of the header, and with the 450 rest of the value claim that the sender was properly authenticated. 451 The non-conformant MTA would fail to strip the forged header, and the 452 MUA could trust it. 454 It is for this reason an MUA SHOULD NOT have processing of the 455 "Authentication-Results" header enabled by default; instead it must 456 be ignored, at least for the purposes of enacting filtering 457 decisions, unless specifically enabled by the user after verifying 458 that the MTA is compliant. It is acceptable to have an MUA aware of 459 this standard, but have an explicit list of hostnames whose 460 "Authentication-Results" headers are trustworthy, however this list 461 SHOULD initially be empty. 463 Proposed alternate solutions to this problem are nascent. Possibly 464 the simplest is a digital signature on the header which can be 465 verified by a posted public key. Another would be a means to 466 interrogate the MTA that added the header to see if it is actually 467 providing any sender authentication services and saw the message in 468 question. In either case, a method needs to exist to verify that the 469 host which appears to have added the header (a) actually did so, and 470 (b) is legitimately adding that header for this delivery. 472 8.2. Header Position 474 Despite the requirements of [MAIL] [6], headers can sometimes be 475 reordered enroute by intermediate MTAs. The goal of requiring header 476 addition only at the top of a message is an acknowledgement that some 477 MTAs do reorder headers, but most do not. Thus, in the general case, 478 there will be some indication of which MTAs (if any) handled the 479 message after the addition of the header defined here. 481 9. References 483 [1] Myers, J., "SMTP Service Extension for Authentication", 484 RFC 2554, March 1999. 486 [2] Delany, M., "Domain-based Email Authentication Using Public 487 Keys Advertised in the DNS (DomainKeys)", RFC RFC-DK, May 2007. 489 [3] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and 490 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 491 RFC 4817, May 2007. 493 [4] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 494 Considerations Section in RFCs", RFC 2434, October 1998. 496 [5] Klyne, G., Nottingham, M., and J. Mogul, "Registration 497 Procedures for Message Header Fields", RFC 2434, 498 September 2004. 500 [6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 502 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 503 Extensions (MIME) Part One: Format of Internet Message Bodies", 504 RFC 2045, November 1996. 506 [8] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 507 RFC 4406, April 2006. 509 [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 510 April 2001. 512 [10] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for 513 Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, 514 April 2006. 516 Appendix A. Acknowledgements 518 The author wishes to acknowledge the following for their review and 519 constructive criticism of this proposal: Tony Hansen of AT&T, Mark 520 Delany and Miles Libbey of Yahoo! Inc., Jim Fenton of Cisco, and 521 Eric Allman of Sendmail, Inc. 523 Appendix B. Public Discussion 525 Public discussion of this proposed specification is handled via the 526 mail-vet-discuss@mipassoc.org mailing list. The list is open. 527 Access to subscription forms and to list archives can be found at 528 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 530 Appendix C. Authentication-Results Examples 532 This section presents some examples of the use of this header to 533 indicate authentication results. 535 C.1. Trivial case; header not present 537 The trivial case: 539 From: sender@example.com 540 Received: from mail-router.example.com 541 (mail-router.example.com [1.2.3.4]) 542 by server.sendmail.com (8.11.6/8.11.6) 543 with ESMTP id g1G0r1kA003489; 544 Fri, Feb 15 2002 17:19:07 -0800 545 Date: Fri, Feb 15 2002 16:54:30 -0800 546 To: receiver@sendmail.com 547 Message-Id: <12345.abc@example.com> 548 Subject: here's a sample 550 Hello! Goodbye! 552 Example 1: Trivial case 554 The "Authentication-Results" header is completely absent. The MUA 555 may make no conclusion about the validity of the message. This could 556 be the case because the sender authentication services were not 557 available at the time of delivery, or no service is provided, or the 558 MTA is not in compliance with this specification. 560 C.2. Nearly-trivial case; service provided, but no authentication done 562 A message that was delivered by an MTA which conforms to this 563 standard but provides no actual sender authentication service: 565 Authentication-Results: mail-router.example.com 566 From: sender@example.com 567 Received: from mail-router.example.com 568 (mail-router.example.com [1.2.3.4]) 569 by server.sendmail.com (8.11.6/8.11.6) 570 with ESMTP id g1G0r1kA003489; 571 Fri, Feb 15 2002 17:19:07 -0800 572 Date: Fri, Feb 15 2002 16:54:30 -0800 573 To: receiver@sendmail.com 574 Message-Id: <12345.abc@example.com> 575 Subject: here's a sample 577 Hello! Goodbye! 579 Example 2: Header present but no authentication done 581 The "Authentication-Results" header is present, indicating that the 582 delivering MTA (which is named in the value of the header) conforms 583 to this specification. The absence of any method and result tokens 584 indicates that no sender authentication was done. 586 C.3. Service provided, authentication done 588 A message that was delivered by an MTA which conforms to this 589 standard and applied some sender authentication: 591 Authentication-Results: mail-router.example.com 592 smtp.auth=sender@example.com; auth=pass (cram-md5) 593 From: sender@example.com 594 Received: from dialup-1-2-3-4.example-isp.com 595 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 596 by mail-router.example.com (8.11.6/8.11.6) 597 with ESMTP id g1G0r1kA003489; 598 Fri, Feb 15 2002 17:19:07 -0800 599 Date: Fri, Feb 15 2002 16:54:30 -0800 600 To: receiver@sendmail.com 601 Message-Id: <12345.abc@example.com> 602 Subject: here's a sample 604 Hello! Goodbye! 606 Example 3: Header reporting results 607 The "Authentication-Results" header is present, indicating that the 608 delivering MTA (which is named in the value of the header) conforms 609 to this specification. Furthermore, the sender authenticated 610 herself/himself to the MTA via a method specified in [AUTH]. The 611 actual method is identified in a header comment after the method's 612 result is indicated. The MUA could extract and relay this extra 613 information if desired. 615 C.4. Service provided, several authentications done, single MTA 617 A message that was relayed inbound via a single MTA which conforms to 618 this standard and applied two different sender authentication checks: 620 Authentication-Results: mail-router.example.com 621 smtp.mail=sender@example.com; 622 auth=pass (cram-md5); spf=pass 623 Authentication-Results: mail-router.example.com 624 header.from=sender@example.com; sender-id=pass 625 From: sender@example.com 626 Received: from mail-router.example.com 627 (mail-router.example.com [1.2.3.4]) 628 by dialup-1-2-3-4.example-isp.com (8.11.6/8.11.6) 629 with ESMTP id g1G0r1kA003489; 630 Fri, Feb 15 2002 17:19:07 -0800 631 Date: Fri, Feb 15 2002 16:54:30 -0800 632 To: receiver@sendmail.com 633 Message-Id: <12345.abc@example.com> 634 Subject: here's a sample 636 Hello! Goodbye! 638 Example 4: Headers reporting results from one MTA 640 The "Authentication-Results" header is present, indicating the 641 delivering MTA (which is named in the value of the header) conforms 642 to this specification. Furthermore, the sender authenticated 643 herself/himself to the MTA via a method specified in [AUTH], and both 644 SPF and Sender-ID checks were done and passed. The MUA could extract 645 and relay this extra information if desired. 647 Two "Authentication-Results" headers are required because the methods 648 applied did not all base their results on the same property of the 649 message. 651 C.5. Service provided, several authentications done, different MTAs 653 A message that was relayed inbound by two different MTAs which 654 conform to this standard and applied multiple sender authentication 655 checks: 657 Authentication-Results: auth-checker.example.com 658 header.from=sender@example.com; sender-id=pass; 659 domainkeys=pass (good signature) 660 Received: from mail-router.example.com 661 (mail-router.example.com [10.11.12.13]) 662 by auth-checker.example.com (8.11.6/8.11.6) 663 with ESMTP id i7PK0sH7021929; 664 Fri, Feb 15 2002 17:19:22 -0800 665 Authentication-Results: mail-router.example.com 666 smtp.mail=sender@example.com; auth=pass (cram-md5); 667 spf=fail 668 Received: from dialup-1-2-3-4.example-isp.com 669 (dialup-1-2-3-4.example-isp.com [1.2.3.4]) 670 by mail-router.example.com (8.11.6/8.11.6) 671 with ESMTP id g1G0r1kA003489; 672 Fri, Feb 15 2002 17:19:07 -0800 673 DomainKey-Signature: a=rsa-sha1; s=gatsby; d=sendmail.com; 674 c=simple; q=dns; 675 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 676 From: sender@example.com 677 Date: Fri, Feb 15 2002 16:54:30 -0800 678 To: receiver@sendmail.com 679 Message-Id: <12345.abc@example.com> 680 Subject: here's a sample 682 Hello! Goodbye! 684 Example 5: Headers reporting results from multiple MTAs 686 The "Authentication-Results" header is present, indicating 687 conformance to this specification. It is present twice because two 688 different MTAs in the chain of delivery did authentication tests. 689 The first, "mail-router.example.com" reports that [AUTH] and SPF were 690 both used and [AUTH] passed but SPF failed. In the [AUTH] case, 691 additional data is provided in the comment field, which the MUA can 692 choose to render if desired. The second MTA, "auth- 693 checker.example.com", reports that it did a Sender-ID test and a 694 DomainKeys [2] test, both of which passed. Again, additional data 695 about one of the tests is provided as a comment, which the MUA may 696 choose to render. 698 Author's Address 700 Murray S. Kucherawy 701 Sendmail, Inc. 702 6425 Christie Ave., Suite 400 703 Emeryville, CA 94608 704 US 706 Phone: +1 510 594 5400 707 Email: msk+ietf@sendmail.com 709 Full Copyright Statement 711 Copyright (C) The IETF Trust (2007). 713 This document is subject to the rights, licenses and restrictions 714 contained in BCP 78, and except as set forth therein, the authors 715 retain all their rights. 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 720 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 721 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 722 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 Intellectual Property 727 The IETF takes no position regarding the validity or scope of any 728 Intellectual Property Rights or other rights that might be claimed to 729 pertain to the implementation or use of the technology described in 730 this document or the extent to which any license under such rights 731 might or might not be available; nor does it represent that it has 732 made any independent effort to identify any such rights. Information 733 on the procedures with respect to rights in RFC documents can be 734 found in BCP 78 and BCP 79. 736 Copies of IPR disclosures made to the IETF Secretariat and any 737 assurances of licenses to be made available, or the result of an 738 attempt made to obtain a general license or permission for the use of 739 such proprietary rights by implementers or users of this 740 specification can be obtained from the IETF on-line IPR repository at 741 http://www.ietf.org/ipr. 743 The IETF invites any interested party to bring to its attention any 744 copyrights, patents or patent applications, or other proprietary 745 rights that may cover technology that may be required to implement 746 this standard. Please address the information to the IETF at 747 ietf-ipr@ietf.org. 749 Acknowledgment 751 Funding for the RFC Editor function is provided by the IETF 752 Administrative Support Activity (IASA).