idnits 2.17.1 draft-ietf-appsawg-rfc7001bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC7001, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2015) is 3250 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 510, but not defined == Missing Reference: 'RFC7208' is mentioned on line 815, but not defined -- 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 7410 (ref. 'PTYPES-REGISTRY') (Obsoleted by RFC 7601) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 6577 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 7001 (Obsoleted by RFC 7601) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft May 5, 2015 4 Obsoletes: 7001, 7410 5 (if approved) 6 Intended status: Standards Track 7 Expires: November 6, 2015 9 Message Header Field for Indicating Message Authentication Status 10 draft-ietf-appsawg-rfc7001bis-08 12 Abstract 14 This document specifies a message header field called Authentication- 15 Results for use with electronic mail messages to indicate the results 16 of message authentication efforts. Any receiver-side software, such 17 as mail filters or Mail User Agents (MUAs), can use this header field 18 to relay that information in a convenient and meaningful way to users 19 or to make sorting and filtering decisions. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 6, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 6 58 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 60 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 61 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 62 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 63 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 8 64 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 9 65 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 9 66 2. Definition and Format of the Header Field . . . . . . . . . . 9 67 2.1. General Description . . . . . . . . . . . . . . . . . . . 9 68 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10 69 2.3. Property Types (ptypes) and Properties . . . . . . . . . . 12 70 2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . . 13 71 2.5. Authentication Identifier Field . . . . . . . . . . . . . 14 72 2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 15 73 2.7. Defined Methods and Result Values . . . . . . . . . . . . 16 74 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 75 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 76 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19 77 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 78 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 21 79 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21 80 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 22 81 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22 82 4. Adding the Header Field to a Message . . . . . . . . . . . . . 23 83 4.1. Header Field Position and Interpretation . . . . . . . . . 25 84 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26 85 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 87 6.1. The Authentication-Results Header Field . . . . . . . . . 27 88 6.2. "Email Authentication Methods" Registry Description . . . 28 89 6.3. "Email Authentication Methods" Registry Update . . . . . . 29 90 6.4. "Email Authentication Property Types" Registry . . . . . . 30 91 6.5. "Email Authentication Result Names" Description . . . . . 31 92 6.6. "Email Authentication Result Names" Update . . . . . . . . 32 93 6.7. SMTP Enhanced Stauts Codes . . . . . . . . . . . . . . . . 33 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 95 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 33 96 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35 97 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35 98 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35 99 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35 100 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35 101 7.7. Attacks against Authentication Methods . . . . . . . . . . 36 102 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36 103 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36 104 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 36 105 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 37 109 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 110 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 40 111 Appendix C. Authentication-Results Examples . . . . . . . . . . . 40 112 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 41 113 C.2. Nearly Trivial Case; Service Provided, but No 114 Authentication Done . . . . . . . . . . . . . . . . . . . 41 115 C.3. Service Provided, Authentication Done . . . . . . . . . . 42 116 C.4. Service Provided, Several Authentications Done, Single 117 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 118 C.5. Service Provided, Several Authentications Done, 119 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44 120 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46 121 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47 122 Appendix D. Operational Considerations about Message 123 Authentication . . . . . . . . . . . . . . . . . . . 48 124 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49 125 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49 126 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50 127 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50 128 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50 129 E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50 130 E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51 131 E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51 132 E.8. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 51 133 E.9. -07 to -08 . . . . . . . . . . . . . . . . . . . . . . . . 52 135 1. Introduction 137 This document describes a header field called Authentication-Results 138 for electronic mail messages that presents the results of a message 139 authentication effort in a machine-readable format. The intent of 140 the header field is to create a place to collect such data when 141 message authentication mechanisms are in use so that a Mail User 142 Agent (MUA) and downstream filters can make filtering decisions 143 and/or provide a recommendation to the user as to the validity of the 144 message's origin and possibly the safety and integrity of its 145 content. 147 This document revises the original definition found in [RFC5451] 148 based upon various authentication protocols in current use and 149 incorporates errata logged since the publication of the original 150 specification. 152 End users are not expected to be direct consumers of this header 153 field. This header field is intended for consumption by programs 154 that will then use such data or render it in a human-usable form. 156 This document specifies the format of this header field and discusses 157 the implications of its presence or absence. However, it does not 158 discuss how the data contained in the header field ought to be used, 159 such as what filtering decisions are appropriate or how an MUA might 160 render those results, as these are local policy and/or user interface 161 design questions that are not appropriate for this document. 163 At the time of publication of this document, the following are 164 published email authentication methods: 166 o Author Domain Signing Practices ([ADSP]) (Historic) 168 o SMTP Service Extension for Authentication ([AUTH]) 170 o DomainKeys Identified Mail Signatures ([DKIM]) 172 o Domain-based Message Authentication, Reporting and Conformance 173 ([DMARC]) 175 o Sender Policy Framework ([SPF]) 177 o reverse IP address name validation ("iprev", defined in Section 3) 179 o Require-Recipient-Valid-Since Header Field and SMTP Service 180 Extension ([RRVS]) 182 o S/MIME Signature Verification ([SMIME-REG]) 184 o Vouch By Reference ([VBR]) 186 o DomainKeys ([DOMAINKEYS]) (Historic) 188 o Sender ID ([SENDERID]) (Experimental) 190 There exist registries for tokens used within this header field that 191 refer to the specifications listed above. Section 6 describes the 192 registries and their contents, and specifies the process by which 193 entries are added or updated. It also updates the existing contents 194 to match the current states of these specifications. 196 This specification is not intended to be restricted to domain-based 197 authentication schemes, but the existing schemes in that family have 198 proven to be a good starting point for implementations. The goal is 199 to give current and future authentication schemes a common framework 200 within which to deliver their results to downstream agents and 201 discourage the creation of unique header fields for each. 203 Although SPF defined a header field called "Received-SPF" and the 204 historic DomainKeys defined one called "DomainKey-Status" for this 205 purpose, those header fields are specific to the conveyance of their 206 respective results only and thus are insufficient to satisfy the 207 requirements enumerated below. In addition, many SPF implementations 208 have adopted the header field specified here at least as an option, 209 and DomainKeys has been obsoleted by DKIM. 211 1.1. Purpose 213 The header field defined in this document is expected to serve 214 several purposes: 216 1. Convey the results of various message authentication checks, 217 which are applied by upstream filters and Mail Transfer Agents 218 (MTAs) and then passed to MUAs and downstream filters within the 219 same "trust domain". Such agents might wish to render those 220 results to end users or to use those data to apply more or less 221 stringent content checks based on authentication results; 223 2. Provide a common location within a message for this data; 225 3. Create an extensible framework for reporting new authentication 226 methods as they emerge. 228 In particular, the mere presence of this header field does not mean 229 its contents are valid. Rather, the header field is reporting 230 assertions made by one or more authentication schemes (supposedly) 231 applied somewhere upstream. For an MUA or downstream filter to treat 232 the assertions as actually valid, there must be an assessment of the 233 trust relationship among such agents, the validating MTA, and the 234 mechanism for conveying the information. 236 1.2. Trust Boundary 238 This document makes several references to the "trust boundary" of an 239 administrative management domain (ADMD). Given the diversity among 240 existing mail environments, a precise definition of this term isn't 241 possible. 243 Simply put, a transfer from the producer of the header field to the 244 consumer must occur within a context that permits the consumer to 245 treat assertions by the producer as being reliable and accurate 246 (trustworthy). How this trust is obtained is outside the scope of 247 this document. It is entirely a local matter. 249 Thus, this document defines a "trust boundary" as the delineation 250 between "external" and "internal" entities. Services that are 251 internal -- within the trust boundary -- are provided by the ADMD's 252 infrastructure for its users. Those that are external are outside of 253 the authority of the ADMD. By this definition, hosts that are within 254 a trust boundary are subject to the ADMD's authority and policies, 255 independent of their physical placement or their physical operation. 256 For example, a host within a trust boundary might actually be 257 operated by a remote service provider and reside physically within 258 its data center. 260 It is possible for a message to be evaluated inside a trust boundary 261 but then depart and re-enter the trust boundary. An example might be 262 a forwarded message such as a message/rfc822 attachment (see 263 Multipurpose Internet Mail Extensions [MIME]) or one that is part of 264 a multipart/digest. The details reported by this field cannot be 265 trusted in that case. Thus, this field found within one of those 266 media types is typically ignored. 268 1.3. Processing Scope 270 The content of this header field is meant to convey to message 271 consumers that authentication work on the message was already done 272 within its trust boundary, and those results are being presented. It 273 is not intended to provide message parameters to consumers so that 274 they can perform authentication protocols on their own. 276 1.4. Requirements 278 This document establishes no new requirements on existing protocols 279 or servers. 281 In particular, this document establishes no requirement on MTAs to 282 reject or filter arriving messages that do not pass authentication 283 checks. The data conveyed by the specified header field's contents 284 are for the information of MUAs and filters and are to be used at 285 their discretion. 287 1.5. Definitions 289 This section defines various terms used throughout this document. 291 1.5.1. Key Words 293 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 294 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 295 document are to be interpreted as described in [KEYWORDS]. 297 1.5.2. Security 299 "Guidelines for Writing RFC Text on Security Considerations" 300 ([SECURITY]) discusses authentication and authorization and the 301 conflation of the two concepts. The use of those terms within the 302 context of recent message security work has given rise to slightly 303 different definitions, and this document reflects those current 304 usages, as follows: 306 o "Authorization" is the establishment of permission to use a 307 resource or represent an identity. In this context, authorization 308 indicates that a message from a particular ADMD arrived via a 309 route the ADMD has explicitly approved. 311 o "Authentication" is the assertion of validity of a piece of data 312 about a message (such as the sender's identity) or the message in 313 its entirety. 315 As examples: SPF and Sender ID are authorization mechanisms in that 316 they express a result that shows whether or not the ADMD that 317 apparently sent the message has explicitly authorized the connecting 318 Simple Mail Transfer Protocol ([SMTP]) client to relay messages on 319 its behalf, but they do not actually validate any other property of 320 the message itself. By contrast, DKIM is agnostic as to the routing 321 of a message but uses cryptographic signatures to authenticate 322 agents, assign (some) responsibility for the message (which implies 323 authorization), and ensure that the listed portions of the message 324 were not modified in transit. Since the signatures are not tied to 325 SMTP connections, they can be added by either the ADMD of origin, 326 intermediate ADMDs (such as a mailing list server), other handling 327 agents, or any combination. 329 Rather than create a separate header field for each class of 330 solution, this proposal groups them both into a single header field. 332 1.5.3. Email Architecture 334 o A "border MTA" is an MTA that acts as a gateway between the 335 general Internet and the users within an organizational boundary. 336 (See also Section 1.2.) 338 o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that 339 actually enacts delivery of a message to a user's inbox or other 340 final delivery. 342 o An "intermediate MTA" is any MTA that is not a delivery MTA and is 343 also not the first MTA to handle the message. 345 The following diagram illustrates the flow of mail among these 346 defined components. See Internet Mail Architecture [EMAIL-ARCH] for 347 further discussion on general email system architecture, which 348 includes detailed descriptions of these components, and Appendix D of 349 this document for discussion about the common aspects of email 350 authentication in current environments. 352 +-----+ +-----+ +------------+ 353 | MUA |-->| MSA |-->| Border MTA | 354 +-----+ +-----+ +------------+ 355 | 356 | 357 V 358 +----------+ 359 | Internet | 360 +----------+ 361 | 362 | 363 V 364 +-----+ +-----+ +------------------+ +------------+ 365 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 366 +-----+ +-----+ +------------------+ +------------+ 368 Generally, it is assumed that the work of applying message 369 authentication schemes takes place at a border MTA or a delivery MTA. 370 This specification is written with that assumption in mind. However, 371 there are some sites at which the entire mail infrastructure consists 372 of a single host. In such cases, such terms as "border MTA" and 373 "delivery MTA" might well apply to the same machine or even the very 374 same agent. It is also possible that some message authentication 375 tests could take place on an intermediate MTA. Although this 376 document doesn't specifically describe such cases, they are not meant 377 to be excluded. 379 1.5.4. Other Terms 381 In this document, the term "producer" refers to any component that 382 adds this header field to messages it is handling, and "consumer" 383 refers to any component that identifies, extracts, and parses the 384 header field to use as part of a handling decision. 386 1.6. Trust Environment 388 This header field permits one or more message validation mechanisms 389 to communicate output to one or more separate assessment mechanisms. 390 These mechanisms operate within a unified trust boundary that defines 391 an Administrative Management Domain (ADMD). An ADMD contains one or 392 more entities that perform validation and generate the header field 393 and one or more that consume it for some type of assessment. The 394 field often contains no integrity or validation mechanism of its own, 395 so its presence must be trusted implicitly. Hence, valid use of the 396 header field requires removing any occurrences of it that are present 397 when the message enters the ADMD. This ensures that later 398 occurrences have been added within the trust boundary of the ADMD. 400 The authserv-id token defined in Section 2.2 can be used to reference 401 an entire ADMD or a specific validation engine within an ADMD. 402 Although the labeling scheme is left as an operational choice, some 403 guidance for selecting a token is provided in later sections of this 404 document. 406 2. Definition and Format of the Header Field 408 This section gives a general overview of the format of the header 409 field being defined and then provides more formal specification. 411 2.1. General Description 413 The header field specified here is called Authentication-Results. It 414 is a Structured Header Field as defined in Internet Message Format 415 ([MAIL]), and thus all of the related definitions in that document 416 apply. 418 This header field is added at the top of the message as it transits 419 MTAs that do authentication checks, so some idea of how far away the 420 checks were done can be inferred. It is therefore considered to be a 421 trace field as defined in [MAIL], and thus all of the related 422 definitions in that document apply. 424 The value of the header field (after removing comments) consists of 425 an authentication identifier, an optional version, and then a series 426 of statements and supporting data. The statements are of the form 427 "method=result" and indicate which authentication method(s) were 428 applied and their respective results. For each such statement, the 429 supporting data can include a "reason" string and one or more 430 "property=value" statements indicating which message properties were 431 evaluated to reach that conclusion. 433 The header field can appear more than once in a single message, more 434 than one result can be represented in a single header field, or a 435 combination of these can be applied. 437 2.2. Formal Definition 439 Formally, the header field is specified as follows using Augmented 440 Backus-Naur Form ([ABNF]): 442 authres-header = "Authentication-Results:" [CFWS] authserv-id 443 [ CFWS authres-version ] 444 ( no-result / 1*resinfo ) [CFWS] CRLF 446 authserv-id = value 447 ; see below for a description of this element 449 authres-version = 1*DIGIT [CFWS] 450 ; indicates which version of this specification is in use; 451 ; this specification is version "1", and the absence of a 452 ; version implies this version of the specification 454 no-result = [CFWS] ";" [CFWS] "none" 455 ; the special case of "none" is used to indicate that no 456 ; message authentication was performed 458 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 459 *( CFWS propspec ) 461 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 462 ; indicates which authentication method was evaluated 463 ; and what its output was 465 reasonspec = "reason" [CFWS] "=" [CFWS] value 466 ; a free-form comment on the reason the given result 467 ; was returned 469 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 470 ; an indication of which properties of the message 471 ; were evaluated by the authentication scheme being 472 ; applied to yield the reported result 474 method = Keyword [ [CFWS] "/" [CFWS] method-version ] 475 ; a method indicates which method's result is 476 ; represented by "result", and is one of the methods 477 ; explicitly defined as valid in this document 478 ; or is an extension method as defined below 480 method-version = 1*DIGIT [CFWS] 481 ; indicates which version of the method specification is 482 ; in use, corresponding to the matching entry in the IANA 483 ; "Email Authentication Methods" registry; a value of "1" 484 ; is assumed if this version string is absent 486 result = Keyword 487 ; indicates the results of the attempt to authenticate 488 ; the message; see below for details 490 ptype = Keyword 491 ; indicates whether the property being evaluated was 492 ; a parameter to an [SMTP] command, was a value taken 493 ; from a message header field, was some property of 494 ; the message body, or was some other property evaluated by 495 ; the receiving MTA; expected to be one of the "property 496 ; types" explicitly defined as valid, or an extension 497 ; ptype, as defined below 499 property = special-smtp-verb / Keyword 500 ; indicates more specifically than "ptype" what the 501 ; source of the evaluated property is; the exact meaning 502 ; is specific to the method whose result is being reported 503 ; and is defined more clearly below 505 special-smtp-verb = "mailfrom" / "rcptto" 506 ; special cases of [SMTP] commands that are made up 507 ; of multiple words 509 pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) 510 [CFWS] 511 ; the value extracted from the message property defined 512 ; by the "ptype.property" construction 514 "local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is 515 defined in Section 3.2.2 of [MAIL]. 517 "Keyword" is defined in Section 4.1.2 of [SMTP]. 519 The "value" is as defined in Section 5.1 of [MIME]. 521 The "domain-name" is as defined in Section 3.5 of [DKIM]. 523 The "Keyword" used in "result" above is further constrained by the 524 necessity of being enumerated in Section 2.7. 526 See Section 2.5 for a description of the authserv-id element. 528 If the value portion of a "pvalue" construction identifies something 529 intended to be an e-mail identity, then it MUST use the right hand 530 portion of that ABNF definition. 532 The list of commands eligible for use with the "smtp" ptype can be 533 found in Section 4.1 of [SMTP]. 535 The "propspec" may be omitted if, for example, the method was unable 536 to extract any properties to do its evaluation yet has a result to 537 report. 539 Where an SMTP command name is being reported as a "property", the 540 agent generating the header field represents that command by 541 converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" 542 becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). 544 A "ptype" value of "policy" indicates a policy decision about the 545 message not specific to a property of the message that could be 546 extracted. See Section 2.4 for details. 548 Examples of complete messages using this header field can be found in 549 Appendix C. 551 2.3. Property Types (ptypes) and Properties 553 The "ptype" in the ABNF above indicates the general type of property 554 being described by the result being reported, upon which the reported 555 result was based. Coupled with the "property", which is more 556 specific, they indicate from which particular part of the message the 557 reported data were extracted. 559 Combinations of ptypes and properties are registered and described in 560 the "Email Authentication Methods" registry, coupled with the 561 authentication methods with which they are used. This is further 562 described in Section 6. 564 Legal values of "ptype" are as defined in the IANA "Email 565 Authentication Property Types" registry, created by 566 [PTYPES-REGISTRY]. The initial values and what they typically 567 indicate are as follows, copied from [RFC7001]: 569 body: Information that was extracted from the body of the message. 570 This might be an arbitrary string of bytes, a hash of a string of 571 bytes, a Uniform Resource Identifier, or some other content of 572 interest. The "property" is an indication of where within the 573 message body the extracted content was found, and can indicate an 574 offset, identify a MIME part, etc. 576 header: Indicates information that was extracted from the header of 577 the message. This might be the value of a header field or some 578 portion of a header field. The "property" gives a more precise 579 indication of the place in the header from which the extraction 580 took place. 582 policy: A local policy mechanism was applied that augments or 583 overrides the result returned by the authentication mechanism. 584 (See Section 2.4.) 586 smtp: Indicates information that was extracted from an SMTP command 587 that was used to relay the message. The "property" indicates 588 which SMTP command included the extracted content as a parameter. 590 Results reported using unknown ptypes MUST NOT be used in making 591 handling decisions. They can be safely ignored by consumers. 593 Entries in the "Email Authentication Methods" registry can define 594 properties that deviate from these definitions when appropriate. 595 Such deviations need to be clear in the registry and/or in the 596 defining document. See Section 2.7.1 for an example. 598 2.4. The "policy" ptype 600 A special ptype value of "policy" is also defined. This ptype is 601 provided to indicate that some local policy mechanism was applied 602 that augments or even replaces (i.e., overrides) the result returned 603 by the authentication mechanism. The property and value in this case 604 identify the local policy that was applied and the result it 605 returned. 607 For example, a DKIM signature is not required to include the Subject 608 header field in the set of fields that are signed. An ADMD receiving 609 such a message might decide that such a signature is unacceptable, 610 even if it passes, because the content of the Subject header field 611 could be altered post-signing without invalidating the signature. 612 Such an ADMD could replace the DKIM "pass" result with a "policy" 613 result and then also include the following in the corresponding 614 Authentication-Result field: 616 ... dkim=fail policy.dkim-rules=unsigned-subject ... 618 In this case, the property is "dkim-rules", indicating some local 619 check by that name took place and that check returned a result of 620 "unsigned-subject". These are arbitrary names selected by (and 621 presumably used within) the ADMD making use of them, so they are not 622 normally registered with IANA or otherwise specified apart from 623 setting syntax restrictions that allow for easy parsing within the 624 rest of the header field. 626 This ptype existed in the original specification for this header 627 field, but without a complete description or example of intended use. 628 As a result, it has not seen any practical use to date that matches 629 its intended purpose. These added details are provided to guide 630 implementers toward proper use. 632 2.5. Authentication Identifier Field 634 Every Authentication-Results header field has an authentication 635 service identifier field (authserv-id above). Specifically, this is 636 any string intended to identify the authentication service within the 637 ADMD that conducted authentication checks on the message. This 638 identifier is intended to be machine-readable and not necessarily 639 meaningful to users. 641 Since agents consuming this field will use this identifier to 642 determine whether its contents are of interest (and are safe to use), 643 the uniqueness of the identifier MUST be guaranteed by the ADMD that 644 generates it and MUST pertain to that ADMD. MUAs or downstream 645 filters SHOULD use this identifier to determine whether or not the 646 data contained in an Authentication-Results header field ought to be 647 used or ignored. 649 For simplicity and scalability, the authentication service identifier 650 SHOULD be a common token used throughout the ADMD. Common practice 651 is to use the DNS domain name used by or within that ADMD, sometimes 652 called the "organizational domain", but this is not strictly 653 necessary. 655 For tracing and debugging purposes, the authentication identifier can 656 instead be the specific hostname of the MTA performing the 657 authentication check whose result is being reported. Moreover, some 658 implementations define a substructure to the identifier; these are 659 outside of the scope of this specification. 661 Note, however, that using a local, relative identifier like a flat 662 hostname, rather than a hierarchical and globally unique ADMD 663 identifier like a DNS domain name, makes configuration more difficult 664 for large sites. The hierarchical identifier permits aggregating 665 related, trusted systems together under a single, parent identifier, 666 which in turn permits assessing the trust relationship with a single 667 reference. The alternative is a flat namespace requiring 668 individually listing each trusted system. Since consumers will use 669 the identifier to determine whether to use the contents of the header 670 field: 672 o Changes to the identifier impose a large, centralized 673 administrative burden. 675 o Ongoing administrative changes require constantly updating this 676 centralized table, making it difficult to ensure that an MUA or 677 downstream filter will have access to accurate information for 678 assessing the usability of the header field's content. In 679 particular, consumers of the header field will need to know not 680 only the current identifier(s) in use but previous ones as well to 681 account for delivery latency or later re-assessment of the header 682 field's contents. 684 Examples of valid authentication identifiers are "example.com", 685 "mail.example.org", "ms1.newyork.example.com", and "example-auth". 687 2.6. Version Tokens 689 The grammar above provides for the optional inclusion of versions on 690 both the header field itself (attached to the authserv-id token) and 691 on each of the methods being reported. The method version refers to 692 the method itself, which is specified in the documents describing 693 those methods, while the authserv-id version refers to this document 694 and thus the syntax of this header field. 696 The purpose of including these is to avoid misinterpretation of the 697 results. That is, if a parser finds a version after an authserv-id 698 that it does not explicitly know, it can immediately discontinue 699 trying to parse since what follows might not be in an expected 700 format. For a method version, the parser SHOULD ignore a method 701 result if the version is not supported in case the semantics of the 702 result have a different meaning than what is expected. For example, 703 if a hypothetical DKIM version 2 yielded a "pass" result for 704 different reasons than version 1 does, a consumer of this field might 705 not want to use the altered semantics. Allowing versions in the 706 syntax is a way to indicate this and let the consumer of the header 707 field decide. 709 2.7. Defined Methods and Result Values 711 Each individual authentication method returns one of a set of 712 specific result values. The subsections below provide references to 713 the documents defining the authentication methods specifically 714 supported by this document, and their corresponding result values. 715 Verifiers SHOULD use these values as described below. New methods 716 not specified in this document, but intended to be supported by the 717 header field defined here, MUST include a similar result table either 718 in their defining documents or in supplementary ones. 720 2.7.1. DKIM and DomainKeys 722 DKIM is represented by the "dkim" method and is defined in [DKIM]. 723 DomainKeys is defined in [DOMAINKEYS] and is represented by the 724 "domainkeys" method. 726 Section 3.8 of [DOMAINKEYS] enumerates some possible results of a 727 DomainKeys evaluation. Those results are not used when generating 728 this header field; rather, the results returned are listed below. 730 A signature is "acceptable to the ADMD" if it passes local policy 731 checks (or there are no specific local policy checks). For example, 732 an ADMD policy might require that the signature(s) on the message be 733 added using the DNS domain present in the From header field of the 734 message, thus making third-party signatures unacceptable even if they 735 verify. 737 Both DKIM and DomainKeys use the same result set, as follows: 739 none: The message was not signed. 741 pass: The message was signed, the signature or signatures were 742 acceptable to the ADMD, and the signature(s) passed verification 743 tests. 745 fail: The message was signed and the signature or signatures were 746 acceptable to the ADMD, but they failed the verification test(s). 748 policy: The message was signed, but some aspect of the signature or 749 signatures was not acceptable to the ADMD. 751 neutral: The message was signed, but the signature or signatures 752 contained syntax errors or were not otherwise able to be 753 processed. This result is also used for other failures not 754 covered elsewhere in this list. 756 temperror: The message could not be verified due to some error that 757 is likely transient in nature, such as a temporary inability to 758 retrieve a public key. A later attempt may produce a final 759 result. 761 permerror: The message could not be verified due to some error that 762 is unrecoverable, such as a required header field being absent. A 763 later attempt is unlikely to produce a final result. 765 DKIM results are reported using a ptype of "header". The property, 766 however, represents one of the tags found in the DKIM-Signature 767 header field rather than a distinct header field. For example, the 768 ptype-property combination "header.d" refers to the content of the 769 "d" (signing domain) tag from within the signature header field, and 770 not a distinct header field called "d". 772 The ability to report different DKIM results for a multiply-signed 773 message is described in [RFC6008]. 775 [DKIM] advises that if a message fails verification, it is to be 776 treated as an unsigned message. A report of "fail" here permits the 777 receiver of the report to decide how to handle the failure. A report 778 of "neutral" or "none" preempts that choice, ensuring the message 779 will be treated as if it had not been signed. 781 Section 3.1 of [DOMAINKEYS] describes a process by which the sending 782 address of the message is determined. DomainKeys results are thus 783 reported along with the signing domain name, the sending address of 784 the message, and the name of the header field from which the latter 785 was extracted. This means that a DomainKeys result includes a ptype- 786 property combination of "header.d", plus one of "header.from" and 787 "header.sender". The sending address extracted from the header is 788 included with any [MAIL]-style comments removed; moreover, the local- 789 part of the address and the "@" character are removed if it has not 790 been authenticated in some way. 792 2.7.2. SPF and Sender ID 794 SPF and Sender ID use the "spf" and "sender-id" method names, 795 respectively. The result values for SPF are defined in Section 2.6 796 of [SPF], and those definitions are included here by reference: 798 +-----------+--------------------------------+ 799 | Code | Meaning | 800 +-----------+--------------------------------+ 801 | none | [RFC7208], Section 2.6.1 | 802 +-----------+--------------------------------+ 803 | pass | [RFC7208], Section 2.6.3 | 804 +-----------+--------------------------------+ 805 | fail | [RFC7208], Section 2.6.4 | 806 +-----------+--------------------------------+ 807 | softfail | [RFC7208], Section 2.6.5 | 808 +-----------+--------------------------------+ 809 | policy | [this RFC], Section 2.4 | 810 +-----------+--------------------------------+ 811 | neutral | [RFC7208], Section 2.6.2 | 812 +-----------+--------------------------------+ 813 | temperror | [RFC7208], Section 2.6.6 | 814 +-----------+--------------------------------+ 815 | permerror | [RFC7208], Section 2.6.7 | 816 +-----------+--------------------------------+ 818 These result codes are used in the context of this specification to 819 reflect the result returned by the component conducting SPF 820 evaluation. 822 For SPF, the ptype used is "smtp", and the property is either 823 "mailfrom" or "helo", since those values are the ones SPF can 824 evaluate. (If the SMTP client issued the EHLO command instead of 825 HELO, the property used is "helo".) 827 The "sender-id" method is described in [SENDERID]. For this method, 828 the ptype used is "header" and the property will be the name of the 829 header field from which the Purported Responsible address (see [PRA]) 830 was extracted, namely one of "Resent-Sender", "Resent-From", 831 "Sender", or "From". 833 The results for Sender ID are listed and described in Section 4.2 of 834 [SENDERID], but for the purposes of this specification, the SPF 835 definitions enumerated above are used instead. Also, [SENDERID] 836 specifies result codes that use mixed case, but they are typically 837 used all lowercase in this context. 839 For both methods, an additional result of "policy" is defined, which 840 means the client was authorized to inject or relay mail on behalf of 841 the sender's DNS domain according to the authentication method's 842 algorithm, but local policy dictates that the result is unacceptable. 843 For example, "policy" might be used if SPF returns a "pass" result, 844 but a local policy check matches the sending DNS domain to one found 845 in an explicit list of unacceptable DNS domains (e.g., spammers). 847 If the retrieved sender policies used to evaluate SPF and Sender ID 848 do not contain explicit provisions for authenticating the local-part 849 (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported 850 along with results for these mechanisms SHOULD NOT include the local- 851 part or the following "@" character. 853 2.7.3. "iprev" 855 The result values used by the "iprev" method, defined in Section 3, 856 are as follows: 858 pass: The DNS evaluation succeeded, i.e., the "reverse" and 859 "forward" lookup results were returned and were in agreement. 861 fail: The DNS evaluation failed. In particular, the "reverse" and 862 "forward" lookups each produced results, but they were not in 863 agreement, or the "forward" query completed but produced no 864 result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an 865 RCODE of 0 (NOERROR) in a reply containing no answers, was 866 returned. 868 temperror: The DNS evaluation could not be completed due to some 869 error that is likely transient in nature, such as a temporary DNS 870 error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or 871 other error condition resulted. A later attempt may produce a 872 final result. 874 permerror: The DNS evaluation could not be completed because no PTR 875 data are published for the connecting IP address, e.g., a DNS 876 RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) 877 in a reply containing no answers, was returned. This prevented 878 completion of the evaluation. A later attempt is unlikely to 879 produce a final result. 881 There is no "none" for this method since any TCP connection 882 delivering email has an IP address associated with it, so some kind 883 of evaluation will always be possible. 885 The result is reported using a ptype of "policy" (as this is not part 886 of any established protocol) and a property of "iprev". 888 For discussion of the format of DNS replies, see "Domain Names - 889 Implementation and Specification" ([DNS]). 891 2.7.4. SMTP AUTH 893 SMTP AUTH (defined in [AUTH]) is represented by the "auth" method. 894 Its result values are as follows: 896 none: SMTP authentication was not attempted. 898 pass: The SMTP client authenticated to the server reporting the 899 result using the protocol described in [AUTH]. 901 fail: The SMTP client attempted to authenticate to the server using 902 the protocol described in [AUTH] but was not successful (such as 903 providing a valid identity but an incorrect password). 905 temperror: The SMTP client attempted to authenticate using the 906 protocol described in [AUTH] but was not able to complete the 907 attempt due to some error that is likely transient in nature, such 908 as a temporary directory service lookup error. A later attempt 909 may produce a final result. 911 permerror: The SMTP client attempted to authenticate using the 912 protocol described in [AUTH] but was not able to complete the 913 attempt due to some error that is likely not transient in nature, 914 such as a permanent directory service lookup error. A later 915 attempt is not likely to produce a final result. 917 The result of AUTH is reported using a ptype of "smtp" and a property 918 of either: 920 o "auth", in which case the value is the authorization identity 921 generated by the exchange initiated by the AUTH command; or 923 o "mailfrom", in which case the value is the mailbox identified by 924 the AUTH parameter used with the MAIL FROM command. 926 If both identities are available, both can be reported. For example, 927 consider this command issued by a client that has completed session 928 authentication with the AUTH command resulting in an authorized 929 identity of "client@c.example": 931 MAIL FROM: AUTH= 933 This could result in a resinfo construction like so: 935 ; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example 937 Note that in all cases other than "pass", the message was sent by an 938 unauthenticated client. All non-"pass" cases SHOULD thus be treated 939 as equivalent with respect to this method. 941 2.7.5. Other Registered Codes 943 Result codes were also registered in other RFCs as follows: 945 o Vouch By Reference (in [AR-VBR], represented by "vbr"); 947 o Authorized Third-Party Signatures (in [ATPS], represented by 948 "dkim-atps"); 950 o Author Domain Signing Practices (in [ADSP], represented by "dkim- 951 adsp"); 953 o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); 955 o S/MIME (in [SMIME-REG], represented by "smime"). 957 2.7.6. Extension Methods 959 Additional authentication method identifiers (extension methods) may 960 be defined in the future by later revisions or extensions to this 961 specification. These method identifiers are registered with the 962 Internet Assigned Numbers Authority (IANA) and, preferably, published 963 in an RFC. See Section 6 for further details. 965 Extension methods can be defined for the following reasons: 967 1. To allow additional information from new authentication systems 968 to be communicated to MUAs or downstream filters. The names of 969 such identifiers ought to reflect the name of the method being 970 defined but ought not be needlessly long. 972 2. To allow the creation of "sub-identifiers" that indicate 973 different levels of authentication and differentiate between 974 their relative strengths, e.g., "auth1-weak" and "auth1-strong". 976 Authentication method implementers are encouraged to provide adequate 977 information, via message header field comments if necessary, to allow 978 an MUA developer to understand or relay ancillary details of 979 authentication results. For example, if it might be of interest to 980 relay what data was used to perform an evaluation, such information 981 could be relayed as a comment in the header field, such as: 983 Authentication-Results: example.com; 984 foo=pass bar.baz=blob (2 of 3 tests OK) 986 Experimental method identifiers MUST only be used within ADMDs that 987 have explicitly consented to use them. These method identifiers and 988 the parameters associated with them are not documented in RFCs. 990 Therefore, they are subject to change at any time and not suitable 991 for production use. Any MTA, MUA, or downstream filter intended for 992 production use SHOULD ignore or delete any Authentication-Results 993 header field that includes an experimental (unknown) method 994 identifier. 996 2.7.7. Extension Result Codes 998 Additional result codes (extension results) might be defined in the 999 future by later revisions or extensions to this specification. 1000 Result codes MUST be registered with the Internet Assigned Numbers 1001 Authority (IANA) and preferably published in an RFC. See Section 6 1002 for further details. 1004 Experimental results MUST only be used within ADMDs that have 1005 explicitly consented to use them. These results and the parameters 1006 associated with them are not formally documented. Therefore, they 1007 are subject to change at any time and not suitable for production 1008 use. Any MTA, MUA, or downstream filter intended for production use 1009 SHOULD ignore or delete any Authentication-Results header field that 1010 includes an extension result. 1012 3. The "iprev" Authentication Method 1014 This section defines an additional authentication method called 1015 "iprev". 1017 "iprev" is an attempt to verify that a client appears to be valid 1018 based on some DNS queries, which is to say that the IP address is 1019 explicitly associated with a domain name. Upon receiving a session 1020 initiation of some kind from a client, the IP address of the client 1021 peer is queried for matching names (i.e., a number-to-name 1022 translation, also known as a "reverse lookup" or a "PTR" record 1023 query). Once that result is acquired, a lookup of each of the names 1024 (i.e., a name-to-number translation, or an "A" or "AAAA" record 1025 query) thus retrieved is done. The response to this second check 1026 will typically result in at least one mapping back to the client's IP 1027 address. 1029 Expressed as an algorithm: If the client peer's IP address is I, the 1030 list of names to which I maps (after a "PTR" query) is the set N, and 1031 the union of IP addresses to which each member of N maps (after 1032 corresponding "A" and "AAAA" queries) is L, then this test is 1033 successful if I is an element of L. 1035 Often an MTA receiving a connection that fails this test will simply 1036 reject the connection using the enhanced status code defined in 1037 [AUTH-ESC]. If an operator instead wishes to make this information 1038 available to downstream agents as a factor in handling decisions, it 1039 records a result in accordance with Section 2.7.3. 1041 The response to a PTR query could contain multiple names. To prevent 1042 heavy DNS loads, agents performing these queries MUST be implemented 1043 such that the number of names evaluated by generation of 1044 corresponding A or AAAA queries is limited so as not to be unduly 1045 taxing to the DNS infrastructure, though it MAY be configurable by an 1046 administrator. As an example, Section 4.6.4 of [SPF] chose a limit 1047 of 10 for its implementation of this algorithm. 1049 "DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the 1050 query formats for the IPv6 case. 1052 There is some contention regarding the wisdom and reliability of this 1053 test. For example, in some regions, it can be difficult for this 1054 test ever to pass because the practice of arranging to match the 1055 forward and reverse DNS is infrequently observed. Therefore, the 1056 precise implementation details of how a verifier performs an "iprev" 1057 test are not specified here. The verifier MAY report a successful or 1058 failed "iprev" test at its discretion having done some kind of check 1059 of the validity of the connection's identity using DNS. It is 1060 incumbent upon an agent making use of the reported "iprev" result to 1061 understand what exactly that particular verifier is attempting to 1062 report. 1064 Extensive discussion of reverse DNS mapping and its implications can 1065 be found in "Considerations for the use of DNS Reverse Mapping" 1066 ([DNSOP-REVERSE]). In particular, it recommends that applications 1067 avoid using this test as a means of authentication or security. Its 1068 presence in this document is not an endorsement but is merely 1069 acknowledgment that the method remains common and provides the means 1070 to relay the results of that test. 1072 4. Adding the Header Field to a Message 1074 This specification makes no attempt to evaluate the relative 1075 strengths of various message authentication methods that may become 1076 available. The methods listed are an order-independent set; their 1077 sequence does not indicate relative strength or importance of one 1078 method over another. Instead, the MUA or downstream filter consuming 1079 this header field is to interpret the result of each method based on 1080 its own knowledge of what that method evaluates. 1082 Each "method" MUST refer to an authentication method declared in the 1083 IANA registry or an extension method as described in Section 2.7.6, 1084 and each "result" MUST refer to a result code declared in the IANA 1085 registry or an extension result code as defined in Section 2.7.7. 1087 See Section 6 for further information about the registered methods 1088 and result codes. 1090 An MTA compliant with this specification adds this header field 1091 (after performing one or more message authentication tests) to 1092 indicate which MTA or ADMD performed the test, which test got 1093 applied, and what the result was. If an MTA applies more than one 1094 such test, it adds this header field either once per test or once 1095 indicating all of the results. An MTA MUST NOT add a result to an 1096 existing header field. 1098 An MTA MAY add this header field containing only the authentication 1099 identifier portion and the "none" token (see Section 2.2) to indicate 1100 explicitly that no message authentication schemes were applied prior 1101 to delivery of this message. 1103 An MTA adding this header field has to take steps to identify it as 1104 legitimate to the MUAs or downstream filters that will ultimately 1105 consume its content. One process to do so is described in Section 5. 1106 Further measures may be necessary in some environments. Some 1107 possible solutions are enumerated in Section 7.1. This document does 1108 not mandate any specific solution to this issue as each environment 1109 has its own facilities and limitations. 1111 Most known message authentication methods focus on a particular 1112 identifier to evaluate. SPF and Sender ID differ in that they can 1113 yield a result based on more than one identifier; specifically, SPF 1114 can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom 1115 parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter 1116 or the Purported Responsible Address (PRA) identity. When generating 1117 this field to report those results, only the parameter that yielded 1118 the result is included. 1120 For MTAs that add this header field, adding header fields in order 1121 (at the top), per Section 3.6 of [MAIL], is particularly important. 1122 Moreover, this header field SHOULD be inserted above any other trace 1123 header fields such MTAs might prepend. This placement allows easy 1124 detection of header fields that can be trusted. 1126 End users making direct use of this header field might inadvertently 1127 trust information that has not been properly vetted. If, for 1128 example, a basic SPF result were to be relayed that claims an 1129 authenticated addr-spec, the local-part of that addr-spec has 1130 actually not been authenticated. Thus, an MTA adding this header 1131 field SHOULD NOT include any data that has not been authenticated by 1132 the method(s) being applied. Moreover, MUAs SHOULD NOT render to 1133 users such information if it is presented by a method known not to 1134 authenticate it. 1136 4.1. Header Field Position and Interpretation 1138 In order to ensure non-ambiguous results and avoid the impact of 1139 false header fields, MUAs and downstream filters SHOULD NOT interpret 1140 this header field unless specifically configured to do so by the user 1141 or administrator. That is, this interpretation should not be "on by 1142 default". Naturally then, users or administrators ought not activate 1143 such a feature unless they are certain the header field will be 1144 validly added by an agent within the ADMD that accepts the mail that 1145 is ultimately read by the MUA, and instances of the header field 1146 appearing to originate within the ADMD but are actually added by 1147 foreign MTAs will be removed before delivery. 1149 Furthermore, MUAs and downstream filters SHOULD NOT interpret this 1150 header field unless the authentication service identifier it bears 1151 appears to be one used within its own ADMD as configured by the user 1152 or administrator. 1154 MUAs and downstream filters MUST ignore any result reported using a 1155 "result" not specified in the IANA "Result Code" registry or a 1156 "ptype" not listed in the corresponding registry for such values as 1157 defined in Section 6. Moreover, such agents MUST ignore a result 1158 indicated for any "method" they do not specifically support. 1160 An MUA SHOULD NOT reveal these results to end users, absent careful 1161 human factors design considerations and testing, for the presentation 1162 of trust-related materials. For example, an attacker could register 1163 examp1e.com (note the digit "one") and send signed mail to intended 1164 victims; a verifier would detect that the signature was valid and 1165 report a "pass" even though it's clear the DNS domain name was 1166 intended to mislead. See Section 7.2 for further discussion. 1168 As stated in Section 2.1, this header field MUST be treated as though 1169 it were a trace header field as defined in Section 3.6.7 of [MAIL] 1170 and hence MUST NOT be reordered and MUST be prepended to the message, 1171 so that there is generally some indication upon delivery of where in 1172 the chain of handling MTAs the message authentication was done. 1174 Note that there are a few message handlers that are only capable of 1175 appending new header fields to a message. Strictly speaking, these 1176 handlers are not compliant with this specification. They can still 1177 add the header field to carry authentication details, but any signal 1178 about where in the handling chain the work was done may be lost. 1179 Consumers SHOULD be designed such that this can be tolerated, 1180 especially from a producer known to have this limitation. 1182 MUAs SHOULD ignore instances of this header field discovered within 1183 message/rfc822 MIME attachments. 1185 Further discussion of these topics can be found in Section 7 below. 1187 4.2. Local Policy Enforcement 1189 Some sites have a local policy that considers any particular 1190 authentication policy's non-recoverable failure results (typically 1191 "fail" or similar) as justification for rejecting the message. In 1192 such cases, the border MTA SHOULD issue an SMTP rejection response to 1193 the message, rather than adding this header field and allowing the 1194 message to proceed toward delivery. This is more desirable than 1195 allowing the message to reach an internal host's MTA or spam filter, 1196 thus possibly generating a local rejection such as a Delivery Status 1197 Notification (DSN) [DSN] to a forged originator. Such generated 1198 rejections are colloquially known as "backscatter". 1200 The same MAY also be done for local policy decisions overriding the 1201 results of the authentication methods (e.g., the "policy" result 1202 codes described in Section 2.7). 1204 Such rejections at the SMTP protocol level are not possible if local 1205 policy is enforced at the MUA and not the MTA. 1207 5. Removing Existing Header Fields 1209 For security reasons, any MTA conforming to this specification MUST 1210 delete any discovered instance of this header field that claims, by 1211 virtue of its authentication service identifier, to have been added 1212 within its trust boundary but that did not come directly from another 1213 trusted MTA. For example, an MTA for example.com receiving a message 1214 MUST delete or otherwise obscure any instance of this header field 1215 bearing an authentication service identifier indicating that the 1216 header field was added within example.com prior to adding its own 1217 header fields. This could mean each MTA will have to be equipped 1218 with a list of internal MTAs known to be compliant (and hence 1219 trustworthy). 1221 For simplicity and maximum security, a border MTA could remove all 1222 instances of this header field on mail crossing into its trust 1223 boundary. However, this may conflict with the desire to access 1224 authentication results performed by trusted external service 1225 providers. It may also invalidate signed messages whose signatures 1226 cover external instances of this header field. A more robust border 1227 MTA could allow a specific list of authenticating MTAs whose 1228 information is to be admitted, removing the header field originating 1229 from all others. 1231 As stated in Section 1.2, a formal definition of "trust boundary" is 1232 deliberately not made here. It is entirely possible that a border 1233 MTA for example.com will explicitly trust authentication results 1234 asserted by upstream host example.net even though they exist in 1235 completely disjoint administrative boundaries. In that case, the 1236 border MTA MAY elect not to delete those results; moreover, the 1237 upstream host doing some authentication work could apply a signing 1238 technology such as [DKIM] on its own results to assure downstream 1239 hosts of their authenticity. An example of this is provided in 1240 Appendix C. 1242 Similarly, in the case of messages signed using [DKIM] or other 1243 message-signing methods that sign header fields, this removal action 1244 could invalidate one or more signatures on the message if they 1245 covered the header field to be removed. This behavior can be 1246 desirable since there's little value in validating the signature on a 1247 message with forged header fields. However, signing agents MAY 1248 therefore elect to omit these header fields from signing to avoid 1249 this situation. 1251 An MTA SHOULD remove any instance of this header field bearing a 1252 version (express or implied) that it does not support. However, an 1253 MTA MUST remove such a header field if the [SMTP] connection relaying 1254 the message is not from a trusted internal MTA. This means the MTA 1255 needs to be able to understand versions of this header field at least 1256 as late as the ones understood by the MUAs or other consumers within 1257 its ADMD. 1259 6. IANA Considerations 1261 IANA has registered the defined header field and created tables as 1262 described below. These registry actions were originally defined by 1263 [RFC5451] and updated by [RFC6577] and [RFC7001]. The created 1264 registries are being further updated here to increase their 1265 completeness. 1267 6.1. The Authentication-Results Header Field 1269 [RFC5451] added the Authentication-Results header field to the IANA 1270 "Permanent Message Header Field Names" registry, per the procedure 1271 found in [IANA-HEADERS]. That entry is to be updated to reference 1272 this document. The following is the registration template: 1274 Header field name: Authentication-Results 1275 Applicable protocol: mail ([MAIL]) 1276 Status: Standard 1277 Author/Change controller: IETF 1278 Specification document(s): [this RFC] 1279 Related information: none 1281 6.2. "Email Authentication Methods" Registry Description 1283 Names of message authentication methods supported by this 1284 specification are to be registered with IANA, with the exception of 1285 experimental names as described in Section 2.7.6. Along with each 1286 method is recorded the properties that accompany the method's result. 1288 The "Email Authentication Parameters" group, and within it the "Email 1289 Authentication Methods" registry, were created by [RFC5451] for this 1290 purpose. [RFC6577] added a "status" field for each entry. [RFC7001] 1291 amended the rules governing that registry, and also added a "version" 1292 field to the registry. 1294 The reference for that registry shall be updated to reference this 1295 document. 1297 New entries are assigned only for values that have received Expert 1298 Review, per [IANA-CONSIDERATIONS]. The designated expert shall be 1299 appointed by the IESG. The designated expert has discretion to 1300 request that a publication be referenced if a clear, concise 1301 definition of the authentication method cannot be provided such that 1302 interoperability is assured. Registrations should otherwise be 1303 permitted. The designated expert can also handle requests to mark 1304 any current registration as "deprecated". 1306 No two entries can have the same combination of method, ptype, and 1307 property. 1309 An entry in this registry contains the following: 1311 Method: the name of the method; 1313 Definition: a reference to the document that created this entry, if 1314 any (see below); 1316 ptype: a "ptype" value appropriate for use with that method; 1318 property: a "property" value matching that "ptype" also appropriate 1319 for use with that method; 1321 Value: a brief description of the value to be supplied with that 1322 method/ptype/property tuple; 1324 Status: the status of this entry, which is either: 1326 active: The entry is in current use. 1328 deprecated: The entry is no longer in current use. 1330 Version: a version number associated with the method (preferably 1331 starting at "1"). 1333 The "Definition" field will typically refer to a permanent document, 1334 or at least some descriptive text, where additional information about 1335 the entry being added can be found. This might in turn reference the 1336 document where the method is defined so that all of the semantics 1337 around creating or interpreting an Authentication-Results header 1338 field using this method, ptype, and property can be understood. 1340 6.3. "Email Authentication Methods" Registry Update 1342 The following changes are to be made to this registry upon approval 1343 of this document: 1345 1. The "Defined" field shall be renamed to "Definition", to be 1346 consistent with the other registries in this group. 1348 2. The current entry for the "auth" method shall have its "property" 1349 field changed to "mailfrom", and its "Definition" field changed 1350 to this document. 1352 3. The entry for the "dkim" method, "header" ptype and "b" property 1353 shall now reference [RFC6008] as its defining document, and the 1354 reference shall be removed from the description. 1356 4. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" 1357 method entries shall have their "Definition" fields changed to 1358 this document, as this document contains a complete description 1359 of the registry and these corresponding values. 1361 5. All "smime" entries have their "Definition" fields changed to 1362 [SMIME-REG]. 1364 6. The "value" field of the "smime" entry using property "smime- 1365 part" shall be changed to read: "The MIME body part reference 1366 that contains the S/MIME signature. See Section 3.2.1 of RFC7281 1367 for full syntax." 1369 7. The following entry is to be added: 1371 Method: auth 1373 Definition: [this document] 1375 ptype: smtp 1377 property: auth 1379 Value: identity confirmed by the AUTH command 1381 Status: active 1383 Version: 1 1385 8. The values of the "domainkeys" entries for ptype "header" are 1386 updated as follows: 1388 from: contents of the [MAIL] From: header field, after removing 1389 comments, and removing the local-part and following "@" if not 1390 authenticated 1392 sender: contents of the [MAIL] Sender: header field, after 1393 removing comments, and removing the local-part and following 1394 "@" if not authenticated 1396 9. All entries for "dkim-adsp" and "domainkeys" shall have their 1397 Status values changed to "deprecated", reflecting the fact that 1398 the corresponding specifications now have Historical status. 1399 Their "Definition" fields shall also be modified to include a 1400 reference to this document. 1402 6.4. "Email Authentication Property Types" Registry 1404 [PTYPES-REGISTRY] created the Email Authentication Property Types 1405 registry. 1407 Entries in this registry are subject to the Expert Review rules as 1408 described in [IANA-CONSIDERATIONS]. Each entry in the registry 1409 requires the following values: 1411 ptype: The name of the ptype being registered, which must fit within 1412 the ABNF described in Section 2.2. 1414 Definition: An optional reference to a defining specification. 1416 Description: A brief description of what sort of information this 1417 "ptype" is meant to cover. 1419 For new entries, the Designated Expert needs to assure that the 1420 description provided for the new entry adequately describes the 1421 intended use. An example would be helpful to include in the entry's 1422 defining document, if any, although entries in the "Email 1423 Authentication Methods" registry or the "Email Authentication Result 1424 Names" registry might also serve as examples of intended use. 1426 As this is a complete re-statement of the definition and rules for 1427 this registry, IANA shall update this registry to show Section 2.3 of 1428 this document as the current definitions for the "body", "header", 1429 "policy" and "smtp" entries of that registry. References to 1430 [RFC7001] shall be removed. 1432 6.5. "Email Authentication Result Names" Description 1434 Names of message authentication result codes supported by this 1435 specification must be registered with IANA, with the exception of 1436 experimental codes as described in Section 2.7.7. A registry was 1437 created by [RFC5451] for this purpose. [RFC6577] added the "status" 1438 column, and [RFC7001] updated the rules governing that registry. 1440 New entries are assigned only for values that have received Expert 1441 Review, per [IANA-CONSIDERATIONS]. The designated expert shall be 1442 appointed by the IESG. The designated expert has discretion to 1443 request that a publication be referenced if a clear, concise 1444 definition of the authentication result cannot be provided such that 1445 interoperability is assured. Registrations should otherwise be 1446 permitted. The designated expert can also handle requests to mark 1447 any current registration as "deprecated". 1449 No two entries can have the same combination of method and code. 1451 An entry in this registry contains the following: 1453 Auth Method: an authentication method for which results are being 1454 returned using the header field defined in this document; 1456 Code: a result code that can be returned for this authentication 1457 method; 1459 Specification: either free form text explaining the meaning of this 1460 method-code combination, or a reference to such a definition. 1462 Status: the status of this entry, which is either: 1464 active: The entry is in current use. 1466 deprecated: The entry is no longer in current use. 1468 6.6. "Email Authentication Result Names" Update 1470 This document includes a complete description of the registry, 1471 obsoleting [RFC7001]. Accordingly, the following changes are to be 1472 made to this registry on publication of this document: 1474 o The "Defined" field shall be removed. 1476 o The "Meaning" field shall be renamed to "Specification", as 1477 described above. 1479 o The "Auth Method" field shall appear before the "Code" field. 1481 o For easier searching, the table shall be arranged such that it is 1482 sorted first by Auth Method, then by Code within each Auth Method 1483 grouping. 1485 o All entries for the "dkim", "domainkeys", "spf", "sender-id", 1486 "auth", and "iprev" methods shall have their "Specification" 1487 fields changed to refer to this document, as follows: 1489 dkim: [this document] Section 2.7.1 1491 domainkeys: [this document] Section 2.7.1 1493 spf: [this document] Section 2.7.2 1495 sender-id: [this document] Section 2.7.2 1497 auth: [this document] Section 2.7.4 1499 iprev: [this document] Section 2.7.3 1501 o All entries for "dkim-adsp" that are missing an explicit reference 1502 to a defining document shall have [ADSP] added to their 1503 Specification fields. 1505 o All entries for "dkim-adsp" and "domainkeys" shall have their 1506 Status values changed to "deprecated", reflecting the fact that 1507 the corresponding specifications now have Historical status. 1508 Their "Specification" fields shall also be modified to include a 1509 reference to this document. 1511 6.7. SMTP Enhanced Stauts Codes 1513 The entry for X.7.25 in the Enumerated Status Codes sub-registry of 1514 the SMTP Enhanced Status Codes registry is to be updated to refer to 1515 this document instead of [RFC7001]. 1517 7. Security Considerations 1519 The following security considerations apply when adding or processing 1520 the Authentication-Results header field: 1522 7.1. Forged Header Fields 1524 An MUA or filter that accesses a mailbox whose messages are handled 1525 by a non-conformant MTA, and understands Authentication-Results 1526 header fields, could potentially make false conclusions based on 1527 forged header fields. A malicious user or agent could forge a header 1528 field using the DNS domain of a receiving ADMD as the authserv-id 1529 token in the value of the header field and, with the rest of the 1530 value, claim that the message was properly authenticated. The non- 1531 conformant MTA would fail to strip the forged header field, and the 1532 MUA could inappropriately trust it. 1534 For this reason, it is best not to have processing of the 1535 Authentication-Results header field enabled by default; instead, it 1536 should be ignored, at least for the purposes of enacting filtering 1537 decisions, unless specifically enabled by the user or administrator 1538 after verifying that the border MTA is compliant. It is acceptable 1539 to have an MUA aware of this specification but have an explicit list 1540 of hostnames whose Authentication-Results header fields are 1541 trustworthy; however, this list should initially be empty. 1543 Proposed alternative solutions to this problem were made some time 1544 ago and are listed below. To date, they have not been developed due 1545 to lack of demand but are documented here should the information be 1546 useful at some point in the future: 1548 1. Possibly the simplest is a digital signature protecting the 1549 header field, such as using [DKIM], that can be verified by an 1550 MUA by using a posted public key. Although one of the main 1551 purposes of this document is to relieve the burden of doing 1552 message authentication work at the MUA, this only requires that 1553 the MUA learn a single authentication scheme even if a number of 1554 them are in use at the border MTA. Note that [DKIM] requires 1555 that the From header field be signed, although in this 1556 application, the signing agent (a trusted MTA) likely cannot 1557 authenticate that value, so the fact that it is signed should be 1558 ignored. Where the authserv-id is the ADMD's domain name, the 1559 authserv-id matching this valid internal signature's "d=" DKIM 1560 value is sufficient. 1562 2. Another would be a means to interrogate the MTA that added the 1563 header field to see if it is actually providing any message 1564 authentication services and saw the message in question, but this 1565 isn't especially palatable given the work required to craft and 1566 implement such a scheme. 1568 3. Yet another might be a method to interrogate the internal MTAs 1569 that apparently handled the message (based on Received header 1570 fields) to determine whether any of them conform to Section 5 of 1571 this memo. This, too, has potentially high barriers to entry. 1573 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to 1574 allow an MUA or filtering agent to acquire the authserv-id in use 1575 within an ADMD, thus allowing it to identify which 1576 Authentication-Results header fields it can trust. 1578 5. On the presumption that internal MTAs are fully compliant with 1579 Section 3.6 of [MAIL] and the compliant internal MTAs are using 1580 their own hostnames or the ADMD's DNS domain name as the 1581 authserv-id token, the header field proposed here should always 1582 appear above a Received header added by a trusted MTA. This can 1583 be used as a test for header field validity. 1585 Support for some of these is being considered for future work. 1587 In any case, a mechanism needs to exist for an MUA or filter to 1588 verify that the host that appears to have added the header field (a) 1589 actually did so and (b) is legitimately adding that header field for 1590 this delivery. Given the variety of messaging environments deployed 1591 today, consensus appears to be that specifying a particular mechanism 1592 for doing so is not appropriate for this document. 1594 Mitigation of the forged header field attack can also be accomplished 1595 by moving the authentication results data into meta-data associated 1596 with the message. In particular, an [SMTP] extension could be 1597 established to communicate authentication results from the border MTA 1598 to intermediate and delivery MTAs; the latter of these could arrange 1599 to store the authentication results as meta-data retrieved and 1600 rendered along with the message by an [IMAP] client aware of a 1601 similar extension in that protocol. The delivery MTA would be told 1602 to trust data via this extension only from MTAs it trusts, and border 1603 MTAs would not accept data via this extension from any source. There 1604 is no vector in such an arrangement for forgery of authentication 1605 data by an outside agent. 1607 7.2. Misleading Results 1609 Until some form of service for querying the reputation of a sending 1610 agent is widely deployed, the existence of this header field 1611 indicating a "pass" does not render the message trustworthy. It is 1612 possible for an arriving piece of spam or other undesirable mail to 1613 pass checks by several of the methods enumerated above (e.g., a piece 1614 of spam signed using [DKIM] by the originator of the spam, which 1615 might be a spammer or a compromised system). In particular, this 1616 issue is not resolved by forged header field removal discussed above. 1618 Hence, MUAs and downstream filters must take some care with use of 1619 this header even after possibly malicious headers are scrubbed. 1621 7.3. Header Field Position 1623 Despite the requirements of [MAIL], header fields can sometimes be 1624 reordered en route by intermediate MTAs. The goal of requiring 1625 header field addition only at the top of a message is an 1626 acknowledgment that some MTAs do reorder header fields, but most do 1627 not. Thus, in the general case, there will be some indication of 1628 which MTAs (if any) handled the message after the addition of the 1629 header field defined here. 1631 7.4. Reverse IP Query Denial-of-Service Attacks 1633 Section 4.6.4 of [SPF] describes a DNS-based denial-of-service attack 1634 for verifiers that attempt DNS-based identity verification of 1635 arriving client connections. A verifier wishing to do this check and 1636 report this information needs to take care not to go to unbounded 1637 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1638 making use of an "iprev" result specified by this document need to be 1639 aware of the algorithm used by the verifier reporting the result and, 1640 especially, its limitations. 1642 7.5. Mitigation of Backscatter 1644 Failing to follow the instructions of Section 4.2 can result in a 1645 denial-of-service attack caused by the generation of [DSN] messages 1646 (or equivalent) to addresses that did not send the messages being 1647 rejected. 1649 7.6. Internal MTA Lists 1651 Section 5 describes a procedure for scrubbing header fields that may 1652 contain forged authentication results about a message. A compliant 1653 installation will have to include, at each MTA, a list of other MTAs 1654 known to be compliant and trustworthy. Failing to keep this list 1655 current as internal infrastructure changes may expose an ADMD to 1656 attack. 1658 7.7. Attacks against Authentication Methods 1660 If an attack becomes known against an authentication method, clearly 1661 then the agent verifying that method can be fooled into thinking an 1662 inauthentic message is authentic, and thus the value of this header 1663 field can be misleading. It follows that any attack against the 1664 authentication methods supported by this document is also a security 1665 consideration here. 1667 7.8. Intentionally Malformed Header Fields 1669 It is possible for an attacker to add an Authentication-Results 1670 header field that is extraordinarily large or otherwise malformed in 1671 an attempt to discover or exploit weaknesses in header field parsing 1672 code. Implementers must thoroughly verify all such header fields 1673 received from MTAs and be robust against intentionally as well as 1674 unintentionally malformed header fields. 1676 7.9. Compromised Internal Hosts 1678 An internal MUA or MTA that has been compromised could generate mail 1679 with a forged From header field and a forged Authentication-Results 1680 header field that endorses it. Although it is clearly a larger 1681 concern to have compromised internal machines than it is to prove the 1682 value of this header field, this risk can be mitigated by arranging 1683 that internal MTAs will remove this header field if it claims to have 1684 been added by a trusted border MTA (as described above), yet the 1685 [SMTP] connection is not coming from an internal machine known to be 1686 running an authorized MTA. However, in such a configuration, 1687 legitimate MTAs will have to add this header field when legitimate 1688 internal-only messages are generated. This is also covered in 1689 Section 5. 1691 7.10. Encapsulated Instances 1693 MIME messages can contain attachments of type "message/rfc822", which 1694 contain other messages. Such an encapsulated message can also 1695 contain an Authentication-Results header field. Although the 1696 processing of these is outside of the intended scope of this document 1697 (see Section 1.3), some early guidance to MUA developers is 1698 appropriate here. 1700 Since MTAs are unlikely to strip Authentication-Results header fields 1701 after mailbox delivery, MUAs are advised in Section 4.1 to ignore 1702 such instances within MIME attachments. Moreover, when extracting a 1703 message digest to separate mail store messages or other media, such 1704 header fields should be removed so that they will never be 1705 interpreted improperly by MUAs that might later consume them. 1707 7.11. Reverse Mapping 1709 Although Section 3 of this memo includes explicit support for the 1710 "iprev" method, its value as an authentication mechanism is limited. 1711 Implementers of both this proposal and agents that use the data it 1712 relays are encouraged to become familiar with the issues raised by 1713 [DNSOP-REVERSE] when deciding whether or not to include support for 1714 "iprev". 1716 8. References 1718 8.1. Normative References 1720 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 1721 Syntax Specifications: ABNF", STD 68, 1722 RFC 5234, January 2008. 1724 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 1725 "Registration Procedures for Message Header 1726 Fields", BCP 90, RFC 3864, September 2004. 1728 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 1729 Indicate Requirement Levels", BCP 14, 1730 RFC 2119. 1732 [MAIL] Resnick, P., Ed., "Internet Message Format", 1733 RFC 5322, October 2008. 1735 [MIME] Freed, N. and N. Borenstein, "Multipurpose 1736 Internet Mail Extensions (MIME) Part One: 1737 Format of Internet Message Bodies", RFC 2045, 1738 November 1996. 1740 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 1741 RFC 5321, October 2008. 1743 8.2. Informative References 1745 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 1746 Levine, "DomainKeys Identified Mail (DKIM) 1747 Author Domain Signing Practices (ADSP)", 1748 RFC 5617, August 2009. 1750 [AR-VBR] Kucherawy, M., "Authentication-Results 1751 Registration for Vouch by Reference Results", 1752 RFC 6212, April 2011. 1754 [ATPS] Kucherawy, M., "DomainKeys Identified Mail 1755 (DKIM) Authorized Third-Party Signatures", 1756 RFC 6541, February 2012. 1758 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service 1759 Extension for Authentication", RFC 4954, 1760 July 2007. 1762 [AUTH-ESC] Kucherawy, M., "Email Authentication Status 1763 Codes", RFC 7372, September 2014. 1765 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, 1766 "DomainKeys Identified Mail (DKIM) 1767 Signatures", STD 76, RFC 6376, September 2011. 1769 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., 1770 "Domain-based Message Authentication, 1771 Reporting and Conformance (DMARC)", RFC 7489, 1772 March 2015. 1774 [DNS] Mockapetris, P., "Domain names - 1775 Implementation and Specification", STD 13, 1776 RFC 1035, November 1987. 1778 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. 1779 Souissi, "DNS Extensions to Support IP Version 1780 6", RFC 3596, October 2003. 1782 [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for 1783 the use of DNS Reverse Mapping", Work 1784 in Progress, March 2008. 1786 [DOMAINKEYS] Delany, M., "Domain-Based Email Authentication 1787 Using Public Keys Advertised in the DNS 1788 (DomainKeys)", RFC 4870, May 2007. 1790 [DSN] Moore, K. and G. Vaudreuil, "An Extensible 1791 Message Format for Delivery Status 1792 Notifications", RFC 3464, January 2003. 1794 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 1795 RFC 5598, July 2009. 1797 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 1798 Writing an IANA Considerations Section in 1799 RFCs", BCP 26, RFC 5226, May 2008. 1801 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL 1802 - VERSION 4rev1", RFC 3501, March 2003. 1804 [POP3] Myers, J. and M. Rose, "Post Office Protocol - 1805 Version 3", STD 53, RFC 1939, May 1996. 1807 [PRA] Lyon, J., "Purported Responsible Address in 1808 E-Mail Messages", RFC 4407, April 2006. 1810 [PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for 1811 the Authentication-Results Header Field", 1812 RFC 7410, December 2014. 1814 [RFC5451] Kucherawy, M., "Message Header Field for 1815 Indicating Message Authentication Status", 1816 RFC 5451, April 2009. 1818 [RFC6008] Kucherawy, M., "Authentication-Results 1819 Registration for Differentiating among 1820 Cryptographic Results", RFC 6008, 1821 September 2010. 1823 [RFC6577] Kucherawy, M., "Authentication-Results 1824 Registration Update for Sender Policy 1825 Framework (SPF) Results", RFC 6577, 1826 March 2012. 1828 [RFC7001] Kucherawy, M., "Message Header Field for 1829 Indicating Message Authentication Status", 1830 RFC 7001, September 2013. 1832 [RRVS] Mills, W. and M. Kucherawy, "The Require- 1833 Recipient-Valid-Since Header Field and SMTP 1834 Service Extension", RFC 7293, July 2014. 1836 [SECURITY] Rescorla, E. and B. Korver, "Guidelines for 1837 Writing RFC Text on Security Considerations", 1838 BCP 72, RFC 3552, July 2003. 1840 [SENDERID] Lyon, J. and M. Wong, "Sender ID: 1841 Authenticating E-Mail", RFC 4406, April 2006. 1843 [SMIME-REG] Melnikov, A., "Authentication-Results 1844 Registration for S/MIME Signature 1845 Verification", RFC 7281, June 2014. 1847 [SPF] Kitterman, S., "Sender Policy Framework (SPF) 1848 for Authorizing Use of Domains in E-Mail, 1849 Version 1", RFC 7208, April 2014. 1851 [VBR] Hoffman, P., Levine, J., and A. Hathcock, 1852 "Vouch By Reference", RFC 5518, April 2009. 1854 Appendix A. Acknowledgments 1856 The author wishes to acknowledge the following individuals for their 1857 review and constructive criticism of this document: Stephane 1858 Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete 1859 Resnick. 1861 Appendix B. Legacy MUAs 1863 Implementers of this protocol should be aware that many MUAs are 1864 unlikely to be retrofitted to support the new header field and its 1865 semantics. In the interests of convenience and quicker adoption, a 1866 delivery MTA might want to consider adding things that are processed 1867 by existing MUAs in addition to the Authentication-Results header 1868 field. One suggestion is to include a Priority header field, on 1869 messages that don't already have such a header field, containing a 1870 value that reflects the strength of the authentication that was 1871 accomplished, e.g., "low" for weak or no authentication, "normal" or 1872 "high" for good or strong authentication. 1874 Some modern MUAs can already filter based on the content of this 1875 header field. However, there is keen interest in having MUAs make 1876 some kind of graphical representation of this header field's meaning 1877 to end users. Until this capability is added, other interim means of 1878 conveying authentication results may be necessary while this proposal 1879 and its successors are adopted. 1881 Appendix C. Authentication-Results Examples 1883 This section presents some examples of the use of this header field 1884 to indicate authentication results. 1886 C.1. Trivial Case; Header Field Not Present 1888 The trivial case: 1890 Received: from mail-router.example.com 1891 (mail-router.example.com [192.0.2.1]) 1892 by server.example.org (8.11.6/8.11.6) 1893 with ESMTP id g1G0r1kA003489; 1894 Fri, Feb 15 2002 17:19:07 -0800 1895 From: sender@example.com 1896 Date: Fri, Feb 15 2002 16:54:30 -0800 1897 To: receiver@example.org 1898 Message-Id: <12345.abc@example.com> 1899 Subject: here's a sample 1901 Hello! Goodbye! 1903 Example 1: Trivial Case 1905 The Authentication-Results header field is completely absent. The 1906 MUA may make no conclusion about the validity of the message. This 1907 could be the case because the message authentication services were 1908 not available at the time of delivery, or no service is provided, or 1909 the MTA is not in compliance with this specification. 1911 C.2. Nearly Trivial Case; Service Provided, but No Authentication Done 1913 A message that was delivered by an MTA that conforms to this 1914 specification but provides no actual message authentication service: 1916 Authentication-Results: example.org 1; none 1917 Received: from mail-router.example.com 1918 (mail-router.example.com [192.0.2.1]) 1919 by server.example.org (8.11.6/8.11.6) 1920 with ESMTP id g1G0r1kA003489; 1921 Fri, Feb 15 2002 17:19:07 -0800 1922 From: sender@example.com 1923 Date: Fri, Feb 15 2002 16:54:30 -0800 1924 To: receiver@example.org 1925 Message-Id: <12345.abc@example.com> 1926 Subject: here's a sample 1928 Hello! Goodbye! 1930 Example 2: Header Present but No Authentication Done 1932 The Authentication-Results header field is present, showing that the 1933 delivering MTA conforms to this specification. It used its DNS 1934 domain name as the authserv-id. The presence of "none" (and the 1935 absence of any method and result tokens) indicates that no message 1936 authentication was done. The version number of the specification to 1937 which the field's content conforms is explicitly provided. 1939 C.3. Service Provided, Authentication Done 1941 A message that was delivered by an MTA that conforms to this 1942 specification and applied some message authentication: 1944 Authentication-Results: example.com; 1945 spf=pass smtp.mailfrom=example.net 1946 Received: from dialup-1-2-3-4.example.net 1947 (dialup-1-2-3-4.example.net [192.0.2.200]) 1948 by mail-router.example.com (8.11.6/8.11.6) 1949 with ESMTP id g1G0r1kA003489; 1950 Fri, Feb 15 2002 17:19:07 -0800 1951 From: sender@example.net 1952 Date: Fri, Feb 15 2002 16:54:30 -0800 1953 To: receiver@example.com 1954 Message-Id: <12345.abc@example.net> 1955 Subject: here's a sample 1957 Hello! Goodbye! 1959 Example 3: Header Reporting Results 1961 The Authentication-Results header field is present, indicating that 1962 the border MTA conforms to this specification. The authserv-id is 1963 once again the DNS domain name. Furthermore, the message was 1964 authenticated by that MTA via the method specified in [SPF]. Note 1965 that since that method cannot authenticate the local-part, it has 1966 been omitted from the result's value. The MUA could extract and 1967 relay this extra information if desired. 1969 C.4. Service Provided, Several Authentications Done, Single MTA 1971 A message that was relayed inbound via a single MTA that conforms to 1972 this specification and applied three different message authentication 1973 checks: 1975 Authentication-Results: example.com; 1976 auth=pass (cram-md5) smtp.auth=sender@example.net; 1977 spf=pass smtp.mailfrom=example.net 1978 Authentication-Results: example.com; 1979 sender-id=pass header.from=example.net 1980 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1981 (dialup-1-2-3-4.example.net [192.0.2.200]) 1982 by mail-router.example.com (8.11.6/8.11.6) 1983 with ESMTPA id g1G0r1kA003489; 1984 Fri, Feb 15 2002 17:19:07 -0800 1985 Date: Fri, Feb 15 2002 16:54:30 -0800 1986 To: receiver@example.com 1987 From: sender@example.net 1988 Message-Id: <12345.abc@example.net> 1989 Subject: here's a sample 1991 Hello! Goodbye! 1993 Example 4: Headers Reporting Results from One MTA 1995 The Authentication-Results header field is present, indicating that 1996 the delivering MTA conforms to this specification. Once again, the 1997 receiving DNS domain name is used as the authserv-id. Furthermore, 1998 the sender authenticated herself/himself to the MTA via a method 1999 specified in [AUTH], and both SPF and Sender ID checks were done and 2000 passed. The MUA could extract and relay this extra information if 2001 desired. 2003 Two Authentication-Results header fields are not required since the 2004 same host did all of the checking. The authenticating agent could 2005 have consolidated all the results into one header field. 2007 This example illustrates a scenario in which a remote user on a 2008 dialup connection (example.net) sends mail to a border MTA 2009 (example.com) using SMTP authentication to prove identity. The 2010 dialup provider has been explicitly authorized to relay mail as 2011 example.com resulting in passes by the SPF and Sender ID checks. 2013 C.5. Service Provided, Several Authentications Done, Different MTAs 2015 A message that was relayed inbound by two different MTAs that conform 2016 to this specification and applied multiple message authentication 2017 checks: 2019 Authentication-Results: example.com; 2020 sender-id=fail header.from=example.com; 2021 dkim=pass (good signature) header.d=example.com 2022 Received: from mail-router.example.com 2023 (mail-router.example.com [192.0.2.1]) 2024 by auth-checker.example.com (8.11.6/8.11.6) 2025 with ESMTP id i7PK0sH7021929; 2026 Fri, Feb 15 2002 17:19:22 -0800 2027 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 2028 t=1188964191; c=simple/simple; h=From:Date:To:Subject: 2029 Message-Id:Authentication-Results; 2030 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 2031 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 2032 Authentication-Results: example.com; 2033 auth=pass (cram-md5) smtp.auth=sender@example.com; 2034 spf=fail smtp.mailfrom=example.com 2035 Received: from dialup-1-2-3-4.example.net 2036 (dialup-1-2-3-4.example.net [192.0.2.200]) 2037 by mail-router.example.com (8.11.6/8.11.6) 2038 with ESMTPA id g1G0r1kA003489; 2039 Fri, Feb 15 2002 17:19:07 -0800 2040 From: sender@example.com 2041 Date: Fri, Feb 15 2002 16:54:30 -0800 2042 To: receiver@example.com 2043 Message-Id: <12345.abc@example.com> 2044 Subject: here's a sample 2046 Hello! Goodbye! 2048 Example 5: Headers Reporting Results from Multiple MTAs 2050 The Authentication-Results header field is present, indicating 2051 conformance to this specification. Once again, the authserv-id used 2052 is the recipient's DNS domain name. The header field is present 2053 twice because two different MTAs in the chain of delivery did 2054 authentication tests. The first MTA, mail-router.example.com, 2055 reports that SMTP AUTH and SPF were both used and that the former 2056 passed while the latter failed. In the SMTP AUTH case, additional 2057 information is provided in the comment field, which the MUA can 2058 choose to render if desired. 2060 The second MTA, auth-checker.example.com, reports that it did a 2061 Sender ID test (which failed) and a DKIM test (which passed). Again, 2062 additional data about one of the tests is provided as a comment, 2063 which the MUA may choose to render. Also noteworthy here is the fact 2064 that there is a DKIM signature added by example.com that assured the 2065 integrity of the lower Authentication-Results field. 2067 Since different hosts did the two sets of authentication checks, the 2068 header fields cannot be consolidated in this example. 2070 This example illustrates more typical transmission of mail into 2071 example.com from a user on a dialup connection example.net. The user 2072 appears to be legitimate as he/she had a valid password allowing 2073 authentication at the border MTA using SMTP AUTH. The SPF and Sender 2074 ID tests failed since example.com has not granted example.net 2075 authority to relay mail on its behalf. However, the DKIM test passed 2076 because the sending user had a private key matching one of 2077 example.com's published public keys and used it to sign the message. 2079 C.6. Service Provided, Multi-Tiered Authentication Done 2081 A message that had authentication done at various stages, one of 2082 which was outside the receiving ADMD: 2084 Authentication-Results: example.com; 2085 dkim=pass reason="good signature" 2086 header.i=@mail-router.example.net; 2087 dkim=fail reason="bad signature" 2088 header.i=@newyork.example.com 2089 Received: from mail-router.example.net 2090 (mail-router.example.net [192.0.2.250]) 2091 by chicago.example.com (8.11.6/8.11.6) 2092 for 2093 with ESMTP id i7PK0sH7021929; 2094 Fri, Feb 15 2002 17:19:22 -0800 2095 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 2096 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 2097 h=From:Date:To:Message-Id:Subject:Authentication-Results; 2098 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 2099 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 2100 Authentication-Results: example.net; 2101 dkim=pass (good signature) header.i=@newyork.example.com 2102 Received: from smtp.newyork.example.com 2103 (smtp.newyork.example.com [192.0.2.220]) 2104 by mail-router.example.net (8.11.6/8.11.6) 2105 with ESMTP id g1G0r1kA003489; 2106 Fri, Feb 15 2002 17:19:07 -0800 2107 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; 2108 d=newyork.example.com; 2109 t=1188964191; c=simple/simple; 2110 h=From:Date:To:Message-Id:Subject; 2111 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 2112 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 2113 From: sender@newyork.example.com 2114 Date: Fri, Feb 15 2002 16:54:30 -0800 2115 To: meetings@example.net 2116 Message-Id: <12345.abc@newyork.example.com> 2117 Subject: here's a sample 2119 Example 6: Headers Reporting Results from Multiple MTAs in Different 2120 ADMDs 2122 In this example, we see multi-tiered authentication with an extended 2123 trust boundary. 2125 The message was sent from someone at example.com's New York office 2126 (newyork.example.com) to a mailing list managed at an intermediary. 2128 The message was signed at the origin using DKIM. 2130 The message was sent to a mailing list service provider called 2131 example.net, which is used by example.com. There, 2132 meetings@example.net is expanded to a long list of recipients, one of 2133 whom is at the Chicago office. In this example, we will assume that 2134 the trust boundary for chicago.example.com includes the mailing list 2135 server at example.net. 2137 The mailing list server there first authenticated the message and 2138 affixed an Authentication-Results header field indicating such using 2139 its DNS domain name for the authserv-id. It then altered the message 2140 by affixing some footer text to the body, including some 2141 administrivia such as unsubscription instructions. Finally, the 2142 mailing list server affixes a second DKIM signature and begins 2143 distribution of the message. 2145 The border MTA for chicago.example.com explicitly trusts results from 2146 mail-router.example.net, so that header field is not removed. It 2147 performs evaluation of both signatures and determines that the first 2148 (most recent) is a "pass" but, because of the aforementioned 2149 modifications, the second is a "fail". However, the first signature 2150 included the Authentication-Results header added at mail- 2151 router.example.net that validated the second signature. Thus, 2152 indirectly, it can be determined that the authentications claimed by 2153 both signatures are indeed valid. 2155 Note that two styles of presenting meta-data about the result are in 2156 use here. In one case, the "reason=" clause is present, which is 2157 intended for easy extraction by parsers; in the other case, the CFWS 2158 production of the ABNF is used to include such data as a header field 2159 comment. The latter can be harder for parsers to extract given the 2160 varied supported syntaxes of mail header fields. 2162 C.7. Comment-Heavy Example 2164 The formal syntax permits comments within the content in a number of 2165 places. For the sake of illustration, this example is also legal: 2167 Authentication-Results: foo.example.net (foobar) 1 (baz); 2168 dkim (Because I like it) / 1 (One yay) = (wait for it) fail 2169 policy (A dot can go here) . (like that) expired 2170 (this surprised me) = (as I wasn't expecting it) 1362471462 2172 Example 7: A Very Comment-Heavy but Perfectly Legal Example 2174 Appendix D. Operational Considerations about Message Authentication 2176 This protocol is predicated on the idea that authentication (and 2177 presumably in the future, reputation) work is typically done by 2178 border MTAs rather than MUAs or intermediate MTAs; the latter merely 2179 make use of the results determined by the former. Certainly this is 2180 not mandatory for participation in electronic mail or message 2181 authentication, but this protocol and its deployment to date are 2182 based on that model. The assumption satisfies several common ADMD 2183 requirements: 2185 1. Service operators prefer to resolve the handling of problem 2186 messages as close to the border of the ADMD as possible. This 2187 enables, for example, rejection of messages at the SMTP level 2188 rather than generating a DSN internally. Thus, doing any of the 2189 authentication or reputation work exclusively at the MUA or 2190 intermediate MTA renders this desire unattainable. 2192 2. Border MTAs are more likely to have direct access to external 2193 sources of authentication or reputation information since modern 2194 MUAs are more likely to be heavily firewalled. Thus, some MUAs 2195 might not even be able to complete the task of performing 2196 authentication or reputation evaluations without complex proxy 2197 configurations or similar burdens. 2199 3. MUAs rely upon the upstream MTAs within their trust boundaries to 2200 make correct (as much as is possible) evaluations about the 2201 message's envelope, header, and content. Thus, MUAs don't need 2202 to know how to do the work that upstream MTAs do; they only need 2203 the results of that work. 2205 4. Evaluations about the quality of a message, from simple token 2206 matching (e.g., a list of preferred DNS domains) to cryptanalysis 2207 (e.g., public/private key work), are at least a little bit 2208 expensive and thus need to be minimized. To that end, performing 2209 those tests at the border MTA is far preferred to doing that work 2210 at each MUA that handles a message. If an ADMD's environment 2211 adheres to common messaging protocols, a reputation query or an 2212 authentication check performed by a border MTA would return the 2213 same result as the same query performed by an MUA. By contrast, 2214 in an environment where the MUA does the work, a message arriving 2215 for multiple recipients would thus cause authentication or 2216 reputation evaluation to be done more than once for the same 2217 message (i.e., at each MUA), causing needless amplification of 2218 resource use and creating a possible denial-of-service attack 2219 vector. 2221 5. Minimizing change is good. As new authentication and reputation 2222 methods emerge, the list of methods supported by this header 2223 field would presumably be extended. If MUAs simply consume the 2224 contents of this header field rather than actually attempt to do 2225 authentication and/or reputation work, then MUAs only need to 2226 learn to parse this header field once; emergence of new methods 2227 requires only a configuration change at the MUAs and software 2228 changes at the MTAs (which are presumably fewer in number). When 2229 choosing to implement these functions in MTAs vs. MUAs, the 2230 issues of individual flexibility, infrastructure inertia, and 2231 scale of effort must be considered. It is typically easier to 2232 change a single MUA than an MTA because the modification affects 2233 fewer users and can be pursued with less care. However, changing 2234 many MUAs is more effort than changing a smaller number of MTAs. 2236 6. For decisions affecting message delivery and display, assessment 2237 based on authentication and reputation is best performed close to 2238 the time of message transit, as a message makes its journey 2239 toward a user's inbox, not afterwards. DKIM keys and IP address 2240 reputations, etc., can change over time or even become invalid, 2241 and users can take a long time to read a message once delivered. 2242 The value of this work thus degrades, perhaps quickly, once the 2243 delivery process has completed. This seriously diminishes the 2244 value of this work when done other than at MTAs. 2246 Many operational choices are possible within an ADMD, including the 2247 venue for performing authentication and/or reputation assessment. 2248 The current specification does not dictate any of those choices. 2249 Rather, it facilitates those cases in which information produced by 2250 one stage of analysis needs to be transported with the message to the 2251 next stage. 2253 Appendix E. Change History 2255 E.1. RFC7001 to -00 2257 o Remove "Changes since RFC5451" section; add this "Change History" 2258 section. 2260 o Restore XML to previous format. (No visible changes). 2262 o Reset "Acknowledgments". 2264 o Add "To-Do" section. 2266 E.2. -00 to -01 2268 o Apply RFC7410. 2270 o Update all the RFC4408 references to RFC7208. 2272 o Add section explaining "property" values. (Errata #4201) 2274 o Remove "To-Do" section. 2276 E.3. -01 to -02 2278 o Consolidate new sections. 2280 E.4. -02 to -03 2282 o Move the DKIM exception text down to where the DKIM results are 2283 defined, and add a forward reference to them. 2285 o More detail about registry creation and previous augmentations. 2287 o Add text explaining each of the method-ptype-property tuples 2288 registered by this document. 2290 o Change the meaning of the "Defined" column of the methods registry 2291 to be the place where each entry was created and described; it is 2292 expected that this will then refer to the method's defining 2293 document. Provide IANA with corresponding update instructions. 2295 o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG]. 2297 E.5. -03 to -04 2299 o Add specific update instructions for the "dkim"/"header"/"b" entry 2300 in IANA Considerations. 2302 o Add description of values that can be extracted from SMTP AUTH 2303 sessions and an example. 2305 o Much more complete descriptions of reporting DomainKeys results. 2307 o Minor editorial adjustments. 2309 o Fix up "smime" entries. 2311 o Update current definitions for the Email Authentication Property 2312 Types registry to point to this document. 2314 o Rework the Email Authentication Result Names registry. 2316 o Add more detail about Sender ID. 2318 o Mark all ADSP and DomainKeys entries as deprecated since their 2319 defining documents are as well. 2321 o Add references: [RFC6008]. 2323 E.6. -04 to -05 2325 o Fix typos. 2327 o Rework some text around ignoring unknown ptypes. 2329 o Completely describe the ptypes registry. 2331 o EHLO is mapped to HELO for SPF. 2333 o RFC7208 uses all-lowercase result strings now, so adjust prose 2334 accordingly. 2336 o Move the RFC6008 reference up to where the DKIM reporting is 2337 described. 2339 E.7. -05 to -06 2341 WGLC feedback: 2343 o Update list of supported methods, and mention the registries 2344 immediately below there. 2346 o Mention that when a local-part is removed, the "@" goes with it. 2348 o Refer to RFC7328 in the "iprev" definition. 2350 o Correction to "smime-part" prose. 2352 o Examples that use SMTP AUTH now claim "with ESMTPA" in the 2353 Received fields. 2355 E.8. -06 to -07 2357 o Wording around the S/MIME results. 2359 E.9. -07 to -08 2361 o Clarifications in IANA Considerations. 2363 Author's Address 2365 Murray S. Kucherawy 2366 270 Upland Drive 2367 San Francisco, CA 94127 2368 US 2370 EMail: superuser@gmail.com