idnits 2.17.1 draft-kucherawy-sender-auth-header-16.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1551. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (September 23, 2008) is 5692 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 299, but not defined == Missing Reference: 'TBD' is mentioned on line 872, but not defined ** Obsolete normative reference: RFC 2822 (ref. 'MAIL') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4870 (ref. 'DOMAINKEYS') (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 13 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 September 23, 2008 5 Expires: March 27, 2009 7 Message Header Field for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-header-16 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. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 27, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This memo defines a new message header field for use with electronic 42 mail messages to indicate the results of message authentication 43 efforts. Mail user agents (MUAs) may use this message header field 44 to relay that information in a convenient way to users or to make 45 sorting and filtering decisions. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 53 2. Definition and Format of the Header . . . . . . . . . . . . . 7 54 2.1. General Description . . . . . . . . . . . . . . . . . . . 7 55 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 7 56 2.3. Authentication Identifier Fields . . . . . . . . . . . . . 10 57 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 10 58 2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 10 59 2.4.2. DKIM ADSP Results . . . . . . . . . . . . . . . . . . 11 60 2.4.3. SPF and Sender-ID Results . . . . . . . . . . . . . . 12 61 2.4.4. iprev Results . . . . . . . . . . . . . . . . . . . . 13 62 2.4.5. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 13 63 2.4.6. Extension Result Codes . . . . . . . . . . . . . . . . 14 64 2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15 65 2.5.1. Definition Of Initial Methods . . . . . . . . . . . . 15 66 2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 15 67 3. The 'iprev' Authentication Method . . . . . . . . . . . . . . 17 68 4. Adding The Header Field To A Message . . . . . . . . . . . . . 18 69 4.1. Header Position and Interpretation . . . . . . . . . . . . 18 70 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 19 71 5. Removing The Header Field . . . . . . . . . . . . . . . . . . 20 72 6. Conformance and Usage Requirements . . . . . . . . . . . . . . 21 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 7.1. The Authentication-Results: header . . . . . . . . . . . . 22 75 7.2. Email Authentication Method Name Registry . . . . . . . . 22 76 7.3. Email Authentication Result Name Registry . . . . . . . . 23 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 78 8.1. Forged Headers . . . . . . . . . . . . . . . . . . . . . . 26 79 8.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 26 80 8.3. Other Protocols . . . . . . . . . . . . . . . . . . . . . 27 81 8.4. Header Position . . . . . . . . . . . . . . . . . . . . . 27 82 8.5. Reverse IP Query Denial-Of-Service Attacks . . . . . . . . 27 83 8.6. Mitigation of Backscatter . . . . . . . . . . . . . . . . 27 84 8.7. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 28 85 8.8. Attacks Against Authentication Methods . . . . . . . . . . 28 86 8.9. Intentionally Malformed Header Fields . . . . . . . . . . 28 87 8.10. Compromised Internal Hosts . . . . . . . . . . . . . . . . 28 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 91 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 31 92 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 32 93 Appendix C. Authentication-Results Examples . . . . . . . . . . . 33 94 C.1. Trivial case; header field not present . . . . . . . . . . 33 95 C.2. Nearly-trivial case; service provided, but no 96 authentication done . . . . . . . . . . . . . . . . . . . 34 97 C.3. Service provided, authentication done . . . . . . . . . . 34 98 C.4. Service provided, several authentications done, single 99 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 100 C.5. Service provided, several authentications done, 101 different MTAs . . . . . . . . . . . . . . . . . . . . . . 36 102 C.6. Service provided, multi-tiered authentication done . . . . 38 103 Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 40 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 105 Intellectual Property and Copyright Statements . . . . . . . . . . 42 107 1. Introduction 109 This memo defines a new message header field for electronic mail 110 messages which presents the results of a message authentication 111 effort in a machine-readable format. The intent is to create a place 112 to collect such data when message authentication mechanisms are in 113 use so that a Mail User Agent (MUA) can provide a recommendation to 114 the user as to the validity of the message's origin and possibly the 115 integrity of its content. 117 This memo defines both the format of this new header field, and 118 discusses the implications of its presence or absence. 120 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 121 draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the 122 published e-mail authentication methods in common use. As various 123 methods emerge, it is necessary to prepare for their appearance and 124 encourage convergence in the area of interfacing these filters to 125 MUAs. 127 Although [SPF] defined a header field called Received-SPF for this 128 purpose, that header field is specific to the conveyance of SPF and 129 similar results only and thus is insufficient to satisfy the 130 requirements enumerated below. 132 1.1. Purpose 134 The header field defined in this memo is expected to serve several 135 purposes: 137 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the 138 results of various message authentication checks being applied; 140 2. Provide a common location for the presentation of this data; 142 3. Create an extensible framework for reporting new authentication 143 methods as such emerge; 145 4. Convey the results of message authentication tests to later 146 filtering agents within the same "trust domain", as such agents 147 might apply more or less stringent checks based on message 148 authentication results. 150 1.2. Requirements 152 This memo establishes no new requirements on existing protocols or 153 servers, as there is currently no standard place for the described 154 data to be collected or presented. 156 In particular, this memo establishes no requirement on MTAs to reject 157 or filter arriving messages which do not pass authentication checks. 158 The data conveyed by the defined header field's contents are for the 159 information of MUAs and filters and should be used at their 160 discretion. 162 1.3. Definitions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [KEYWORDS]. 168 A "border MTA" is an MTA which acts as a gateway between the general 169 Internet and the users within an organizational boundary. 171 A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which 172 actually enacts delivery of a message to a user's inbox or other 173 final delivery. 175 An "intermediate MTA" is an MTA which handles messages after a border 176 MTAs and before a delivery MTA. 178 +-----+ +-----+ +------------+ 179 | MUA |-->| MSA |-->| Border MTA | 180 +-----+ +-----+ +------------+ 181 | 182 | 183 V 184 +----------+ 185 | Internet | 186 +----------+ 187 | 188 | 189 V 190 +-----+ +-----+ +------------------+ +------------+ 191 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 192 +-----+ +-----+ +------------------+ +------------+ 194 Generally it is assumed that the work of applying message 195 authentication schemes takes place at a border MTA or a delivery MTA. 196 This specification is written with that assumption in mind. However, 197 there are some sites at which the entire mail infrastructure consists 198 of a single host. In such cases, such terms as "border MTA" and 199 "delivery MTA" may well apply to the same machine or even the very 200 same agent. It is also possible that message authentication could 201 take place on an intermediate MTA. Although this document doesn't 202 specifically describe such cases, they are not meant to be excluded 203 from this specification. 205 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 206 system architecture. 208 2. Definition and Format of the Header 210 This section gives a general overview of the format of the header 211 field being defined, and then provides more formal specification. 213 2.1. General Description 215 The new header field being defined here is called "Authentication- 216 Results". It is a Structured Header Field as defined in [MAIL] and 217 thus all of the related definitions in that document apply. 219 This new header field MUST be added at the top of the message as it 220 transits MTAs which do authentication checks so some idea of how far 221 away the checks were done can be inferred. It therefore should be 222 treated as a Trace Header Field as defined in [MAIL] and thus all of 223 the related definitions in that document apply. 225 The value of the header field (after removing [MAIL] comments) 226 consists of an authentication identifier, an optional version and 227 then a series of "method=result" statements indicating which 228 authentication method(s) were applied and their respective results, 229 and then, for each applied method, an optional "reason" string plus 230 optional "property=value" statements indicating which message 231 properties were evaluated to reach that conclusion. 233 The header field MAY appear more than once in a single message, or 234 more than one result MAY be represented in a single header field, or 235 a combination of these MAY be applied. 237 2.2. Formal Definition 239 Formally, the header field is specified as follows using [ABNF]: 241 header = "Authentication-Results:" [CFWS] authserv-id 242 [ CFWS version ] 243 ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF 244 ; the special case of "none" is used to indicate that no 245 ; message authentication is performed 247 authserv-id = dot-atom-text 248 ; see below for a description of this element; 249 ; "dot-atom-text" is defined in section 3.2.4 of [MAIL] 251 version = 1*DIGIT [CFWS] 252 ; indicates which version of this specification is in use; 253 ; this specification is version "1"; the absence of a version 254 ; implies this version of the specification 256 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 257 *( CFWS propspec ) 259 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 260 ; indicates which authentication method was evaluated 262 reasonspec = "reason" [CFWS] "=" [CFWS] value 263 ; a free-form comment on the reason the given result 264 ; was returned 266 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 267 ; an indication of which properties of the message 268 ; were evaluated by the authentication scheme being 269 ; applied to yield the reported result 271 method = token [ [CFWS] "/" [CFWS] version ] 272 ; a method indicates which method's result is 273 ; represented by "result", and is one of the methods 274 ; explicitly defined as valid in this document 275 ; or is an extension method as defined below 277 result = token 278 ; indicates the results of the attempt to authenticate 279 ; the message; see below for details 281 ptype = "smtp" / "header" / "body" / "policy" 282 ; indicates whether the property being evaluated was 283 ; a parameter to an [SMTP] command, or was a value taken 284 ; from a message header field, or was some property of 285 ; the message body, or some other property evaluated by 286 ; the receiving MTA 288 property = token 289 ; if "ptype" is "smtp", this indicates which [SMTP] 290 ; command provided the value which was evaluated by the 291 ; authentication scheme being applied; if "ptype" is 292 ; "header", this indicates from which header field the 293 ; value being evaluated was extracted; if "ptype" is 294 ; "body", this indicates the offset into the body at which 295 ; content of interest was detected; if "ptype" is "policy" 296 ; then this indicates the name of the policy which caused 297 ; this header field to be added (see below) 299 pvalue = [CFWS] ( token / addr-spec ) [CFWS] 300 ; the value extracted from the message property defined 301 ; by the "ptype.property" construction; if the value 302 ; identifies an address, then it is an "addr-spec" 303 ; as defined in section 3.4 of [MAIL] 305 The "token" and "value" are as defined in section 5.1 of [MIME]. 307 The "token" used in a "result" above is further constrained by the 308 necessity of being enumerated in Section 2.4 or an amendment to it. 310 See Section 2.3 for a description of the "authserv-id" element. 312 The list of commands eligible for use with the "smtp" ptype can be 313 found in [SMTP] and subsequent amendments. 315 "CFWS" is as defined in section 3.2.3 of [MAIL]. 317 The "propspec" may be omitted if for example the method was unable to 318 extract any properties to do its evaluation yet has a result to 319 report. 321 The "ptype" and "property" values used by each authentication method 322 should be defined in the specification for that method (or its 323 amendments). 325 The "ptype" and "property" are case-insensitive. 327 A "ptype" value of "policy" indicates a policy decision about the 328 message not specific to a property of the message that could be 329 extracted. For example, if a method would normally report a 330 "ptype.property" of "header.From" and no From: header field was 331 present, the method can use "policy" to indicate that no conclusion 332 about the authenticity of the message could be reached. 334 If the parsed "ptype.property" construction clearly identifies a 335 mailbox (in particular, smtp.mailfrom, smtp.rcpt, header.from, 336 header.sender), then the "pvalue" MUST be an "addr-spec". Other 337 properties (e.g. smtp.helo) may be evaluated, but the property MUST 338 still be expressed as a "token" for simplified parsing. 340 2.3. Authentication Identifier Fields 342 Every Authentication-Results header field has an authentication 343 identifier field ("authserv-id" above). This is similar in syntax to 344 a fully-qualified domain name. 346 The authentication identifier field provides a unique identifier that 347 refers to the authenticating service within a given mail 348 administrative domain. The uniqueness of the identifier is 349 guaranteed by the mail administrative domain that generates it and 350 must pertain to exactly that one mail administrative domain. This 351 identifier is intended to be machine-readable and not necessarily 352 meaningful to users. MUAs may use this identifier to determine 353 whether or not the data contained in an Authentication-Results header 354 field can be trusted. 356 For tracing and debugging purposes, the authentication identifier 357 SHOULD be the domain name of the MTA performing the authentication 358 check whose result is being reported. 360 Examples of valid authentication identifiers are mail.example.org, 361 engineering.example.net and ms1.newyork.example.com. 363 2.4. Result Values 365 Each individual authentication method returns one of a set of 366 specific result values. The subsections below define these results 367 for the authentication methods specifically supported by this memo. 368 New methods not specified in this document intended to be supported 369 by the header field defined in this memo MUST include a similar 370 result table either in its defining memo or in a supplementary one. 372 2.4.1. DKIM and DomainKeys Results 374 The result values used by [DKIM] and [DOMAINKEYS] are as follows: 376 none: The message was not signed. 378 pass: The message was signed, the signature(s) is (were) acceptable 379 to the verifier, and the signature(s) passed verification tests. 381 fail: The message was signed and the signature(s) is (were) 382 acceptable to the verifier, but it (they) failed the verification 383 test(s). 385 policy: The message was signed but the signature(s) is (were) not 386 acceptable to the verifier. 388 neutral: The message was signed but the signature(s) contained 389 syntax errors or were not otherwise able to be processed. This 390 result SHOULD also be used for other failures not covered 391 elsewhere in this list. 393 temperror: The message could not be verified due to some error which 394 is likely transient in nature, such as a temporary inability to 395 retrieve a public key. A later attempt may produce a final 396 result. 398 permerror: The message could not be verified due to some error which 399 is unrecoverable, such as a required header field being absent. A 400 later attempt is unlikley to produce a final result. 402 A signature is "acceptable to the verifier" if it passes local policy 403 checks (or there are no specific local policy checks). For example, 404 a verifier might require that the signature(s) on the message be 405 added by the domain identified in the From: header field of the 406 message, thus making third-party signatures unacceptable. 408 2.4.2. DKIM ADSP Results 410 The result values are used by [I-D.DRAFT-IETF-DKIM-SSP] as follows: 412 none: No DKIM author domain signing practises (ADSP) record was 413 published. 415 pass: A DKIM ADSP record was published which indicated the mail 416 should be signed with an author signature, and this message had 417 such a signature that validated. 419 unknown: No valid author signature was found on the message and 420 either the published ADSP was "unknown", or no policy was 421 published. 423 signed: A valid author signature was found on the message and the 424 published ADSP was "unknown". 426 fail: No valid author signature was found on the message and the 427 published ASDP record indicated an "all" policy. 429 discard: No valid author signature was found on the message and the 430 published ADSP record indicated a "discardable" policy. 432 nxdomain: Evaluating the ADSP for the author's domain indicated that 433 the author's domain does not exist. 435 temperror: A DKIM policy could not be retrieved due to some error 436 which is likely transient in nature, such as a temporary DNS 437 error. A later attempt may produce a final result. 439 permerror: A DKIM policy could not be retrieved due to some error 440 which is likely not transient in nature, such as a permanent DNS 441 error. A later attempt is unlikely to produce a final result. 443 2.4.3. SPF and Sender-ID Results 445 The result values are used by [SPF] and [SENDERID] as follows: 447 none: No policy records were published by the sender's domain. 449 neutral: The sender's domain has asserted that it cannot or does not 450 want to assert whether or not the sending IP address is authorized 451 to send mail on behalf of the sender's domain. 453 pass: The client is authorized to inject or relay mail on behalf of 454 the sender's domain. 456 policy: The client is authorized to inject or relay mail on behalf 457 of the sender's domain according to the authentication method's 458 algorithm, but local policy dictates that the result is 459 unacceptable. 461 hardfail: This client is explicitly not authorized to inject or 462 relay mail on behalf of the sender's domain. 464 softfail: The sender's domain believes the client was not authorized 465 to inject or relay mail on its behalf but is unwilling to make a 466 strong assertion to that effect. 468 temperror: The message could not be verified due to some error which 469 is likely transient in nature, such as a temporary inability to 470 retrieve a policy record from DNS. A later attempt may produce a 471 final result. 473 permerror: The message could not be verified due to some error which 474 is unrecoverable, such as a required header field being absent. A 475 later attempt is unlikley to produce a final result. 477 The distinction between and interpretation of "none" and "neutral" 478 under these methods is discussed further in [SPF]. 480 The "policy" result would be returned if, for example, [SPF] returned 481 as "pass" result, but a local policy check matches the sending domain 482 to one found in an explicit list of unacceptable domains (e.g. 483 spammers). 485 2.4.4. iprev Results 487 The result values are used by the "iprev" method, defined in 488 Section 3, are as follows: 490 pass: The reverse DNS evaluation succeeded, i.e. the "reverse" and 491 "forward" lookup results were in agreement. 493 hardfail: The reverse DNS evaluation failed. In particular, the 494 "reverse" and "forward" lookups each produced results but they 495 were not in agreement. 497 softfail: The reverse DNS evaluation failed. In particular, one or 498 both of the "reverse" and forward lookups returned no data (i.e. a 499 DNS reply code of NODATA). 501 temperror: The reverse DNS evaluation could not be completed due to 502 some error which is likely transient in nature, such as a 503 temporary DNS error. A later attempt may produce a final result. 505 permerror: The reverse DNS evaluation could not be completed due to 506 some error which is unrecoverable (e.g. a DNS reply code of NODATA 507 or NXDOMAIN). A later attempt is unlikely to produce a final 508 result. 510 There is no "none" for this method since any TCP connection 511 delivering e-mail has an IP address associated with it, so some kind 512 of evaluation will always be possible. 514 2.4.5. SMTP AUTH Results 516 The result values are used by the [AUTH] method are as follows: 518 none: SMTP authentication was not attempted. 520 pass: The SMTP client had authenicated to the server reporting the 521 result using the protocol described in [AUTH]. 523 fail: The SMTP client had attempted to authenticate to the server 524 using the protocol described in [AUTH] but was not successful, yet 525 continued to send the message about which a result is being 526 reported. 528 temperror: The SMTP client attempted to authenticate using the 529 protocol described in [AUTH] but was not able to complete the 530 attempt due to some error which is likely transient in nature, 531 such as a temporary LDAP lookup error. A later attempt may 532 produce a final result. 534 permerror: The SMTP client attempted to authenticate using the 535 protocol described in [AUTH] but was not able to complete the 536 attempt due to some error which is likely not transient in nature, 537 such as a permanent LDAP lookup error. A later attempt is not 538 likely produce a final result. 540 Note that an agent making use of the data provided by this header 541 field SHOULD consider "fail" and "temperror" to be the synonymous in 542 terms of message authentication, i.e. the client did not 543 authenticate. 545 2.4.6. Extension Result Codes 547 Additional result codes (extension results) may be defined in the 548 future by later revisions or extensions to this specification. 549 Extension results beginning with "x-" will never be defined as 550 standard fields; such names are reserved for experimental use. 551 Result codes not beginning with "x-" MUST be registered with the 552 Internet Assigned Numbers Authority (IANA) and published in an RFC. 553 See Section 7 for further details. 555 Implementations reporting new result codes MUST use the "x-" prefix 556 until such time as the new method is registered by IANA. 558 Extension results MUST only be used within trust domains that have 559 explicitly consented to use them. These results and the parameters 560 associated with them are not documented in RFCs. Therefore, they are 561 subject to change at any time and not suitable for production use. 562 Any MTA or MUA intended for production use SHOULD ignore or delete 563 any Authentication-Results header field that includes an extension 564 result. 566 2.5. Authentication Methods 568 This section defines the supported authentication methods and 569 discusses the proper means for applying experimental and other 570 extension methods. 572 2.5.1. Definition Of Initial Methods 574 As they are currently existing specifications for message 575 authentication, it is appropriate to define an authentication method 576 identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and 577 [SPF]. Therefore, the authentication method identifiers "auth", 578 "dkim", "domainkeys", "senderid" and "spf" respectively are hereby 579 defined for MTAs applying those specifications for e-mail message 580 authentication. 582 Furthermore, method "iprev" is defined in Section 3. 584 Finally, as its publication is imminent, this document also defines 585 "dkim-adsp" per [I-D.DRAFT-IETF-DKIM-SSP]. 587 See Section 7 for details. 589 2.5.2. Extension Methods 591 Additional authentication method identifiers (extension methods) may 592 be defined in the future by later revisions or extensions to this 593 specification. Extension methods beginning with "x-" will never be 594 defined as standard fields; such names are reserved for experimental 595 use. Method identifiers not beginning with "x-" MUST be registered 596 with the Internet Assigned Numbers Authority (IANA) and published in 597 an RFC. See Section 7 for further details. 599 Extension methods may be defined for the following reasons: 601 1. To allow additional information from new authentication systems 602 to be communicated to MUAs. The names of such identifiers should 603 reflect the name of the method being defined, but should not be 604 needlessly long. 606 2. To allow the creation of "sub-identifiers" which indicate 607 different levels of authentication and differentiate between 608 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 610 Implementations of new methods MUST use the "x-" prefix until such 611 time as the new method is registered by IANA. 613 Authentication method implementors are encouraged to provide adequate 614 information, via [MAIL] comments if necessary, to allow an MUA 615 developer to understand or relay ancilliary details of authentication 616 results. For example, if it might be of interest to relay what data 617 was used to perform an evaluation, such information could be relayed 618 as a comment in the header field, such as: 620 Authentication-Results: mx.example.com; 621 foo=pass bar.baz=blob (2 of 3 tests OK) 623 Experimental method identifiers MUST only be used within trust 624 domains that have explicitly consented to use them. These method 625 identifiers and the parameters associated with them are not 626 documented in RFCs. Therefore, they are subject to change at any 627 time and not suitable for production use. Any MTA or MUA intended 628 for production use SHOULD ignore or delete any Authentication-Results 629 header field that includes an experimental method identifier. 631 3. The 'iprev' Authentication Method 633 This section defines an additional authentication method called 634 "iprev". 636 In general, "iprev" is an attempt to verify that a client appears to 637 be valid based on some DNS queries. Upon receiving a session 638 initiation of some kind from a client, the IP address of the client 639 peer is queried for matching names (i.e. a number-to-name 640 translation, also known as a "reverse lookup" or a "PTR" record 641 query). Once that result is acquired, a lookup of each of the names 642 (i.e. a name-to-number translation, or an "A" record query) thus 643 retrieved is done. The response to this second check should result 644 in at least one mapping back to the client's IP address. 646 More algorithmically: If the client peer's IP address is A, the list 647 of names to which A maps (after a "PTR" query) is the set N, and the 648 union of IP addresses to which each member of N maps (after an "A" 649 query) is L, then this test is successful if A is an element of L. 651 Section 5.5 of [SPF] contains more detail about this process as well 652 as some discussion of possible denial-of-service attacks. [DNS-IP6] 653 discusses the format of this query for the IPv6 case. 655 A successful test using this algorithm constitutes a result of "pass" 656 since the domain in which the client's PTR claims it belongs has 657 confirmed that claim. A failure to match constitutes a "hardfail". 658 There is no case in which "softfail" or "neutral" can be returned. 659 The remaining "temperror" and "permerror" cases refer respectively to 660 temporary and permanent DNS query errors. 662 There is some contention regarding the wisdom and reliability of this 663 test. For example, in some regions it can be difficult for this test 664 ever to pass because the practise of arranging to match the forward 665 and reverse DNS is infrequently observed. Therefore, the actual 666 implementation details of how a verifier performs an "iprev" test are 667 not specified here. The verifier MAY report a successful or failed 668 "iprev" test at its discretion having done some kind of check of the 669 validity of the connection's identity using DNS. It is incumbent 670 upon an agent making use of the reported "iprev" result to understand 671 what exactly that particular verifier is attempting to report. 673 4. Adding The Header Field To A Message 675 This specification makes no attempt to evaluate the relative 676 strengths of various message authentication methods that may become 677 available. As such, the order of the presented authentication 678 methods and results MUST NOT be used to determine the importance or 679 strength of any given method over another. Instead, the MUA must 680 interpret the result of each method based on its knowledge of what 681 that method evaluates. 683 Each "method" MUST refer to an authentication method declared in the 684 IANA registry, or an extension method as defined in Section 2.5.2, 685 and each "result" MUST refer to a result code declared in the IANA 686 registry, or an extension result code as defined in Section 2.4.6. 687 See Section 7 for further information about the registered methods 688 and result codes. 690 An MTA compliant with this specification MUST add this header field 691 (after performing one or more message authentication tests) to 692 indicate at which host which the test was done, which test got 693 applied and what the result was. If an MTA applies more than one 694 such test, it MUST either add this header field once per test, or one 695 header field indicating all of the results. An MTA MUST NOT add a 696 result to an existing header. 698 An MTA MAY add this header field containing only the authentication 699 identifier portion to indicate explicitly that no message 700 authentication schemes were applied prior to delivery of this 701 message. 703 4.1. Header Position and Interpretation 705 In order to ensure non-ambiguous results and avoid the impact of 706 false header fields, an MUA SHOULD NOT interpret this header field 707 unless specifically instructed to do so by the user or administrator. 708 That is, this interpretation should not be "on by default". 709 Naturally then, users or administrators should not activate such a 710 feature unless they are certain the header field will be added by the 711 border MTA that accepts the mail that is ultimately read by the MUA, 712 and instances of the header field appearing to be from within the 713 trust domain but actually added by foreign MTAs will be removed 714 before delivery. 716 Furthermore, an MUA SHOULD NOT interpret this header field unless the 717 authentication identifier it bears appears to be one within its own 718 trust domain as configured by the user or administrator. 720 An MUA MUST ignore any result reported using a "result" not specified 721 in the result code registry, or a "ptype" not listed in the 722 corresponding registry for such values as defined in Section 7. 723 Moreover, an MUA MUST ignore a result indicated for any "method" it 724 does not support. 726 An MUA SHOULD NOT reveal these results to end users unless the 727 results are accompanied by, at a minimum, some associated reputation 728 data about the message that was authenticated. For example, an 729 attacker could register examp1e.com (note the digit "one") and send 730 signed mail to intended victims; a verifier would detect that the 731 signature was valid and report a "pass" even though it's clear the 732 domain name was intended to mislead. See Section 8.2 for further 733 discussion. 735 As stated in Section 2.1, this header field SHOULD be treated as 736 though it were a trace header field as defined in section 3.6 of 737 [MAIL], and hence MUST NOT be reordered and MUST be prepended to the 738 message, so that there is generally some indication upon delivery of 739 where in the chain of handling MTAs the message authentication was 740 done. 742 Further discussion of this can be found in Section 8 below. 744 4.2. Local Policy Enforcement 746 If a site's local policy is to consider a non-recoverable failure 747 result (e.g. "fail" for DKIM, "hardfail" for SPF or "discard" for 748 DKIM-ADSP) for any particular authentication method as justification 749 to reject the message completely, the border MTA SHOULD issue an 750 [SMTP] rejection response to the message rather than adding this 751 header with the failure result and allowing it to proceed toward 752 delivery. This is more desirable than allowing the message to reach 753 an internal host's MTA or spam filter, thus possibly generating a 754 local rejection such as a [DSN] to a forged originator. 756 The same MAY also be done for local policy decisions overriding the 757 results of the authentication methods (e.g. the "policy" result codes 758 described in Section 4.2. 760 Such rejections at the SMTP protocol level are not possible if local 761 policy is enforced at the MUA and not the MTA. Unfortunately, this 762 may be a common scenario. 764 5. Removing The Header Field 766 For security reasons, any MTA conforming to this specification MUST 767 delete any discovered instance of this header field which claims to 768 have been added within its trust boundary and did not come from 769 another trusted MTA. For example, an MTA (border or otherwise) for 770 example.com receiving a message MUST delete any instance of this 771 header field bearing an authentication identifier indicating the 772 header field was added within example.com prior to adding its own 773 header fields. This may mean each MTA will have to be equipped with 774 a list of internal MTAs known to be compliant (and hence 775 trustworthy). 777 Furthermore, a border MTA MAY elect simply to remove all instances of 778 this header field on mail crossing into its trust boundary. 780 A formal definition of "trust boundary" is deliberately not made 781 here. It is entirely possible that a border MTA for example.com 782 might explicitly trust authentication results asserted by upstream 783 host example.net even though they exist in completely disjoint 784 administrative boundaries. In that case the border MTA MAY elect not 785 to delete those results; moreover, the upstream host doing some 786 authentication work could apply a signing technology such as [DKIM] 787 on its own results to assure downstream hosts of their authenticity. 788 An example of this is provided in Appendix C. 790 Similarly, in the case of messages signed using [DKIM] or other 791 message signing methods that sign headers, this may invalidate one or 792 more signature on the message if they included the header field to be 793 removed at the time of signing. This behaviour can be desirable 794 since there's little value in validating the signature on a message 795 with forged headers. However, signing agents MAY therefore elect to 796 omit these header fields from signing to avoid this situation. 798 An MTA SHOULD remove any instance of this header bearing a version 799 (express or implied) that it does not support. However, an MTA MUST 800 remove such a header if the [SMTP] connection relaying the message is 801 from not a trusted internal MTA. 803 6. Conformance and Usage Requirements 805 An MTA or gateway conforms to this specification if it applies one or 806 more message authentication mechanisms and inserts a header field 807 corresponding to this specification after doing so and prior to 808 delivery (per Section 4) and removes apparently improper headers (per 809 Section 5). 811 MTAs that are relaying mail rather than delivering it, i.e. are not 812 part of an intended recipient's trust boundary, MAY perform message 813 authentication or even take actions based on the results found, but 814 SHOULD NOT add an "Authentication-Results" header field if relaying 815 (rather than rejecting or discarding at the gateway). Conversely, an 816 MTA doing local delivery and some form of message authentication MUST 817 add this header field prior to delivering the message in order to be 818 compliant. An exception to the former case is described in 819 Section 5. 821 A minimal implementation that does at least one message 822 authentication check will add the header field defined by this memo 823 prior to invoking local delivery procedures. 825 7. IANA Considerations 827 IANA is requested to register a new header field and to create a new 828 table as described below. 830 7.1. The Authentication-Results: header 832 Per [IANA-HEADERS], the "Authentication-Results:" header field is 833 added to the IANA Permanent Message Header Field Registry. The 834 following is the registration template: 836 Header field name: Authentication-Results 837 Applicable protocol: mail ([MAIL]) 838 Status: Standard 839 Author/Change controller: IETF 840 Specification document(s): [TBD] 841 Related information: 842 Requesting review of any proposed changes and additions to 843 this field is recommended. 845 7.2. Email Authentication Method Name Registry 847 Names of message authentication methods supported by this 848 specification must be registered with IANA, with the exception of 849 experimental names as described in Section 2.5.2. 851 New entries are assigned only for values that have been documented in 852 a published RFC that has IETF Review, per [IANA-CONSIDERATIONS]. 853 Each method must register a name, the specification that defines it, 854 one or more "ptype" values appropriate for use with that method, and 855 which "property" value(s) should be reported by that method. 857 The initial set of entries in this registry is as follows: 859 +------------+----------+--------+----------------+--------------------+ 860 | Method | Defined | ptype | property | value | 861 +------------+----------+--------+----------------+--------------------+ 862 | auth | RFC4954 | smtp | auth | AUTH parameter of | 863 | | | | | the SMTP MAIL | 864 | | | | | command | 865 +------------+----------+--------+----------------+--------------------+ 866 | dkim | RFC4871 | header | d | value of | 867 | | | | | signature "d" tag | 868 | | | +----------------+--------------------+ 869 | | | | i | value of | 870 | | | | | signature "i" tag | 871 +------------+----------+--------+----------------+--------------------+ 872 | dkim-adsp | [TBD] | header | from | value of From | 873 | | | | | header field | 874 | | | | | w/comments removed | 875 +------------+----------+--------+----------------+--------------------+ 876 | domainkeys | RFC4870 | header | from | value of From | 877 | | | | | header field | 878 | | | | | w/comments removed | 879 | | | +----------------+--------------------+ 880 | | | | sender | value of Sender | 881 | | | | | header field | 882 | | | | | w/comments removed | 883 +------------+----------+--------+----------------+--------------------+ 884 | iprev | this | policy | iprev | client IP address | 885 | | document | | | | 886 +------------+----------+--------+----------------+--------------------+ 887 | senderid | RFC4406 | header | name of header | value of header | 888 | | | | field used by | field used by PRA | 889 | | | | PRA | w/comments removed | 890 +------------+----------+--------+----------------+--------------------+ 891 | spf | RFC4408 | smtp | mailfrom | envelope sender | 892 | | +--------+----------------+--------------------+ 893 | | | smtp | helo | HELO/EHLO value | 894 +------------+----------+--------+----------------+--------------------+ 896 7.3. Email Authentication Result Name Registry 898 Names of message authentication result codes supported by this 899 specification must be registered with IANA, with the exception of 900 experimental codes as described in Section 2.4.6. 902 New entries are assigned only for result codes that have been 903 documented in a published RFC that has IETF Review, per 904 [IANA-CONSIDERATIONS]. Each code must register a name, the document 905 which establishes the registration, the authentication method(s) 906 which uses it, and either a definition of the semantics of its use or 907 a reference to the place where those semantics are defined. 909 The initial set of entries in this registry is as follows: 911 +-----------+----------+----------------+------------------------------+ 912 | Code | Defined | Auth Method(s) | Meaning | 913 +-----------+----------+----------------+------------------------------+ 914 | none | this | dkim | section 2.4.1 | 915 | | document | domainkeys | | 916 | | +----------------+------------------------------+ 917 | | | dkim-adsp | section 2.4.2 | 918 | | +----------------+------------------------------+ 919 | | | spf | section 2.4.3 | 920 | | | sender-id | | 921 | | +----------------+------------------------------+ 922 | | | auth | section 2.4.5 | 923 +-----------+----------+----------------+------------------------------+ 924 | pass | this | dkim | section 2.4.1 | 925 | | document | domainkeys | | 926 | | +----------------+------------------------------+ 927 | | | dkim-adsp | section 2.4.2 | 928 | | +----------------+------------------------------+ 929 | | | spf | section 2.4.3 | 930 | | | sender-id | | 931 | | +----------------+------------------------------+ 932 | | | iprev | section 2.4.4 | 933 | | +----------------+------------------------------+ 934 | | | auth | section 2.4.5 | 935 +-----------+----------+----------------+------------------------------+ 936 | fail | this | dkim | section 2.4.1 | 937 | | document | domainkeys | | 938 | | +----------------+------------------------------+ 939 | | | dkim-adsp | section 2.4.2 | 940 | | +----------------+------------------------------+ 941 | | | auth | section 2.4.5 | 942 +-----------+----------+----------------+------------------------------+ 943 | policy | this | dkim | section 2.4.1 | 944 | | document | domainkeys | | 945 +-----------+----------+----------------+------------------------------+ 946 | neutral | this | dkim | section 2.4.1 | 947 | | document | domainkeys | | 948 | | +----------------+------------------------------+ 949 | | | spf | section 2.4.3 | 950 | | | sender-id | | 951 +-----------+----------+----------------+------------------------------+ 952 | temperror | this | dkim | section 2.4.1 | 953 | | document | domainkeys | | 954 | | +----------------+------------------------------+ 955 | | | dkim-adsp | section 2.4.2 | 956 | | +----------------+------------------------------+ 957 | | | spf | section 2.4.3 | 958 | | | sender-id | | 959 | | +----------------+------------------------------+ 960 | | | iprev | section 2.4.4 | 961 | | +----------------+------------------------------+ 962 | | | auth | section 2.4.5 | 963 +-----------+----------+----------------+------------------------------+ 964 | permerror | this | dkim | section 2.4.1 | 965 | | document | domainkeys | | 966 | | +----------------+------------------------------+ 967 | | | dkim-adsp | section 2.4.2 | 968 | | +----------------+------------------------------+ 969 | | | spf | section 2.4.3 | 970 | | | sender-id | | 971 | | +----------------+------------------------------+ 972 | | | iprev | section 2.4.4 | 973 | | +----------------+------------------------------+ 974 | | | auth | section 2.4.5 | 975 +-----------+----------+----------------+------------------------------+ 976 | nxdomain | this | dkim-adsp | section 2.4.2 | 977 | | document | | | 978 +-----------+----------+----------------+------------------------------+ 979 | signed | this | dkim-adsp | section 2.4.2 | 980 | | document | | | 981 +-----------+----------+----------------+------------------------------+ 982 | unknown | this | dkim-adsp | section 2.4.2 | 983 | | document | | | 984 +-----------+----------+----------------+------------------------------+ 985 | discard | this | dkim-adsp | section 2.4.2 | 986 | | document | | | 987 +-----------+----------+----------------+------------------------------+ 988 | hardfail | this | spf | section 2.4.3 | 989 | | document | sender-id | | 990 | | +----------------+------------------------------+ 991 | | | iprev | section 2.4.4 | 992 +-----------+----------+----------------+------------------------------+ 993 | softfail | this | spf | section 2.4.3 | 994 | | document | sender-id | | 995 | | +----------------+------------------------------+ 996 | | | iprev | section 2.4.4 | 997 +-----------+----------+----------------+------------------------------+ 998 8. Security Considerations 1000 The following security considerations apply when applying or 1001 processing the "Authentication-Results" header field: 1003 8.1. Forged Headers 1005 An MUA that accesses a mailbox whose mail is handled by a non- 1006 conformant MTA, and understands Authentication-Results header fields, 1007 could potentially make false conclusions based on forged header 1008 fields. A malicious user or agent could forge a header field using 1009 the destination MX for a receiving domain as the hostname token in 1010 the value of the header, and with the rest of the value claim that 1011 the message was properly authenticated. The non-conformant MTA would 1012 fail to strip the forged header field, and the MUA could 1013 inappropriately trust it. 1015 It is for this reason an MUA should not have processing of the 1016 "Authentication-Results" header field enabled by default; instead it 1017 should be ignored, at least for the purposes of enacting filtering 1018 decisions, unless specifically enabled by the user or administrator 1019 after verifying that the border MTA is compliant. It is acceptable 1020 to have an MUA aware of this specification, but have an explicit list 1021 of hostnames whose "Authentication-Results" header fields are 1022 trustworthy; however, this list should initially be empty. 1024 Proposed alternate solutions to this problem are nascent. Possibly 1025 the simplest is a digital signature on the header field that can be 1026 verified by a posted public key. Another would be a means to 1027 interrogate the MTA that added the header field to see if it is 1028 actually providing any message authentication services and saw the 1029 message in question, but this isn't especially palatable. In either 1030 case, a mechanism needs to exist to verify that the host that appears 1031 to have added the header field (a) actually did so, and (b) is 1032 legitimately adding that header field for this delivery. 1034 8.2. Misleading Results 1036 Until some form of service for querying the reputation of a sending 1037 agent is widely deployed, the existence of this header field 1038 indicating a "pass" does not render the message trustworthy. It is 1039 possible for an arriving piece of spam or other undesirable mail to 1040 pass checks by several of the methods enumerated above (e.g. a piece 1041 of spam signed using [DKIM] by the originator of the spam, which 1042 might be a spammer or a compromised system). In particular, this 1043 issue is not resolved by forged header removal discussed above. 1045 Hence, MUAs must take some care with use of this header even after 1046 possibly malicious headers are scrubbed. 1048 8.3. Other Protocols 1050 Mitigation of the forged header attack can also be accomplished by 1051 moving the authentication results data into meta-data associated with 1052 the message. In particular, an [SMTP] extension could be established 1053 which is used to communicate authentication results from the border 1054 MTA to intermediate and delivery MTAs; the latter of these could 1055 arrange to store the authentication results as meta-data retrieved 1056 and rendered along with the message by an [IMAP] client aware of a 1057 similar extension in that protocol. The delivery MTA would be told 1058 to trust data via this extension only from MTAs it trusts, and border 1059 MTAs would not accept data via this extension from any source. There 1060 is no vector in such an arrangement for forgery of authentication 1061 data by an outside agent. 1063 8.4. Header Position 1065 Despite the requirements of [MAIL], header fields can sometimes be 1066 reordered enroute by intermediate MTAs. The goal of requiring header 1067 field addition only at the top of a message is an acknowledgement 1068 that some MTAs do reorder header fields, but most do not. Thus, in 1069 the general case, there will be some indication of which MTAs (if 1070 any) handled the message after the addition of the header field 1071 defined here. 1073 8.5. Reverse IP Query Denial-Of-Service Attacks 1075 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 1076 for verifiers that attempt to DNS-based identity verification of 1077 arriving client connections. A verifier wishing to do this check and 1078 report this information SHOULD take care not to go to unbounded 1079 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1080 making use of an "iprev" result specified by this memo SHOULD be 1081 aware of the algorithm used by the verifier reporting the result and 1082 thus be aware of its limitations. 1084 8.6. Mitigation of Backscatter 1086 Failing to follow the instructions of Section 4.2 can result in a 1087 denial-of-service attack caused by the generation of [DSN] messages 1088 (or equivalent) to addresses which did not send the messages being 1089 rejected. 1091 8.7. Internal MTA Lists 1093 Section 5 describes a procedure for scrubbing headers which may 1094 contain forged authentication results about a message. A compliant 1095 installation will have to include at each MTA a list of other MTAs 1096 known to be compliant and trustworthy. Failing to keep this list 1097 current as internal infrastructure changes may expose a domain to 1098 attack. 1100 8.8. Attacks Against Authentication Methods 1102 If an attack becomes known against an authentication method, clearly 1103 then the agent verifying that method can be fooled into thinking an 1104 inauthentic message is authentic, and thus the value of this header 1105 field can be misleading. It follows that any attack against the 1106 authentication methods supported by this document (and later 1107 amendments to it) is also a security consideration here. 1109 8.9. Intentionally Malformed Header Fields 1111 It is possible for an attacker to add an Authentication-Results: 1112 header field which is extraordinarily large or otherwise malformed in 1113 an attempt to discover or exploit weaknesses in header field parsing 1114 code. Implementors must thoroughly verify all such header fields 1115 received from MTAs and be robust against intentionally as well as 1116 unintentionally malformed header fields. 1118 8.10. Compromised Internal Hosts 1120 An internal MUA or MTA which has been compromised could generate mail 1121 with a forged From: header and a forged Authentication-Results: 1122 header which endorses it. Although it is clearly a larger concern to 1123 have compromised internal machines than it is to prove the value of 1124 this header, this risk can be mitigated by arranging that internal 1125 MTAs will remove this header field if it claims to have been added by 1126 a trusted border MTA (as described above) yet the [SMTP] connection 1127 is not coming from an internal machine known to be running an 1128 authorized MTA. However, in such a configuration, legitimate MTAs 1129 will have to add this header field when legitimate internal-only 1130 messages are generated. This is also covered in Section 5. 1132 9. References 1134 9.1. Normative References 1136 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1137 Specifications: ABNF", RFC 5234, January 2008. 1139 [IANA-HEADERS] 1140 Klyne, G., Nottingham, M., and J. Mogul, "Registration 1141 Procedures for Message Header Fields", RFC 3864, 1142 September 2004. 1144 [KEYWORDS] 1145 Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", RFC 2119, March 1997. 1148 [MAIL] Resnick, P., "Internet Message Format", RFC 2822, 1149 April 2001. 1151 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1152 Extensions (MIME) Part One: Format of Internet Message 1153 Bodies", RFC 2045, November 1996. 1155 9.2. Informative References 1157 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1158 for Authentication", RFC 4954, July 2007. 1160 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1161 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1162 Signatures", RFC 4871, May 2007. 1164 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1165 "DNS Extensions to Support IP Version 6", RFC 3596, 1166 October 2003. 1168 [DOMAINKEYS] 1169 Delany, M., "Domain-based Email Authentication Using 1170 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1171 May 2007. 1173 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1174 for Delivery Status Notifications", RFC 3464, 1175 January 2003. 1177 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 1178 Crocker, D., "Internet Mail Architecture", 1179 I-D draft-crocker-email-arch, May 2007. 1181 [I-D.DRAFT-IETF-DKIM-SSP] 1182 Allman, E., Delany, M., and J. Fenton, "DKIM Author 1183 Signing Practices", I-D draft-ietf-dkim-ssp, January 2008. 1185 [IANA-CONSIDERATIONS] 1186 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1187 IANA Considerations Section in RFCs", RFC 5226, 1188 October 1998. 1190 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 1191 4rev1", RFC 3501, March 2003. 1193 [SENDERID] 1194 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 1195 RFC 4406, April 2006. 1197 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1198 April 2001. 1200 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 1201 for Authorizing Use of Domains in E-Mail, Version 1", 1202 RFC 4408, April 2006. 1204 Appendix A. Acknowledgements 1206 The author wishes to acknowledge the following for their review and 1207 constructive criticism of this proposal: Eric Allman, Dave Crocker, 1208 Mark Delany, Frank Ellermann, Jim Fenton, Philip Guenther, Tony 1209 Hansen, Paul Hoffman, Eliot Lear, John Levine, Miles Libbey, Charles 1210 Lindsey, S. Moonesamy, Juan Altmayer Pizzorno, Michael Thomas. 1212 Appendix B. Legacy MUAs 1214 Implementors of this proposal should be aware that many MUAs are 1215 unlikely to be retrofitted to support the new header field and its 1216 semantics. In the interests of convenience and quicker adaptation, a 1217 delivery MTA might want to consider adding things that are processed 1218 by existing MUAs in addition to the Authentication-Results header 1219 field. One suggestion is to include a Priority: header field, on 1220 messages that don't already have such a header field, containing a 1221 value that reflects the strength of the authentication that was 1222 accomplished, e.g. "low" for weak or no authentication, "normal" or 1223 "high" for good or strong authentication. 1225 Some modern MUAs can already filter based on the content of this 1226 header field. However, there is keen interest in having MUAs make 1227 some kind of graphical representation of this header field's meaning 1228 to end users. Until this capability is added, other interim means of 1229 conveying authentication results may be necessary while this proposal 1230 and its successors are adopted. 1232 Appendix C. Authentication-Results Examples 1234 This section presents some examples of the use of this header field 1235 to indicate authentication results. 1237 C.1. Trivial case; header field not present 1239 The trivial case: 1241 Received: from mail-router.example.com 1242 (mail-router.example.com [192.0.2.1]) 1243 by server.sendmail.com (8.11.6/8.11.6) 1244 with ESMTP id g1G0r1kA003489; 1245 Fri, Feb 15 2002 17:19:07 -0800 1246 From: sender@example.com 1247 Date: Fri, Feb 15 2002 16:54:30 -0800 1248 To: receiver@sendmail.com 1249 Message-Id: <12345.abc@example.com> 1250 Subject: here's a sample 1252 Hello! Goodbye! 1254 Example 1: Trivial case 1256 The "Authentication-Results" header field is completely absent. The 1257 MUA may make no conclusion about the validity of the message. This 1258 could be the case because the message authentication services were 1259 not available at the time of delivery, or no service is provided, or 1260 the MTA is not in compliance with this specification. 1262 C.2. Nearly-trivial case; service provided, but no authentication done 1264 A message that was delivered by an MTA that conforms to this 1265 specification but provides no actual message authentication service: 1267 Authentication-Results: mail-router.example.com; none 1268 Received: from mail-router.example.com 1269 (mail-router.example.com [192.0.2.1]) 1270 by server.sendmail.com (8.11.6/8.11.6) 1271 with ESMTP id g1G0r1kA003489; 1272 Fri, Feb 15 2002 17:19:07 -0800 1273 From: sender@example.com 1274 Date: Fri, Feb 15 2002 16:54:30 -0800 1275 To: receiver@sendmail.com 1276 Message-Id: <12345.abc@example.com> 1277 Subject: here's a sample 1279 Hello! Goodbye! 1281 Example 2: Header present but no authentication done 1283 The "Authentication-Results" header field is present, indicating that 1284 the delivering MTA (which is named in the value of the header field) 1285 conforms to this specification. The presence of "none" (and the 1286 absence of any method and result tokens) indicates that no message 1287 authentication was done. 1289 C.3. Service provided, authentication done 1291 A message that was delivered by an MTA that conforms to this 1292 specification and applied some message authentication: 1294 Authentication-Results: mail-router.example.com; 1295 spf=pass smtp.mailfrom=sender@example.net 1296 Received: from dialup-1-2-3-4.example.net 1297 (dialup-1-2-3-4.example.net [192.0.2.200]) 1298 by mail-router.example.com (8.11.6/8.11.6) 1299 with ESMTP id g1G0r1kA003489; 1300 Fri, Feb 15 2002 17:19:07 -0800 1301 From: sender@example.net 1302 Date: Fri, Feb 15 2002 16:54:30 -0800 1303 To: receiver@example.com 1304 Message-Id: <12345.abc@example.net> 1305 Subject: here's a sample 1307 Hello! Goodbye! 1309 Example 3: Header reporting results 1310 The "Authentication-Results" header field is present, indicating that 1311 the border MTA (which is identified in the value of the header field) 1312 conforms to this specification. Furthermore, the message was 1313 authenticated by that MTA via the method specified in [SPF]. The MUA 1314 could extract and relay this extra information if desired. 1316 C.4. Service provided, several authentications done, single MTA 1318 A message that was relayed inbound via a single MTA that conforms to 1319 this specification and applied three different message authentication 1320 checks: 1322 Authentication-Results: mail-router.example.com; 1323 auth=pass (cram-md5) smtp.auth=sender@example.com; 1324 spf=pass smtp.mailfrom=sender@example.com 1325 Authentication-Results: mail-router.example.com; 1326 sender-id=pass header.from=sender@example.com 1327 Received: from mail-router.example.com 1328 (mail-router.example.com [192.0.2.1]) 1329 by dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1330 with ESMTP id g1G0r1kA003489; 1331 Fri, Feb 15 2002 17:19:07 -0800 1332 Date: Fri, Feb 15 2002 16:54:30 -0800 1333 To: receiver@example.net 1334 From: sender@example.com 1335 Message-Id: <12345.abc@example.com> 1336 Subject: here's a sample 1338 Hello! Goodbye! 1340 Example 4: Headers reporting results from one MTA 1342 The "Authentication-Results" header field is present, indicating the 1343 delivering MTA (which is identified in the value of the header field) 1344 conforms to this specification. Furthermore, the sender 1345 authenticated herself/himself to the MTA via a method specified in 1346 [AUTH], and both [SPF] and [SENDERID] checks were done and passed. 1347 The MUA could extract and relay this extra information if desired. 1349 Two "Authentication-Results" header fields are not required since the 1350 same host did all of the checking. The authenticating agent could 1351 have consolidated all the results into one header field. 1353 This example illustrates a scenario in which a remote user on a 1354 dialup connection (example.net) sends mail to a border MTA 1355 (example.com) using SMTP authentication to prove identity. The 1356 dialup provider has been explicitly authorized to relay mail as 1357 "example.com" resulting in passes by the SPF and SenderID checks. 1359 C.5. Service provided, several authentications done, different MTAs 1361 A message that was relayed inbound by two different MTAs that conform 1362 to this specification and applied multiple message authentication 1363 checks: 1365 Authentication-Results: auth-checker.example.com; 1366 sender-id=hardfail header.from=sender@example.com; 1367 dkim=pass (good signature) header.i=sender@example.com 1368 Received: from mail-router.example.com 1369 (mail-router.example.com [192.0.2.1]) 1370 by auth-checker.example.com (8.11.6/8.11.6) 1371 with ESMTP id i7PK0sH7021929; 1372 Fri, Feb 15 2002 17:19:22 -0800 1373 Authentication-Results: mail-router.example.com; 1374 auth=pass (cram-md5) smtp.auth=sender@example.com; 1375 spf=hardfail smtp.mailfrom=sender@example.com 1376 Received: from dialup-1-2-3-4.example.net 1377 (dialup-1-2-3-4.example.net [192.0.2.200]) 1378 by mail-router.example.com (8.11.6/8.11.6) 1379 with ESMTP id g1G0r1kA003489; 1380 Fri, Feb 15 2002 17:19:07 -0800 1381 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1382 t=1188964191; c=simple/simple; 1383 h=From:Date:To:Message-Id:Subject; 1384 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1385 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1386 From: sender@example.com 1387 Date: Fri, Feb 15 2002 16:54:30 -0800 1388 To: receiver@sendmail.com 1389 Message-Id: <12345.abc@example.com> 1390 Subject: here's a sample 1392 Hello! Goodbye! 1394 Example 5: Headers reporting results from multiple MTAs 1396 The "Authentication-Results" header field is present, indicating 1397 conformance to this specification. It is present twice because two 1398 different MTAs in the chain of delivery did authentication tests. 1399 The first, "mail-router.example.com" reports that [AUTH] and [SPF] 1400 were both used, and [AUTH] passed but [SPF] failed. In the [AUTH] 1401 case, additional data is provided in the comment field, which the MUA 1402 can choose to render if desired. 1404 The second MTA, identifying itself as "auth-checker.example.com", 1405 reports that it did a [SENDERID] test (which failed) and a [DKIM] 1406 test (which passed). Again, additional data about one of the tests 1407 is provided as a comment, which the MUA may choose to render. 1409 Since different hosts did the two sets of authentication checks, the 1410 header fields cannot be consolidated in this example. 1412 This example illustrates more typical transmission of mail into 1413 "example.com" from a user on a dialup connection "example.net". The 1414 user appears to be legitimate as he/she had a valid password allowing 1415 authentication at the border MTA using [AUTH]. The [SPF] and 1416 [SENDERID] tests failed since "example.com" has not granted 1417 "example.net" authority to relay mail on its behalf. However, the 1418 [DKIM] test passed because the sending user had a private key 1419 matching one of "example.com"'s published public keys and used it to 1420 sign the message. 1422 C.6. Service provided, multi-tiered authentication done 1424 A message that had authentication done at various stages, one of 1425 which was outside the receiving domain: 1427 Authentication-Results: chicago.example.com; 1428 dkim=pass (good signature) header.i=@mail-router.example.net; 1429 dkim=fail (bad signature) header.i=@newyork.example.com 1430 Received: from mail-router.example.net 1431 (mail-router.example.net [192.0.2.250]) 1432 by chicago.example.com (8.11.6/8.11.6) 1433 for 1434 with ESMTP id i7PK0sH7021929; 1435 Fri, Feb 15 2002 17:19:22 -0800 1436 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1437 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1438 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1439 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1440 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1441 Authentication-Results: mail-router.example.net; 1442 dkim=pass (good signature) header.i=@newyork.example.com 1443 Received: from smtp.newyork.example.com 1444 (smtp.newyork.example.com [192.0.2.220]) 1445 by mail-router.example.net (8.11.6/8.11.6) 1446 with ESMTP id g1G0r1kA003489; 1447 Fri, Feb 15 2002 17:19:07 -0800 1448 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; 1449 t=1188964191; c=simple/simple; 1450 h=From:Date:To:Message-Id:Subject; 1451 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1452 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1453 From: sender@newyork.example.com 1454 Date: Fri, Feb 15 2002 16:54:30 -0800 1455 To: meetings@example.net 1456 Message-Id: <12345.abc@newyork.example.com> 1457 Subject: here's a sample 1459 Example 6: Headers reporting results from multiple MTAs in different 1460 domains 1462 In this example we see multi-tiered authentication with an extended 1463 trust boundary. 1465 The message was sent from someone at example.com's New York office 1466 (newyork.example.com) to a mailing list managed at an intermediary. 1467 The message was signed at the origin using [DKIM]. 1469 The message was sent to a mailing list service provider called 1470 example.net which is used by example.com. There meetings@example.net 1471 is expanded to a long list of recipients, one of which is at the 1472 Chicago office. In this example, we will assume that the trust 1473 boundary for chicago.example.com includes the mailing list server at 1474 example.net. 1476 The mailing list server there first authenticated the message and 1477 affixed an Authentication-Results: header field indicating such. It 1478 then altered the message by affixing some footer text to the body 1479 including some administrivia such as unsubscription instructions. 1480 Finally, the mailing list server affixes a second [DKIM] signature 1481 and begins distribution of the message. 1483 The border MTA for chicago.example.com explicitly trusts results from 1484 mail-router.example.net so that header is not removed. It performs 1485 evaluation of both signatures and determines that the first (most 1486 recent) is a "pass" but, because of the aforementioned modifications, 1487 the second is a "hardfail". However, the first signature included 1488 the Authentication-Results: header added at mail-router.example.net 1489 which validated the second signature. Thus, indirectly, it can be 1490 determined that the authentication claimed by both signatures are 1491 indeed valid. 1493 Appendix D. Public Discussion 1495 [REMOVE BEFORE PUBLICATION] 1497 Public discussion of this proposed specification is handled via the 1498 mail-vet-discuss@mipassoc.org mailing list. The list is open. 1499 Access to subscription forms and to list archives can be found at 1500 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 1502 Author's Address 1504 Murray S. Kucherawy 1505 Sendmail, Inc. 1506 6475 Christie Ave., Suite 350 1507 Emeryville, CA 94608 1508 US 1510 Phone: +1 510 594 5400 1511 Email: msk+ietf@sendmail.com 1513 Full Copyright Statement 1515 Copyright (C) The IETF Trust (2008). 1517 This document is subject to the rights, licenses and restrictions 1518 contained in BCP 78, and except as set forth therein, the authors 1519 retain all their rights. 1521 This document and the information contained herein are provided on an 1522 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1523 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1524 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1525 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1526 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1527 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1529 Intellectual Property 1531 The IETF takes no position regarding the validity or scope of any 1532 Intellectual Property Rights or other rights that might be claimed to 1533 pertain to the implementation or use of the technology described in 1534 this document or the extent to which any license under such rights 1535 might or might not be available; nor does it represent that it has 1536 made any independent effort to identify any such rights. Information 1537 on the procedures with respect to rights in RFC documents can be 1538 found in BCP 78 and BCP 79. 1540 Copies of IPR disclosures made to the IETF Secretariat and any 1541 assurances of licenses to be made available, or the result of an 1542 attempt made to obtain a general license or permission for the use of 1543 such proprietary rights by implementers or users of this 1544 specification can be obtained from the IETF on-line IPR repository at 1545 http://www.ietf.org/ipr. 1547 The IETF invites any interested party to bring to its attention any 1548 copyrights, patents or patent applications, or other proprietary 1549 rights that may cover technology that may be required to implement 1550 this standard. Please address the information to the IETF at 1551 ietf-ipr@ietf.org. 1553 Acknowledgment 1555 Funding for the RFC Editor function is provided by the IETF 1556 Administrative Support Activity (IASA).