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