idnits 2.17.1 draft-ietf-appsawg-rfc7001bis-03.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 (March 9, 2015) is 3336 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 490, but not defined == Missing Reference: 'RFC7208' is mentioned on line 785, 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 March 9, 2015 4 Obsoletes: 7001, 7410 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 10, 2015 9 Message Header Field for Indicating Message Authentication Status 10 draft-ietf-appsawg-rfc7001bis-03 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 September 10, 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 . . . . . . . . . . . . . . . . . . . . . . 5 58 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 59 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 7 62 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 7 63 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7 64 1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 15 74 2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16 75 2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 17 76 2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 18 77 2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 19 78 2.7.5. Other Registered Codes . . . . . . . . . . . . . . . . 20 79 2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 20 80 2.7.7. Extension Result Codes . . . . . . . . . . . . . . . . 21 81 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 21 82 4. Adding the Header Field to a Message . . . . . . . . . . . . . 22 83 4.1. Header Field Position and Interpretation . . . . . . . . . 23 84 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 25 85 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 25 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 6.1. The Authentication-Results Header Field . . . . . . . . . 26 88 6.2. "Email Authentication Methods" Registry Description . . . 27 89 6.3. "Email Authentication Methods" Registry Update . . . . . . 28 90 6.4. "Email Authentication Result Names" Registry . . . . . . . 28 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 29 93 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 30 94 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 31 95 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 31 96 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 31 97 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 31 98 7.7. Attacks against Authentication Methods . . . . . . . . . . 32 99 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 32 100 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 32 101 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 32 102 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 33 106 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 107 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 36 108 Appendix C. Authentication-Results Examples . . . . . . . . . . . 36 109 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 36 110 C.2. Nearly Trivial Case; Service Provided, but No 111 Authentication Done . . . . . . . . . . . . . . . . . . . 37 112 C.3. Service Provided, Authentication Done . . . . . . . . . . 38 113 C.4. Service Provided, Several Authentications Done, Single 114 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 115 C.5. Service Provided, Several Authentications Done, 116 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 40 117 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 42 118 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 43 119 Appendix D. Operational Considerations about Message 120 Authentication . . . . . . . . . . . . . . . . . . . 44 121 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 45 122 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 45 123 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 46 124 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 46 125 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 46 127 1. Introduction 129 This document describes a header field called Authentication-Results 130 for electronic mail messages that presents the results of a message 131 authentication effort in a machine-readable format. The intent of 132 the header field is to create a place to collect such data when 133 message authentication mechanisms are in use so that a Mail User 134 Agent (MUA) and downstream filters can make filtering decisions 135 and/or provide a recommendation to the user as to the validity of the 136 message's origin and possibly the safety and integrity of its 137 content. 139 This document revises the original definition found in [RFC5451] 140 based upon various authentication protocols in current use and 141 incorporates errata logged since the publication of the original 142 specification. 144 End users are not expected to be direct consumers of this header 145 field. This header field is intended for consumption by programs 146 that will then use such data or render it in a human-usable form. 148 This document specifies the format of this header field and discusses 149 the implications of its presence or absence. However, it does not 150 discuss how the data contained in the header field ought to be used, 151 such as what filtering decisions are appropriate or how an MUA might 152 render those results, as these are local policy and/or user interface 153 design questions that are not appropriate for this document. 155 At the time of publication of this document, the following are 156 published, domain-level email authentication methods in common use: 158 o Author Domain Signing Practices ([ADSP]) 160 o SMTP Service Extension for Authentication ([AUTH]) 162 o DomainKeys Identified Mail Signatures ([DKIM]) 164 o Sender Policy Framework ([SPF]) 166 o Vouch By Reference ([VBR]) 168 o reverse IP address name validation ("iprev", defined in Section 3) 170 In addition, the following are non-standard methods recognized by 171 this specification that are no longer common: 173 o DomainKeys ([DOMAINKEYS]) (Historic) 174 o Sender ID ([SENDERID]) (Experimental) 176 This specification is not intended to be restricted to domain-based 177 authentication schemes, but the existing schemes in that family have 178 proven to be a good starting point for implementations. The goal is 179 to give current and future authentication schemes a common framework 180 within which to deliver their results to downstream agents and 181 discourage the creation of unique header fields for each. 183 Although SPF defined a header field called "Received-SPF" and the 184 historic DomainKeys defined one called "DomainKey-Status" for this 185 purpose, those header fields are specific to the conveyance of their 186 respective results only and thus are insufficient to satisfy the 187 requirements enumerated below. In addition, many SPF implementations 188 have adopted the header field specified here at least as an option, 189 and DomainKeys has been obsoleted by DKIM. 191 1.1. Purpose 193 The header field defined in this document is expected to serve 194 several purposes: 196 1. Convey the results of various message authentication checks, 197 which are applied by upstream filters and Mail Transfer Agents 198 (MTAs) and then passed to MUAs and downstream filters within the 199 same "trust domain". Such agents might wish to render those 200 results to end users or to use those data to apply more or less 201 stringent content checks based on authentication results; 203 2. Provide a common location within a message for this data; 205 3. Create an extensible framework for reporting new authentication 206 methods as they emerge. 208 In particular, the mere presence of this header field does not mean 209 its contents are valid. Rather, the header field is reporting 210 assertions made by one or more authentication schemes (supposedly) 211 applied somewhere upstream. For an MUA or downstream filter to treat 212 the assertions as actually valid, there must be an assessment of the 213 trust relationship among such agents, the validating MTA, and the 214 mechanism for conveying the information. 216 1.2. Trust Boundary 218 This document makes several references to the "trust boundary" of an 219 administrative management domain (ADMD). Given the diversity among 220 existing mail environments, a precise definition of this term isn't 221 possible. 223 Simply put, a transfer from the producer of the header field to the 224 consumer must occur within a context that permits the consumer to 225 treat assertions by the producer as being reliable and accurate 226 (trustworthy). How this trust is obtained is outside the scope of 227 this document. It is entirely a local matter. 229 Thus, this document defines a "trust boundary" as the delineation 230 between "external" and "internal" entities. Services that are 231 internal -- within the trust boundary -- are provided by the ADMD's 232 infrastructure for its users. Those that are external are outside of 233 the authority of the ADMD. By this definition, hosts that are within 234 a trust boundary are subject to the ADMD's authority and policies, 235 independent of their physical placement or their physical operation. 236 For example, a host within a trust boundary might actually be 237 operated by a remote service provider and reside physically within 238 its data center. 240 It is possible for a message to be evaluated inside a trust boundary 241 but then depart and re-enter the trust boundary. An example might be 242 a forwarded message such as a message/rfc822 attachment (see 243 Multipurpose Internet Mail Extensions [MIME]) or one that is part of 244 a multipart/digest. The details reported by this field cannot be 245 trusted in that case. Thus, this field found within one of those 246 media types is typically ignored. 248 1.3. Processing Scope 250 The content of this header field is meant to convey to message 251 consumers that authentication work on the message was already done 252 within its trust boundary, and those results are being presented. It 253 is not intended to provide message parameters to consumers so that 254 they can perform authentication protocols on their own. 256 1.4. Requirements 258 This document establishes no new requirements on existing protocols 259 or servers. 261 In particular, this document establishes no requirement on MTAs to 262 reject or filter arriving messages that do not pass authentication 263 checks. The data conveyed by the specified header field's contents 264 are for the information of MUAs and filters and are to be used at 265 their discretion. 267 1.5. Definitions 269 This section defines various terms used throughout this document. 271 1.5.1. Key Words 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [KEYWORDS]. 277 1.5.2. Security 279 "Guidelines for Writing RFC Text on Security Considerations" 280 ([SECURITY]) discusses authentication and authorization and the 281 conflation of the two concepts. The use of those terms within the 282 context of recent message security work has given rise to slightly 283 different definitions, and this document reflects those current 284 usages, as follows: 286 o "Authorization" is the establishment of permission to use a 287 resource or represent an identity. In this context, authorization 288 indicates that a message from a particular ADMD arrived via a 289 route the ADMD has explicitly approved. 291 o "Authentication" is the assertion of validity of a piece of data 292 about a message (such as the sender's identity) or the message in 293 its entirety. 295 As examples: SPF and Sender ID are authorization mechanisms in that 296 they express a result that shows whether or not the ADMD that 297 apparently sent the message has explicitly authorized the connecting 298 Simple Mail Transfer Protocol ([SMTP]) client to relay messages on 299 its behalf, but they do not actually validate any other property of 300 the message itself. By contrast, DKIM is agnostic as to the routing 301 of a message but uses cryptographic signatures to authenticate 302 agents, assign (some) responsibility for the message (which implies 303 authorization), and ensure that the listed portions of the message 304 were not modified in transit. Since the signatures are not tied to 305 SMTP connections, they can be added by either the ADMD of origin, 306 intermediate ADMDs (such as a mailing list server), other handling 307 agents, or any combination. 309 Rather than create a separate header field for each class of 310 solution, this proposal groups them both into a single header field. 312 1.5.3. Email Architecture 314 o A "border MTA" is an MTA that acts as a gateway between the 315 general Internet and the users within an organizational boundary. 316 (See also Section 1.2.) 318 o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that 319 actually enacts delivery of a message to a user's inbox or other 320 final delivery. 322 o An "intermediate MTA" is any MTA that is not a delivery MTA and is 323 also not the first MTA to handle the message. 325 The following diagram illustrates the flow of mail among these 326 defined components. See Internet Mail Architecture [EMAIL-ARCH] for 327 further discussion on general email system architecture, which 328 includes detailed descriptions of these components, and Appendix D of 329 this document for discussion about the common aspects of email 330 authentication in current environments. 332 +-----+ +-----+ +------------+ 333 | MUA |-->| MSA |-->| Border MTA | 334 +-----+ +-----+ +------------+ 335 | 336 | 337 V 338 +----------+ 339 | Internet | 340 +----------+ 341 | 342 | 343 V 344 +-----+ +-----+ +------------------+ +------------+ 345 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 346 +-----+ +-----+ +------------------+ +------------+ 348 Generally, it is assumed that the work of applying message 349 authentication schemes takes place at a border MTA or a delivery MTA. 350 This specification is written with that assumption in mind. However, 351 there are some sites at which the entire mail infrastructure consists 352 of a single host. In such cases, such terms as "border MTA" and 353 "delivery MTA" might well apply to the same machine or even the very 354 same agent. It is also possible that some message authentication 355 tests could take place on an intermediate MTA. Although this 356 document doesn't specifically describe such cases, they are not meant 357 to be excluded. 359 1.5.4. Other Terms 361 In this document, the term "producer" refers to any component that 362 adds this header field to messages it is handling, and "consumer" 363 refers to any component that identifies, extracts, and parses the 364 header field to use as part of a handling decision. 366 1.6. Trust Environment 368 This header field permits one or more message validation mechanisms 369 to communicate output to one or more separate assessment mechanisms. 370 These mechanisms operate within a unified trust boundary that defines 371 an Administrative Management Domain (ADMD). An ADMD contains one or 372 more entities that perform validation and generate the header field 373 and one or more that consume it for some type of assessment. The 374 field often contains no integrity or validation mechanism of its own, 375 so its presence must be trusted implicitly. Hence, valid use of the 376 header field requires removing any occurrences of it that are present 377 when the message enters the ADMD. This ensures that later 378 occurrences have been added within the trust boundary of the ADMD. 380 The authserv-id token defined in Section 2.2 can be used to reference 381 an entire ADMD or a specific validation engine within an ADMD. 382 Although the labeling scheme is left as an operational choice, some 383 guidance for selecting a token is provided in later sections of this 384 document. 386 2. Definition and Format of the Header Field 388 This section gives a general overview of the format of the header 389 field being defined and then provides more formal specification. 391 2.1. General Description 393 The header field specified here is called Authentication-Results. It 394 is a Structured Header Field as defined in Internet Message Format 395 ([MAIL]), and thus all of the related definitions in that document 396 apply. 398 This header field is added at the top of the message as it transits 399 MTAs that do authentication checks, so some idea of how far away the 400 checks were done can be inferred. It is therefore considered to be a 401 trace field as defined in [MAIL], and thus all of the related 402 definitions in that document apply. 404 The value of the header field (after removing comments) consists of 405 an authentication identifier, an optional version, and then a series 406 of statements and supporting data. The statements are of the form 407 "method=result" and indicate which authentication method(s) were 408 applied and their respective results. For each such statement, the 409 supporting data can include a "reason" string and one or more 410 "property=value" statements indicating which message properties were 411 evaluated to reach that conclusion. 413 The header field can appear more than once in a single message, more 414 than one result can be represented in a single header field, or a 415 combination of these can be applied. 417 2.2. Formal Definition 419 Formally, the header field is specified as follows using Augmented 420 Backus-Naur Form ([ABNF]): 422 authres-header = "Authentication-Results:" [CFWS] authserv-id 423 [ CFWS authres-version ] 424 ( no-result / 1*resinfo ) [CFWS] CRLF 426 authserv-id = value 427 ; see below for a description of this element 429 authres-version = 1*DIGIT [CFWS] 430 ; indicates which version of this specification is in use; 431 ; this specification is version "1", and the absence of a 432 ; version implies this version of the specification 434 no-result = [CFWS] ";" [CFWS] "none" 435 ; the special case of "none" is used to indicate that no 436 ; message authentication was performed 438 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 439 *( CFWS propspec ) 441 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 442 ; indicates which authentication method was evaluated 443 ; and what its output was 445 reasonspec = "reason" [CFWS] "=" [CFWS] value 446 ; a free-form comment on the reason the given result 447 ; was returned 449 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 450 ; an indication of which properties of the message 451 ; were evaluated by the authentication scheme being 452 ; applied to yield the reported result 454 method = Keyword [ [CFWS] "/" [CFWS] method-version ] 455 ; a method indicates which method's result is 456 ; represented by "result", and is one of the methods 457 ; explicitly defined as valid in this document 458 ; or is an extension method as defined below 460 method-version = 1*DIGIT [CFWS] 461 ; indicates which version of the method specification is 462 ; in use, corresponding to the matching entry in the IANA 463 ; "Email Authentication Methods" registry; a value of "1" 464 ; is assumed if this version string is absent 466 result = Keyword 467 ; indicates the results of the attempt to authenticate 468 ; the message; see below for details 470 ptype = Keyword 471 ; indicates whether the property being evaluated was 472 ; a parameter to an [SMTP] command, was a value taken 473 ; from a message header field, was some property of 474 ; the message body, or was some other property evaluated by 475 ; the receiving MTA; expected to be one of the "property 476 ; types" explicitly defined as valid, or an extension 477 ; ptype, as defined below 479 property = special-smtp-verb / Keyword 480 ; indicates more specifically than "ptype" what the 481 ; source of the evaluated property is; the exact meaning 482 ; is specific to the method whose result is being reported 483 ; and is defined more clearly below 485 special-smtp-verb = "mailfrom" / "rcptto" 486 ; special cases of [SMTP] commands that are made up 487 ; of multiple words 489 pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) 490 [CFWS] 491 ; the value extracted from the message property defined 492 ; by the "ptype.property" construction 494 "local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is 495 defined in Section 3.2.2 of [MAIL]. 497 "Keyword" is defined in Section 4.1.2 of [SMTP]. 499 The "value" is as defined in Section 5.1 of [MIME]. 501 The "domain-name" is as defined in Section 3.5 of [DKIM]. 503 The "Keyword" used in "result" above is further constrained by the 504 necessity of being enumerated in Section 2.7. 506 See Section 2.5 for a description of the authserv-id element. 508 If the value portion of a "pvalue" construction identifies something 509 intended to be an e-mail identity, then it MUST use the right hand 510 portion of that ABNF definition. 512 The list of commands eligible for use with the "smtp" ptype can be 513 found in Section 4.1 of [SMTP]. 515 The "propspec" may be omitted if, for example, the method was unable 516 to extract any properties to do its evaluation yet has a result to 517 report. 519 Where an SMTP command name is being reported as a "property", the 520 agent generating the header field represents that command by 521 converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" 522 becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.). 524 A "ptype" value of "policy" indicates a policy decision about the 525 message not specific to a property of the message that could be 526 extracted. See Section 2.4 for details. 528 Examples of complete messages using this header field can be found in 529 Appendix C. 531 2.3. Property Types (ptypes) and Properties 533 The "ptype" in the ABNF above indicates the general type of property 534 being described by the result being reported, upon which the reported 535 result was based. Coupled with the "property", which is more 536 specific, they inidcate from which particular part of the message the 537 reported data were extracted. 539 Combinations of ptypes and properties are registered and described in 540 the "Email Authentication Methods" registry, coupled with the 541 authentication methods with which they are used. This is further 542 described in Section 6. 544 Legal values of "ptype" are as defined in the IANA "Email 545 Authentication Property Types" registry, created by 546 [PTYPES-REGISTRY]. The initial values and what they typically 547 indicate are as follows, copied from [RFC7001]: 549 body: Information that was extracted from the body of the message. 550 This might be an arbitrary string of bytes, a hash of a string of 551 bytes, a Uniform Resource Identifier, or some other content of 552 interest. The "property" is an indication of where within the 553 message body the extracted content was found, and can indicate an 554 offset, identify a MIME part, or 556 header: Indicates information that was extracted from the header of 557 the message. This might be the value of a header field or some 558 portion of a header field. The "property" gives a more precise 559 indication of the place in the header from which the extraction 560 took place. 562 policy: A local policy mechanism was applied that augments or 563 overrides the result returned by the authentication mechanism. 564 (See Section 2.4.) 566 smtp: Indicates information that was extracted from an SMTP command 567 that was used to relay the message. The "property" indicates 568 which SMTP command included the extracted content as a parameter. 570 When a consumer of this header field encounters a "ptype" that it 571 does not understand, it ignores the result reported with that 572 "ptype". 574 Entries in the "Email Authentication Methods" registry can define 575 properties that deviate from these definitions when appropriate. 576 Such deviations need to be clear in the registry and/or in the 577 defining document. See Section 2.7.1 for an example. 579 2.4. The "policy" ptype 581 A special ptype value of "policy" is also defined. This ptype is 582 provided to indicate that some local policy mechanism was applied 583 that augments or even replaces (i.e., overrides) the result returned 584 by the authentication mechanism. The property and value in this case 585 identify the local policy that was applied and the result it 586 returned. 588 For example, a DKIM signature is not required to include the Subject 589 header field in the set of fields that are signed. An ADMD receiving 590 such a message might decide that such a signature is unacceptable, 591 even if it passes, because the content of the Subject header field 592 could be altered post-signing without invalidating the signature. 593 Such an ADMD could replace the DKIM "pass" result with a "policy" 594 result and then also include the following in the corresponding 595 Authentication-Result field: 597 ... dkim=fail policy.dkim-rules=unsigned-subject ... 599 In this case, the property is "dkim-rules", indicating some local 600 check by that name took place and that check returned a result of 601 "unsigned-subject". These are arbitrary names selected by (and 602 presumably used within) the ADMD making use of them, so they are not 603 normally registered with IANA or otherwise specified apart from 604 setting syntax restrictions that allow for easy parsing within the 605 rest of the header field. 607 This ptype existed in the original specification for this header 608 field, but without a complete description or example of intended use. 609 As a result, it has not seen any practical use to date that matches 610 its intended purpose. These added details are provided to guide 611 implementers toward proper use. 613 2.5. Authentication Identifier Field 615 Every Authentication-Results header field has an authentication 616 service identifier field (authserv-id above). Specifically, this is 617 any string intended to identify the authentication service within the 618 ADMD that conducted authentication checks on the message. This 619 identifier is intended to be machine-readable and not necessarily 620 meaningful to users. 622 Since agents consuming this field will use this identifier to 623 determine whether its contents are of interest (and are safe to use), 624 the uniqueness of the identifier MUST be guaranteed by the ADMD that 625 generates it and MUST pertain to that ADMD. MUAs or downstream 626 filters SHOULD use this identifier to determine whether or not the 627 data contained in an Authentication-Results header field ought to be 628 used or ignored. 630 For simplicity and scalability, the authentication service identifier 631 SHOULD be a common token used throughout the ADMD. Common practice 632 is to use the DNS domain name used by or within that ADMD, sometimes 633 called the "organizational domain", but this is not strictly 634 necessary. 636 For tracing and debugging purposes, the authentication identifier can 637 instead be the specific hostname of the MTA performing the 638 authentication check whose result is being reported. Moreover, some 639 implementations define a substructure to the identifier; these are 640 outside of the scope of this specification. 642 Note, however, that using a local, relative identifier like a flat 643 hostname, rather than a hierarchical and globally unique ADMD 644 identifier like a DNS domain name, makes configuration more difficult 645 for large sites. The hierarchical identifier permits aggregating 646 related, trusted systems together under a single, parent identifier, 647 which in turn permits assessing the trust relationship with a single 648 reference. The alternative is a flat namespace requiring 649 individually listing each trusted system. Since consumers will use 650 the identifier to determine whether to use the contents of the header 651 field: 653 o Changes to the identifier impose a large, centralized 654 administrative burden. 656 o Ongoing administrative changes require constantly updating this 657 centralized table, making it difficult to ensure that an MUA or 658 downstream filter will have access to accurate information for 659 assessing the usability of the header field's content. In 660 particular, consumers of the header field will need to know not 661 only the current identifier(s) in use but previous ones as well to 662 account for delivery latency or later re-assessment of the header 663 field's contents. 665 Examples of valid authentication identifiers are "example.com", 666 "mail.example.org", "ms1.newyork.example.com", and "example-auth". 668 2.6. Version Tokens 670 The grammar above provides for the optional inclusion of versions on 671 both the header field itself (attached to the authserv-id token) and 672 on each of the methods being reported. The method version refers to 673 the method itself, which is specified in the documents describing 674 those methods, while the authserv-id version refers to this document 675 and thus the syntax of this header field. 677 The purpose of including these is to avoid misinterpretation of the 678 results. That is, if a parser finds a version after an authserv-id 679 that it does not explicitly know, it can immediately discontinue 680 trying to parse since what follows might not be in an expected 681 format. For a method version, the parser SHOULD ignore a method 682 result if the version is not supported in case the semantics of the 683 result have a different meaning than what is expected. For example, 684 if a hypothetical DKIM version 2 yielded a "pass" result for 685 different reasons than version 1 does, a consumer of this field might 686 not want to use the altered semantics. Allowing versions in the 687 syntax is a way to indicate this and let the consumer of the header 688 field decide. 690 2.7. Defined Methods and Result Values 692 Each individual authentication method returns one of a set of 693 specific result values. The subsections below provide references to 694 the documents defining the authentication methods specifically 695 supported by this document, and their corresponding result values. 696 Verifiers SHOULD use these values as described below. New methods 697 not specified in this document, but intended to be supported by the 698 header field defined here, MUST include a similar result table either 699 in their defining documents or in supplementary ones. 701 2.7.1. DKIM and DomainKeys 703 DKIM is represented by the "dkim" method and is defined in [DKIM]. 704 DomainKeys is defined in [DOMAINKEYS] and is represented by the 705 "domainkeys" method. 707 A signature is "acceptable to the ADMD" if it passes local policy 708 checks (or there are no specific local policy checks). For example, 709 an ADMD policy might require that the signature(s) on the message be 710 added using the DNS domain present in the From header field of the 711 message, thus making third-party signatures unacceptable even if they 712 verify. 714 Both DKIM and DomainKeys use the same result set, as follows: 716 none: The message was not signed. 718 pass: The message was signed, the signature or signatures were 719 acceptable to the ADMD, and the signature(s) passed verification 720 tests. 722 fail: The message was signed and the signature or signatures were 723 acceptable to the ADMD, but they failed the verification test(s). 725 policy: The message was signed, but some aspect of the signature or 726 signatures was not acceptable to the ADMD. 728 neutral: The message was signed, but the signature or signatures 729 contained syntax errors or were not otherwise able to be 730 processed. This result is also used for other failures not 731 covered elsewhere in this list. 733 temperror: The message could not be verified due to some error that 734 is likely transient in nature, such as a temporary inability to 735 retrieve a public key. A later attempt may produce a final 736 result. 738 permerror: The message could not be verified due to some error that 739 is unrecoverable, such as a required header field being absent. A 740 later attempt is unlikely to produce a final result. 742 DKIM results are reported using a ptype of "header". The property, 743 however, represents one of the tags found in the DKIM-Signature 744 header field rather than a distinct header field. For example, the 745 ptype-property combination "header.d" refers to the content of the 746 "d" (signing domain) tag from within the signature header field, and 747 not a distinct header field called "d". 749 DomainKeys results are reported using the "header" ptype, but a 750 mixture of DKIM-style values (e.g., "d" represents the value of the 751 "d" tag from the DomainKey-Signature header field) and typical uses 752 (e.g., "from" and "sender", containing those header fields' values). 753 In the latter case, [MAIL]-style comments are removed, leaving only 754 the address. 756 [DKIM] advises that if a message fails verification, it is to be 757 treated as an unsigned message. A report of "fail" here permits the 758 receiver of the report to decide how to handle the failure. A report 759 of "neutral" or "none" preempts that choice, ensuring the message 760 will be treated as if it had not been signed. 762 2.7.2. SPF and Sender ID 764 SPF and Sender ID use the "spf" and "sender-id" method names, 765 respectively. The result values for SPF are defined in Section 2.6 766 of [SPF], and those definitions are included here by reference: 768 +-----------+--------------------------------+ 769 | Code | Meaning | 770 +-----------+--------------------------------+ 771 | none | [RFC7208], Section 2.6.1 | 772 +-----------+--------------------------------+ 773 | pass | [RFC7208], Section 2.6.3 | 774 +-----------+--------------------------------+ 775 | fail | [RFC7208], Section 2.6.4 | 776 +-----------+--------------------------------+ 777 | softfail | [RFC7208], Section 2.6.5 | 778 +-----------+--------------------------------+ 779 | policy | [this RFC], Section 2.4 | 780 +-----------+--------------------------------+ 781 | neutral | [RFC7208], Section 2.6.2 | 782 +-----------+--------------------------------+ 783 | temperror | [RFC7208], Section 2.6.6 | 784 +-----------+--------------------------------+ 785 | permerror | [RFC7208], Section 2.6.7 | 786 +-----------+--------------------------------+ 788 These result codes are used in the context of this specification to 789 reflect the result returned by the component conducting SPF 790 evaluation. 792 Similarly, the results for Sender ID are listed and described in 793 Section 4.2 of [SENDERID], which in turn uses the SPF definitions 794 that now appear in [SPF]. 796 Note that both of those documents specify result codes that use mixed 797 case, but they are typically used all lowercase in this context. 799 For SPF, the ptype used is "smtp", and the property is any of 800 "mailfrom", "helo", and "ehlo", since those values are the ones SPF 801 can evaluate. For Sender ID, the ptype used is "header", and the 802 property will be the name of the header field from which the 803 Purported Responsible Address (see [PRA]) was extracted. 805 In both cases, an additional result of "policy" is defined, which 806 means the client was authorized to inject or relay mail on behalf of 807 the sender's DNS domain according to the authentication method's 808 algorithm, but local policy dictates that the result is unacceptable. 809 For example, "policy" might be used if SPF returns a "pass" result, 810 but a local policy check matches the sending DNS domain to one found 811 in an explicit list of unacceptable DNS domains (e.g., spammers). 813 If the retrieved sender policies used to evaluate SPF and Sender ID 814 do not contain explicit provisions for authenticating the local-part 815 (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported 816 along with results for these mechanisms SHOULD NOT include the local- 817 part. 819 2.7.3. "iprev" 821 The result values used by the "iprev" method, defined in Section 3, 822 are as follows: 824 pass: The DNS evaluation succeeded, i.e., the "reverse" and 825 "forward" lookup results were returned and were in agreement. 827 fail: The DNS evaluation failed. In particular, the "reverse" and 828 "forward" lookups each produced results, but they were not in 829 agreement, or the "forward" query completed but produced no 830 result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an 831 RCODE of 0 (NOERROR) in a reply containing no answers, was 832 returned. 834 temperror: The DNS evaluation could not be completed due to some 835 error that is likely transient in nature, such as a temporary DNS 836 error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or 837 other error condition resulted. A later attempt may produce a 838 final result. 840 permerror: The DNS evaluation could not be completed because no PTR 841 data are published for the connecting IP address, e.g., a DNS 842 RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) 843 in a reply containing no answers, was returned. This prevented 844 completion of the evaluation. A later attempt is unlikely to 845 produce a final result. 847 There is no "none" for this method since any TCP connection 848 delivering email has an IP address associated with it, so some kind 849 of evaluation will always be possible. 851 The result is reported using a ptype of "policy" (as this is not part 852 of any established protocol) and a property of "iprev". 854 For discussion of the format of DNS replies, see "Domain Names - 855 Implementation and Specification" ([DNS]). 857 2.7.4. SMTP AUTH 859 SMTP AUTH (defined in [AUTH]) is represented by the "auth" method, 860 and its result values are as follows: 862 none: SMTP authentication was not attempted. 864 pass: The SMTP client authenticated to the server reporting the 865 result using the protocol described in [AUTH]. 867 fail: The SMTP client attempted to authenticate to the server using 868 the protocol described in [AUTH] but was not successful, yet 869 continued to send the message about which a result is being 870 reported. 872 temperror: The SMTP client attempted to authenticate using the 873 protocol described in [AUTH] but was not able to complete the 874 attempt due to some error that is likely transient in nature, such 875 as a temporary directory service lookup error. A later attempt 876 may produce a final result. 878 permerror: The SMTP client attempted to authenticate using the 879 protocol described in [AUTH] but was not able to complete the 880 attempt due to some error that is likely not transient in nature, 881 such as a permanent directory service lookup error. A later 882 attempt is not likely to produce a final result. 884 The result of AUTH is reported using a ptype of "smtp" and a property 885 of "mailfrom", and the reported value is the value of the AUTH 886 parameter to that command. 888 An agent making use of the data provided by this header field SHOULD 889 consider "fail" and "temperror" to be synonymous in terms of message 890 authentication, i.e., the client did not authenticate in either case. 892 2.7.5. Other Registered Codes 894 Result codes were also registered in other RFCs as follows: 896 o Vouch By Reference (in [AR-VBR], represented by "vbr"); 898 o Authorized Third-Party Signatures (in [ATPS], represented by 899 "dkim-atps"); 901 o Author Domain Signing Practices (in [ADSP], represented by "dkim- 902 adsp"); 904 o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs"); 906 o S/MIME (in [SMIME-REG], represented by "smime"). 908 2.7.6. Extension Methods 910 Additional authentication method identifiers (extension methods) may 911 be defined in the future by later revisions or extensions to this 912 specification. These method identifiers are registered with the 913 Internet Assigned Numbers Authority (IANA) and, preferably, published 914 in an RFC. See Section 6 for further details. 916 Extension methods can be defined for the following reasons: 918 1. To allow additional information from new authentication systems 919 to be communicated to MUAs or downstream filters. The names of 920 such identifiers ought to reflect the name of the method being 921 defined but ought not be needlessly long. 923 2. To allow the creation of "sub-identifiers" that indicate 924 different levels of authentication and differentiate between 925 their relative strengths, e.g., "auth1-weak" and "auth1-strong". 927 Authentication method implementers are encouraged to provide adequate 928 information, via message header field comments if necessary, to allow 929 an MUA developer to understand or relay ancillary details of 930 authentication results. For example, if it might be of interest to 931 relay what data was used to perform an evaluation, such information 932 could be relayed as a comment in the header field, such as: 934 Authentication-Results: example.com; 935 foo=pass bar.baz=blob (2 of 3 tests OK) 937 Experimental method identifiers MUST only be used within ADMDs that 938 have explicitly consented to use them. These method identifiers and 939 the parameters associated with them are not documented in RFCs. 941 Therefore, they are subject to change at any time and not suitable 942 for production use. Any MTA, MUA, or downstream filter intended for 943 production use SHOULD ignore or delete any Authentication-Results 944 header field that includes an experimental (unknown) method 945 identifier. 947 2.7.7. Extension Result Codes 949 Additional result codes (extension results) might be defined in the 950 future by later revisions or extensions to this specification. 951 Result codes MUST be registered with the Internet Assigned Numbers 952 Authority (IANA) and preferably published in an RFC. See Section 6 953 for further details. 955 Experimental results MUST only be used within ADMDs that have 956 explicitly consented to use them. These results and the parameters 957 associated with them are not formally documented. Therefore, they 958 are subject to change at any time and not suitable for production 959 use. Any MTA, MUA, or downstream filter intended for production use 960 SHOULD ignore or delete any Authentication-Results header field that 961 includes an extension result. 963 3. The "iprev" Authentication Method 965 This section defines an additional authentication method called 966 "iprev". 968 "iprev" is an attempt to verify that a client appears to be valid 969 based on some DNS queries, which is to say that the IP address is 970 explicitly associated with a domain name. Upon receiving a session 971 initiation of some kind from a client, the IP address of the client 972 peer is queried for matching names (i.e., a number-to-name 973 translation, also known as a "reverse lookup" or a "PTR" record 974 query). Once that result is acquired, a lookup of each of the names 975 (i.e., a name-to-number translation, or an "A" or "AAAA" record 976 query) thus retrieved is done. The response to this second check 977 will typically result in at least one mapping back to the client's IP 978 address. 980 Expressed as an algorithm: If the client peer's IP address is I, the 981 list of names to which I maps (after a "PTR" query) is the set N, and 982 the union of IP addresses to which each member of N maps (after 983 corresponding "A" and "AAAA" queries) is L, then this test is 984 successful if I is an element of L. 986 The response to a PTR query could contain multiple names. To prevent 987 heavy DNS loads, agents performing these queries MUST be implemented 988 such that the number of names evaluated by generation of 989 corresponding A or AAAA queries is limited so as not to be unduly 990 taxing to the DNS infrastructure, though it MAY be configurable by an 991 administrator. As an example, Section 4.6.4 of [SPF] chose a limit 992 of 10 for its implementation of this algorithm. 994 "DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the 995 query formats for the IPv6 case. 997 There is some contention regarding the wisdom and reliability of this 998 test. For example, in some regions, it can be difficult for this 999 test ever to pass because the practice of arranging to match the 1000 forward and reverse DNS is infrequently observed. Therefore, the 1001 precise implementation details of how a verifier performs an "iprev" 1002 test are not specified here. The verifier MAY report a successful or 1003 failed "iprev" test at its discretion having done some kind of check 1004 of the validity of the connection's identity using DNS. It is 1005 incumbent upon an agent making use of the reported "iprev" result to 1006 understand what exactly that particular verifier is attempting to 1007 report. 1009 Extensive discussion of reverse DNS mapping and its implications can 1010 be found in "Considerations for the use of DNS Reverse Mapping" 1011 ([DNSOP-REVERSE]). In particular, it recommends that applications 1012 avoid using this test as a means of authentication or security. Its 1013 presence in this document is not an endorsement but is merely 1014 acknowledgement that the method remains common and provides the means 1015 to relay the results of that test. 1017 4. Adding the Header Field to a Message 1019 This specification makes no attempt to evaluate the relative 1020 strengths of various message authentication methods that may become 1021 available. The methods listed are an order-independent set; their 1022 sequence does not indicate relative strength or importance of one 1023 method over another. Instead, the MUA or downstream filter consuming 1024 this header field is to interpret the result of each method based on 1025 its own knowledge of what that method evaluates. 1027 Each "method" MUST refer to an authentication method declared in the 1028 IANA registry or an extension method as described in Section 2.7.6, 1029 and each "result" MUST refer to a result code declared in the IANA 1030 registry or an extension result code as defined in Section 2.7.7. 1031 See Section 6 for further information about the registered methods 1032 and result codes. 1034 An MTA compliant with this specification adds this header field 1035 (after performing one or more message authentication tests) to 1036 indicate which MTA or ADMD performed the test, which test got 1037 applied, and what the result was. If an MTA applies more than one 1038 such test, it adds this header field either once per test or once 1039 indicating all of the results. An MTA MUST NOT add a result to an 1040 existing header field. 1042 An MTA MAY add this header field containing only the authentication 1043 identifier portion and the "none" token (see Section 2.2) to indicate 1044 explicitly that no message authentication schemes were applied prior 1045 to delivery of this message. 1047 An MTA adding this header field has to take steps to identify it as 1048 legitimate to the MUAs or downstream filters that will ultimately 1049 consume its content. One process to do so is described in Section 5. 1050 Further measures may be necessary in some environments. Some 1051 possible solutions are enumerated in Section 7.1. This document does 1052 not mandate any specific solution to this issue as each environment 1053 has its own facilities and limitations. 1055 Most known message authentication methods focus on a particular 1056 identifier to evaluate. SPF and Sender ID differ in that they can 1057 yield a result based on more than one identifier; specifically, SPF 1058 can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom 1059 parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter 1060 or the Purported Responsible Address (PRA) identity. When generating 1061 this field to report those results, only the parameter that yielded 1062 the result is included. 1064 For MTAs that add this header field, adding header fields in order 1065 (at the top), per Section 3.6 of [MAIL], is particularly important. 1066 Moreover, this header field SHOULD be inserted above any other trace 1067 header fields such MTAs might prepend. This placement allows easy 1068 detection of header fields that can be trusted. 1070 End users making direct use of this header field might inadvertently 1071 trust information that has not been properly vetted. If, for 1072 example, a basic SPF result were to be relayed that claims an 1073 authenticated addr-spec, the local-part of that addr-spec has 1074 actually not been authenticated. Thus, an MTA adding this header 1075 field SHOULD NOT include any data that has not been authenticated by 1076 the method(s) being applied. Moreover, MUAs SHOULD NOT render to 1077 users such information if it is presented by a method known not to 1078 authenticate it. 1080 4.1. Header Field Position and Interpretation 1082 In order to ensure non-ambiguous results and avoid the impact of 1083 false header fields, MUAs and downstream filters SHOULD NOT interpret 1084 this header field unless specifically configured to do so by the user 1085 or administrator. That is, this interpretation should not be "on by 1086 default". Naturally then, users or administrators ought not activate 1087 such a feature unless they are certain the header field will be 1088 validly added by an agent within the ADMD that accepts the mail that 1089 is ultimately read by the MUA, and instances of the header field 1090 appearing to originate within the ADMD but are actually added by 1091 foreign MTAs will be removed before delivery. 1093 Furthermore, MUAs and downstream filters SHOULD NOT interpret this 1094 header field unless the authentication service identifier it bears 1095 appears to be one used within its own ADMD as configured by the user 1096 or administrator. 1098 MUAs and downstream filters MUST ignore any result reported using a 1099 "result" not specified in the IANA "Result Code" registry or a 1100 "ptype" not listed in the corresponding registry for such values as 1101 defined in Section 6. Moreover, such agents MUST ignore a result 1102 indicated for any "method" they do not specifically support. 1104 An MUA SHOULD NOT reveal these results to end users, absent careful 1105 human factors design considerations and testing, for the presentation 1106 of trust-related materials. For example, an attacker could register 1107 examp1e.com (note the digit "one") and send signed mail to intended 1108 victims; a verifier would detect that the signature was valid and 1109 report a "pass" even though it's clear the DNS domain name was 1110 intended to mislead. See Section 7.2 for further discussion. 1112 As stated in Section 2.1, this header field MUST be treated as though 1113 it were a trace header field as defined in Section 3.6.7 of [MAIL] 1114 and hence MUST NOT be reordered and MUST be prepended to the message, 1115 so that there is generally some indication upon delivery of where in 1116 the chain of handling MTAs the message authentication was done. 1118 Note that there are a few message handlers that are only capable of 1119 appending new header fields to a message. Strictly speaking, these 1120 handlers are not compliant with this specification. They can still 1121 add the header field to carry authentication details, but any signal 1122 about where in the handling chain the work was done may be lost. 1123 Consumers SHOULD be designed such that this can be tolerated, 1124 especially from a producer known to have this limitation. 1126 MUAs SHOULD ignore instances of this header field discovered within 1127 message/rfc822 MIME attachments. 1129 Further discussion of these topics can be found in Section 7 below. 1131 4.2. Local Policy Enforcement 1133 Some sites have a local policy that considers any particular 1134 authentication policy's non-recoverable failure results (typically 1135 "fail" or similar) as justification for rejecting the message. In 1136 such cases, the border MTA SHOULD issue an SMTP rejection response to 1137 the message, rather than adding this header field and allowing the 1138 message to proceed toward delivery. This is more desirable than 1139 allowing the message to reach an internal host's MTA or spam filter, 1140 thus possibly generating a local rejection such as a Delivery Status 1141 Notification (DSN) [DSN] to a forged originator. Such generated 1142 rejections are colloquially known as "backscatter". 1144 The same MAY also be done for local policy decisions overriding the 1145 results of the authentication methods (e.g., the "policy" result 1146 codes described in Section 2.7). 1148 Such rejections at the SMTP protocol level are not possible if local 1149 policy is enforced at the MUA and not the MTA. 1151 5. Removing Existing Header Fields 1153 For security reasons, any MTA conforming to this specification MUST 1154 delete any discovered instance of this header field that claims, by 1155 virtue of its authentication service identifier, to have been added 1156 within its trust boundary but that did not come directly from another 1157 trusted MTA. For example, an MTA for example.com receiving a message 1158 MUST delete or otherwise obscure any instance of this header field 1159 bearing an authentication service identifier indicating that the 1160 header field was added within example.com prior to adding its own 1161 header fields. This could mean each MTA will have to be equipped 1162 with a list of internal MTAs known to be compliant (and hence 1163 trustworthy). 1165 For simplicity and maximum security, a border MTA could remove all 1166 instances of this header field on mail crossing into its trust 1167 boundary. However, this may conflict with the desire to access 1168 authentication results performed by trusted external service 1169 providers. It may also invalidate signed messages whose signatures 1170 cover external instances of this header field. A more robust border 1171 MTA could allow a specific list of authenticating MTAs whose 1172 information is to be admitted, removing the header field originating 1173 from all others. 1175 As stated in Section 1.2, a formal definition of "trust boundary" is 1176 deliberately not made here. It is entirely possible that a border 1177 MTA for example.com will explicitly trust authentication results 1178 asserted by upstream host example.net even though they exist in 1179 completely disjoint administrative boundaries. In that case, the 1180 border MTA MAY elect not to delete those results; moreover, the 1181 upstream host doing some authentication work could apply a signing 1182 technology such as [DKIM] on its own results to assure downstream 1183 hosts of their authenticity. An example of this is provided in 1184 Appendix C. 1186 Similarly, in the case of messages signed using [DKIM] or other 1187 message-signing methods that sign header fields, this removal action 1188 could invalidate one or more signatures on the message if they 1189 covered the header field to be removed. This behavior can be 1190 desirable since there's little value in validating the signature on a 1191 message with forged header fields. However, signing agents MAY 1192 therefore elect to omit these header fields from signing to avoid 1193 this situation. 1195 An MTA SHOULD remove any instance of this header field bearing a 1196 version (express or implied) that it does not support. However, an 1197 MTA MUST remove such a header field if the [SMTP] connection relaying 1198 the message is not from a trusted internal MTA. This means the MTA 1199 needs to be able to understand versions of this header field at least 1200 as late as the ones understood by the MUAs or other consumers within 1201 its ADMD. 1203 6. IANA Considerations 1205 IANA has registered the defined header field and created two tables 1206 as described below. These registry actions were originally defined 1207 by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created 1208 registries are being further updated here to increase their 1209 completeness. 1211 6.1. The Authentication-Results Header Field 1213 [RFC5451] added the Authentication-Results header field to the IANA 1214 "Permanent Message Header Field Names" registry, per the procedure 1215 found in [IANA-HEADERS]. That entry is to be updated to reference 1216 this document. The following is the registration template: 1218 Header field name: Authentication-Results 1219 Applicable protocol: mail ([MAIL]) 1220 Status: Standard 1221 Author/Change controller: IETF 1222 Specification document(s): [this RFC] 1223 Related information: 1224 Requesting review of any proposed changes and additions to 1225 this field is recommended. 1227 6.2. "Email Authentication Methods" Registry Description 1229 Names of message authentication methods supported by this 1230 specification are to be registered with IANA, with the exception of 1231 experimental names as described in Section 2.7.6. Along with each 1232 method is recorded the properties that accompany the method's result. 1234 A registry was created by [RFC5451] for this purpose. [RFC6577] 1235 added a "status" field for each entry. [RFC7001] amended the rules 1236 governing that registry, and also added a "version" field to the 1237 registry. 1239 New entries are assigned only for values that have received Expert 1240 Review, per [IANA-CONSIDERATIONS]. The designated expert shall be 1241 appointed by the IESG. The designated expert has discretion to 1242 request that a publication be referenced if a clear, concise 1243 definition of the authentication method cannot be provided such that 1244 interoperability is assured. Registrations should otherwise be 1245 permitted. The designated expert can also handle requests to mark 1246 any current registration as "deprecated". 1248 No two entries can have the same combination of method, ptype, and 1249 property. 1251 An entry in this registry contains the following: 1253 Method: the name of the method; 1255 Defined: a reference to the document that created this entry, if any 1256 (see below); 1258 ptype: a "ptype" value appropriate for use with that method; 1260 property: a "property" value matching that "ptype" also appropriate 1261 for use with that method; 1263 Value: a brief description of the value to be supplied with that 1264 method/ptype/property tuple; 1266 Status: the status of this entry, which is either: 1268 active: The entry is in current use. 1270 deprecated: The entry is no longer in current use. 1272 Version: a version number associated with the method (preferably 1273 starting at "1"). 1275 The "Defined" field will typically refer to a permanent document, or 1276 at least some descriptive text, where additional information about 1277 the entry being added can be found. This in turn would reference the 1278 document where the method is defined so that all of the semantics 1279 around creating or interpreting an Authentication-Results header 1280 field using this method, ptype, and property can be understood. 1282 6.3. "Email Authentication Methods" Registry Update 1284 The following changes are to be made to this registry upon approval 1285 of this document: 1287 1. The sole entry for the "auth" method shall have its "property" 1288 field changed to "mailfrom", and its "Defined" field changed to 1289 this document. 1291 2. All "dkim", "domainkeys", "iprev", "sender-id", and "spf" method 1292 entries shall have their "Defined" fields changed to this 1293 document. 1295 6.4. "Email Authentication Result Names" Registry 1297 Names of message authentication result codes supported by this 1298 specification must be registered with IANA, with the exception of 1299 experimental codes as described in Section 2.7.7. A registry was 1300 created by [RFC5451] for this purpose. [RFC6577] added the "status" 1301 column, and [RFC7001] updated the rules governing that registry. 1303 New entries are assigned only for values that have received Expert 1304 Review, per [IANA-CONSIDERATIONS]. The designated expert shall be 1305 appointed by the IESG. The designated expert has discretion to 1306 request that a publication be referenced if a clear, concise 1307 definition of the authentication result cannot be provided such that 1308 interoperability is assured. Registrations should otherwise be 1309 permitted. The designated expert can also handle requests to mark 1310 any current registration as "deprecated". 1312 All existing registry entries that reference [RFC7001] are to be 1313 updated to reference this document. 1315 The definitions for the SPF and Sender ID authentication methods are 1316 to be updated using the references found in Section 2.7.2. 1318 7. Security Considerations 1320 The following security considerations apply when adding or processing 1321 the Authentication-Results header field: 1323 7.1. Forged Header Fields 1325 An MUA or filter that accesses a mailbox whose messages are handled 1326 by a non-conformant MTA, and understands Authentication-Results 1327 header fields, could potentially make false conclusions based on 1328 forged header fields. A malicious user or agent could forge a header 1329 field using the DNS domain of a receiving ADMD as the authserv-id 1330 token in the value of the header field and, with the rest of the 1331 value, claim that the message was properly authenticated. The non- 1332 conformant MTA would fail to strip the forged header field, and the 1333 MUA could inappropriately trust it. 1335 For this reason, it is best not to have processing of the 1336 Authentication-Results header field enabled by default; instead, it 1337 should be ignored, at least for the purposes of enacting filtering 1338 decisions, unless specifically enabled by the user or administrator 1339 after verifying that the border MTA is compliant. It is acceptable 1340 to have an MUA aware of this specification but have an explicit list 1341 of hostnames whose Authentication-Results header fields are 1342 trustworthy; however, this list should initially be empty. 1344 Proposed alternative solutions to this problem were made some time 1345 ago and are listed below. To date, they have not been developed due 1346 to lack of demand but are documented here should the information be 1347 useful at some point in the future: 1349 1. Possibly the simplest is a digital signature protecting the 1350 header field, such as using [DKIM], that can be verified by an 1351 MUA by using a posted public key. Although one of the main 1352 purposes of this document is to relieve the burden of doing 1353 message authentication work at the MUA, this only requires that 1354 the MUA learn a single authentication scheme even if a number of 1355 them are in use at the border MTA. Note that [DKIM] requires 1356 that the From header field be signed, although in this 1357 application, the signing agent (a trusted MTA) likely cannot 1358 authenticate that value, so the fact that it is signed should be 1359 ignored. Where the authserv-id is the ADMD's domain name, the 1360 authserv-id matching this valid internal signature's "d=" DKIM 1361 value is sufficient. 1363 2. Another would be a means to interrogate the MTA that added the 1364 header field to see if it is actually providing any message 1365 authentication services and saw the message in question, but this 1366 isn't especially palatable given the work required to craft and 1367 implement such a scheme. 1369 3. Yet another might be a method to interrogate the internal MTAs 1370 that apparently handled the message (based on Received header 1371 fields) to determine whether any of them conform to Section 5 of 1372 this memo. This, too, has potentially high barriers to entry. 1374 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to 1375 allow an MUA or filtering agent to acquire the authserv-id in use 1376 within an ADMD, thus allowing it to identify which 1377 Authentication-Results header fields it can trust. 1379 5. On the presumption that internal MTAs are fully compliant with 1380 Section 3.6 of [MAIL] and the compliant internal MTAs are using 1381 their own hostnames or the ADMD's DNS domain name as the 1382 authserv-id token, the header field proposed here should always 1383 appear above a Received header added by a trusted MTA. This can 1384 be used as a test for header field validity. 1386 Support for some of these is being considered for future work. 1388 In any case, a mechanism needs to exist for an MUA or filter to 1389 verify that the host that appears to have added the header field (a) 1390 actually did so and (b) is legitimately adding that header field for 1391 this delivery. Given the variety of messaging environments deployed 1392 today, consensus appears to be that specifying a particular mechanism 1393 for doing so is not appropriate for this document. 1395 Mitigation of the forged header field attack can also be accomplished 1396 by moving the authentication results data into metadata associated 1397 with the message. In particular, an [SMTP] extension could be 1398 established to communicate authentication results from the border MTA 1399 to intermediate and delivery MTAs; the latter of these could arrange 1400 to store the authentication results as metadata retrieved and 1401 rendered along with the message by an [IMAP] client aware of a 1402 similar extension in that protocol. The delivery MTA would be told 1403 to trust data via this extension only from MTAs it trusts, and border 1404 MTAs would not accept data via this extension from any source. There 1405 is no vector in such an arrangement for forgery of authentication 1406 data by an outside agent. 1408 7.2. Misleading Results 1410 Until some form of service for querying the reputation of a sending 1411 agent is widely deployed, the existence of this header field 1412 indicating a "pass" does not render the message trustworthy. It is 1413 possible for an arriving piece of spam or other undesirable mail to 1414 pass checks by several of the methods enumerated above (e.g., a piece 1415 of spam signed using [DKIM] by the originator of the spam, which 1416 might be a spammer or a compromised system). In particular, this 1417 issue is not resolved by forged header field removal discussed above. 1419 Hence, MUAs and downstream filters must take some care with use of 1420 this header even after possibly malicious headers are scrubbed. 1422 7.3. Header Field Position 1424 Despite the requirements of [MAIL], header fields can sometimes be 1425 reordered en route by intermediate MTAs. The goal of requiring 1426 header field addition only at the top of a message is an 1427 acknowledgement that some MTAs do reorder header fields, but most do 1428 not. Thus, in the general case, there will be some indication of 1429 which MTAs (if any) handled the message after the addition of the 1430 header field defined here. 1432 7.4. Reverse IP Query Denial-of-Service Attacks 1434 Section 4.6.4 of [SPF] describes a DNS-based denial-of-service attack 1435 for verifiers that attempt DNS-based identity verification of 1436 arriving client connections. A verifier wishing to do this check and 1437 report this information needs to take care not to go to unbounded 1438 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1439 making use of an "iprev" result specified by this document need to be 1440 aware of the algorithm used by the verifier reporting the result and, 1441 especially, its limitations. 1443 7.5. Mitigation of Backscatter 1445 Failing to follow the instructions of Section 4.2 can result in a 1446 denial-of-service attack caused by the generation of [DSN] messages 1447 (or equivalent) to addresses that did not send the messages being 1448 rejected. 1450 7.6. Internal MTA Lists 1452 Section 5 describes a procedure for scrubbing header fields that may 1453 contain forged authentication results about a message. A compliant 1454 installation will have to include, at each MTA, a list of other MTAs 1455 known to be compliant and trustworthy. Failing to keep this list 1456 current as internal infrastructure changes may expose an ADMD to 1457 attack. 1459 7.7. Attacks against Authentication Methods 1461 If an attack becomes known against an authentication method, clearly 1462 then the agent verifying that method can be fooled into thinking an 1463 inauthentic message is authentic, and thus the value of this header 1464 field can be misleading. It follows that any attack against the 1465 authentication methods supported by this document is also a security 1466 consideration here. 1468 7.8. Intentionally Malformed Header Fields 1470 It is possible for an attacker to add an Authentication-Results 1471 header field that is extraordinarily large or otherwise malformed in 1472 an attempt to discover or exploit weaknesses in header field parsing 1473 code. Implementers must thoroughly verify all such header fields 1474 received from MTAs and be robust against intentionally as well as 1475 unintentionally malformed header fields. 1477 7.9. Compromised Internal Hosts 1479 An internal MUA or MTA that has been compromised could generate mail 1480 with a forged From header field and a forged Authentication-Results 1481 header field that endorses it. Although it is clearly a larger 1482 concern to have compromised internal machines than it is to prove the 1483 value of this header field, this risk can be mitigated by arranging 1484 that internal MTAs will remove this header field if it claims to have 1485 been added by a trusted border MTA (as described above), yet the 1486 [SMTP] connection is not coming from an internal machine known to be 1487 running an authorized MTA. However, in such a configuration, 1488 legitimate MTAs will have to add this header field when legitimate 1489 internal-only messages are generated. This is also covered in 1490 Section 5. 1492 7.10. Encapsulated Instances 1494 MIME messages can contain attachments of type "message/rfc822", which 1495 contain other messages. Such an encapsulated message can also 1496 contain an Authentication-Results header field. Although the 1497 processing of these is outside of the intended scope of this document 1498 (see Section 1.3), some early guidance to MUA developers is 1499 appropriate here. 1501 Since MTAs are unlikely to strip Authentication-Results header fields 1502 after mailbox delivery, MUAs are advised in Section 4.1 to ignore 1503 such instances within MIME attachments. Moreover, when extracting a 1504 message digest to separate mail store messages or other media, such 1505 header fields should be removed so that they will never be 1506 interpreted improperly by MUAs that might later consume them. 1508 7.11. Reverse Mapping 1510 Although Section 3 of this memo includes explicit support for the 1511 "iprev" method, its value as an authentication mechanism is limited. 1512 Implementers of both this proposal and agents that use the data it 1513 relays are encouraged to become familiar with the issues raised by 1514 [DNSOP-REVERSE] when deciding whether or not to include support for 1515 "iprev". 1517 8. References 1519 8.1. Normative References 1521 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 1522 Syntax Specifications: ABNF", STD 68, 1523 RFC 5234, January 2008. 1525 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 1526 "Registration Procedures for Message Header 1527 Fields", BCP 90, RFC 3864, September 2004. 1529 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 1530 Indicate Requirement Levels", BCP 14, 1531 RFC 2119. 1533 [MAIL] Resnick, P., Ed., "Internet Message Format", 1534 RFC 5322, October 2008. 1536 [MIME] Freed, N. and N. Borenstein, "Multipurpose 1537 Internet Mail Extensions (MIME) Part One: 1538 Format of Internet Message Bodies", RFC 2045, 1539 November 1996. 1541 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 1542 RFC 5321, October 2008. 1544 8.2. Informative References 1546 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 1547 Levine, "DomainKeys Identified Mail (DKIM) 1548 Author Domain Signing Practices (ADSP)", 1549 RFC 5617, August 2009. 1551 [AR-VBR] Kucherawy, M., "Authentication-Results 1552 Registration for Vouch by Reference Results", 1553 RFC 6212, April 2011. 1555 [ATPS] Kucherawy, M., "DomainKeys Identified Mail 1556 (DKIM) Authorized Third-Party Signatures", 1557 RFC 6541, February 2012. 1559 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service 1560 Extension for Authentication", RFC 4954, 1561 July 2007. 1563 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, 1564 "DomainKeys Identified Mail (DKIM) 1565 Signatures", STD 76, RFC 6376, September 2011. 1567 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., 1568 "Domain-based Message Authentication, 1569 Reporting and Conformance (DMARC)", 1570 I-D draft-kucherawy-dmarc-base, February 2015. 1572 [DNS] Mockapetris, P., "Domain names - 1573 Implementation and Specification", STD 13, 1574 RFC 1035, November 1987. 1576 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. 1577 Souissi, "DNS Extensions to Support IP Version 1578 6", RFC 3596, October 2003. 1580 [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for 1581 the use of DNS Reverse Mapping", Work 1582 in Progress, March 2008. 1584 [DOMAINKEYS] Delany, M., "Domain-Based Email Authentication 1585 Using Public Keys Advertised in the DNS 1586 (DomainKeys)", RFC 4870, May 2007. 1588 [DSN] Moore, K. and G. Vaudreuil, "An Extensible 1589 Message Format for Delivery Status 1590 Notifications", RFC 3464, January 2003. 1592 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 1593 RFC 5598, July 2009. 1595 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 1596 Writing an IANA Considerations Section in 1597 RFCs", BCP 26, RFC 5226, May 2008. 1599 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL 1600 - VERSION 4rev1", RFC 3501, March 2003. 1602 [POP3] Myers, J. and M. Rose, "Post Office Protocol - 1603 Version 3", STD 53, RFC 1939, May 1996. 1605 [PRA] Lyon, J., "Purported Responsible Address in 1606 E-Mail Messages", RFC 4407, April 2006. 1608 [PTYPES-REGISTRY] Kucherawy, M., "A Property Types Registry for 1609 the Authentication-Results Header Field", 1610 RFC 7410, December 2014. 1612 [RFC5451] Kucherawy, M., "Message Header Field for 1613 Indicating Message Authentication Status", 1614 RFC 5451, April 2009. 1616 [RFC6577] Kucherawy, M., "Authentication-Results 1617 Registration Update for Sender Policy 1618 Framework (SPF) Results", RFC 6577, 1619 March 2012. 1621 [RFC7001] Kucherawy, M., "Message Header Field for 1622 Indicating Message Authentication Status", 1623 RFC 7001, September 2013. 1625 [RRVS] Mills, W. and M. Kucherawy, "The Require- 1626 Recipient-Valid-Since Header Field and SMTP 1627 Service Extension", RFC 7293, July 2014. 1629 [SECURITY] Rescorla, E. and B. Korver, "Guidelines for 1630 Writing RFC Text on Security Considerations", 1631 BCP 72, RFC 3552, July 2003. 1633 [SENDERID] Lyon, J. and M. Wong, "Sender ID: 1634 Authenticating E-Mail", RFC 4406, April 2006. 1636 [SMIME-REG] Melnikov, A., "Authentication-Results 1637 Registration for S/MIME Signature 1638 Verification", RFC 7281, June 2014. 1640 [SPF] Kitterman, S., "Sender Policy Framework (SPF) 1641 for Authorizing Use of Domains in E-Mail, 1642 Version 1", RFC 7208, April 2014. 1644 [VBR] Hoffman, P., Levine, J., and A. Hathcock, 1645 "Vouch By Reference", RFC 5518, April 2009. 1647 Appendix A. Acknowledgements 1649 The author wishes to acknowledge the following individuals for their 1650 review and constructive criticism of this document: Stephane 1651 Bortzmeyer, Scott Kitterman, John Levine, and Tom Petch. 1653 Appendix B. Legacy MUAs 1655 Implementers of this protocol should be aware that many MUAs are 1656 unlikely to be retrofitted to support the new header field and its 1657 semantics. In the interests of convenience and quicker adoption, a 1658 delivery MTA might want to consider adding things that are processed 1659 by existing MUAs in addition to the Authentication-Results header 1660 field. One suggestion is to include a Priority header field, on 1661 messages that don't already have such a header field, containing a 1662 value that reflects the strength of the authentication that was 1663 accomplished, e.g., "low" for weak or no authentication, "normal" or 1664 "high" for good or strong authentication. 1666 Some modern MUAs can already filter based on the content of this 1667 header field. However, there is keen interest in having MUAs make 1668 some kind of graphical representation of this header field's meaning 1669 to end users. Until this capability is added, other interim means of 1670 conveying authentication results may be necessary while this proposal 1671 and its successors are adopted. 1673 Appendix C. Authentication-Results Examples 1675 This section presents some examples of the use of this header field 1676 to indicate authentication results. 1678 C.1. Trivial Case; Header Field Not Present 1680 The trivial case: 1682 Received: from mail-router.example.com 1683 (mail-router.example.com [192.0.2.1]) 1684 by server.example.org (8.11.6/8.11.6) 1685 with ESMTP id g1G0r1kA003489; 1686 Fri, Feb 15 2002 17:19:07 -0800 1687 From: sender@example.com 1688 Date: Fri, Feb 15 2002 16:54:30 -0800 1689 To: receiver@example.org 1690 Message-Id: <12345.abc@example.com> 1691 Subject: here's a sample 1693 Hello! Goodbye! 1695 Example 1: Trivial Case 1697 The Authentication-Results header field is completely absent. The 1698 MUA may make no conclusion about the validity of the message. This 1699 could be the case because the message authentication services were 1700 not available at the time of delivery, or no service is provided, or 1701 the MTA is not in compliance with this specification. 1703 C.2. Nearly Trivial Case; Service Provided, but No Authentication Done 1705 A message that was delivered by an MTA that conforms to this 1706 specification but provides no actual message authentication service: 1708 Authentication-Results: example.org 1; none 1709 Received: from mail-router.example.com 1710 (mail-router.example.com [192.0.2.1]) 1711 by server.example.org (8.11.6/8.11.6) 1712 with ESMTP id g1G0r1kA003489; 1713 Fri, Feb 15 2002 17:19:07 -0800 1714 From: sender@example.com 1715 Date: Fri, Feb 15 2002 16:54:30 -0800 1716 To: receiver@example.org 1717 Message-Id: <12345.abc@example.com> 1718 Subject: here's a sample 1720 Hello! Goodbye! 1722 Example 2: Header Present but No Authentication Done 1724 The Authentication-Results header field is present, showing that the 1725 delivering MTA conforms to this specification. It used its DNS 1726 domain name as the authserv-id. The presence of "none" (and the 1727 absence of any method and result tokens) indicates that no message 1728 authentication was done. The version number of the specification to 1729 which the field's content conforms is explicitly provided. 1731 C.3. Service Provided, Authentication Done 1733 A message that was delivered by an MTA that conforms to this 1734 specification and applied some message authentication: 1736 Authentication-Results: example.com; 1737 spf=pass smtp.mailfrom=example.net 1738 Received: from dialup-1-2-3-4.example.net 1739 (dialup-1-2-3-4.example.net [192.0.2.200]) 1740 by mail-router.example.com (8.11.6/8.11.6) 1741 with ESMTP id g1G0r1kA003489; 1742 Fri, Feb 15 2002 17:19:07 -0800 1743 From: sender@example.net 1744 Date: Fri, Feb 15 2002 16:54:30 -0800 1745 To: receiver@example.com 1746 Message-Id: <12345.abc@example.net> 1747 Subject: here's a sample 1749 Hello! Goodbye! 1751 Example 3: Header Reporting Results 1753 The Authentication-Results header field is present, indicating that 1754 the border MTA conforms to this specification. The authserv-id is 1755 once again the DNS domain name. Furthermore, the message was 1756 authenticated by that MTA via the method specified in [SPF]. Note 1757 that since that method cannot authenticate the local-part, it has 1758 been omitted from the result's value. The MUA could extract and 1759 relay this extra information if desired. 1761 C.4. Service Provided, Several Authentications Done, Single MTA 1763 A message that was relayed inbound via a single MTA that conforms to 1764 this specification and applied three different message authentication 1765 checks: 1767 Authentication-Results: example.com; 1768 auth=pass (cram-md5) smtp.auth=sender@example.net; 1769 spf=pass smtp.mailfrom=example.net 1770 Authentication-Results: example.com; 1771 sender-id=pass header.from=example.net 1772 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1773 (dialup-1-2-3-4.example.net [192.0.2.200]) 1774 by mail-router.example.com (8.11.6/8.11.6) 1775 with ESMTP id g1G0r1kA003489; 1776 Fri, Feb 15 2002 17:19:07 -0800 1777 Date: Fri, Feb 15 2002 16:54:30 -0800 1778 To: receiver@example.com 1779 From: sender@example.net 1780 Message-Id: <12345.abc@example.net> 1781 Subject: here's a sample 1783 Hello! Goodbye! 1785 Example 4: Headers Reporting Results from One MTA 1787 The Authentication-Results header field is present, indicating that 1788 the delivering MTA conforms to this specification. Once again, the 1789 receiving DNS domain name is used as the authserv-id. Furthermore, 1790 the sender authenticated herself/himself to the MTA via a method 1791 specified in [AUTH], and both SPF and Sender ID checks were done and 1792 passed. The MUA could extract and relay this extra information if 1793 desired. 1795 Two Authentication-Results header fields are not required since the 1796 same host did all of the checking. The authenticating agent could 1797 have consolidated all the results into one header field. 1799 This example illustrates a scenario in which a remote user on a 1800 dialup connection (example.net) sends mail to a border MTA 1801 (example.com) using SMTP authentication to prove identity. The 1802 dialup provider has been explicitly authorized to relay mail as 1803 example.com resulting in passes by the SPF and Sender ID checks. 1805 C.5. Service Provided, Several Authentications Done, Different MTAs 1807 A message that was relayed inbound by two different MTAs that conform 1808 to this specification and applied multiple message authentication 1809 checks: 1811 Authentication-Results: example.com; 1812 sender-id=fail header.from=example.com; 1813 dkim=pass (good signature) header.d=example.com 1814 Received: from mail-router.example.com 1815 (mail-router.example.com [192.0.2.1]) 1816 by auth-checker.example.com (8.11.6/8.11.6) 1817 with ESMTP id i7PK0sH7021929; 1818 Fri, Feb 15 2002 17:19:22 -0800 1819 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1820 t=1188964191; c=simple/simple; h=From:Date:To:Subject: 1821 Message-Id:Authentication-Results; 1822 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1823 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1824 Authentication-Results: example.com; 1825 auth=pass (cram-md5) smtp.auth=sender@example.com; 1826 spf=fail smtp.mailfrom=example.com 1827 Received: from dialup-1-2-3-4.example.net 1828 (dialup-1-2-3-4.example.net [192.0.2.200]) 1829 by mail-router.example.com (8.11.6/8.11.6) 1830 with ESMTP id g1G0r1kA003489; 1831 Fri, Feb 15 2002 17:19:07 -0800 1832 From: sender@example.com 1833 Date: Fri, Feb 15 2002 16:54:30 -0800 1834 To: receiver@example.com 1835 Message-Id: <12345.abc@example.com> 1836 Subject: here's a sample 1838 Hello! Goodbye! 1840 Example 5: Headers Reporting Results from Multiple MTAs 1842 The Authentication-Results header field is present, indicating 1843 conformance to this specification. Once again, the authserv-id used 1844 is the recipient's DNS domain name. The header field is present 1845 twice because two different MTAs in the chain of delivery did 1846 authentication tests. The first MTA, mail-router.example.com, 1847 reports that SMTP AUTH and SPF were both used and that the former 1848 passed while the latter failed. In the SMTP AUTH case, additional 1849 information is provided in the comment field, which the MUA can 1850 choose to render if desired. 1852 The second MTA, auth-checker.example.com, reports that it did a 1853 Sender ID test (which failed) and a DKIM test (which passed). Again, 1854 additional data about one of the tests is provided as a comment, 1855 which the MUA may choose to render. Also noteworthy here is the fact 1856 that there is a DKIM signature added by example.com that assured the 1857 integrity of the lower Authentication-Results field. 1859 Since different hosts did the two sets of authentication checks, the 1860 header fields cannot be consolidated in this example. 1862 This example illustrates more typical transmission of mail into 1863 example.com from a user on a dialup connection example.net. The user 1864 appears to be legitimate as he/she had a valid password allowing 1865 authentication at the border MTA using SMTP AUTH. The SPF and Sender 1866 ID tests failed since example.com has not granted example.net 1867 authority to relay mail on its behalf. However, the DKIM test passed 1868 because the sending user had a private key matching one of 1869 example.com's published public keys and used it to sign the message. 1871 C.6. Service Provided, Multi-Tiered Authentication Done 1873 A message that had authentication done at various stages, one of 1874 which was outside the receiving ADMD: 1876 Authentication-Results: example.com; 1877 dkim=pass reason="good signature" 1878 header.i=@mail-router.example.net; 1879 dkim=fail reason="bad signature" 1880 header.i=@newyork.example.com 1881 Received: from mail-router.example.net 1882 (mail-router.example.net [192.0.2.250]) 1883 by chicago.example.com (8.11.6/8.11.6) 1884 for 1885 with ESMTP id i7PK0sH7021929; 1886 Fri, Feb 15 2002 17:19:22 -0800 1887 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1888 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1889 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1890 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1891 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1892 Authentication-Results: example.net; 1893 dkim=pass (good signature) header.i=@newyork.example.com 1894 Received: from smtp.newyork.example.com 1895 (smtp.newyork.example.com [192.0.2.220]) 1896 by mail-router.example.net (8.11.6/8.11.6) 1897 with ESMTP id g1G0r1kA003489; 1898 Fri, Feb 15 2002 17:19:07 -0800 1899 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; 1900 d=newyork.example.com; 1901 t=1188964191; c=simple/simple; 1902 h=From:Date:To:Message-Id:Subject; 1903 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1904 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1905 From: sender@newyork.example.com 1906 Date: Fri, Feb 15 2002 16:54:30 -0800 1907 To: meetings@example.net 1908 Message-Id: <12345.abc@newyork.example.com> 1909 Subject: here's a sample 1911 Example 6: Headers Reporting Results from Multiple MTAs in Different 1912 ADMDs 1914 In this example, we see multi-tiered authentication with an extended 1915 trust boundary. 1917 The message was sent from someone at example.com's New York office 1918 (newyork.example.com) to a mailing list managed at an intermediary. 1920 The message was signed at the origin using DKIM. 1922 The message was sent to a mailing list service provider called 1923 example.net, which is used by example.com. There, 1924 meetings@example.net is expanded to a long list of recipients, one of 1925 whom is at the Chicago office. In this example, we will assume that 1926 the trust boundary for chicago.example.com includes the mailing list 1927 server at example.net. 1929 The mailing list server there first authenticated the message and 1930 affixed an Authentication-Results header field indicating such using 1931 its DNS domain name for the authserv-id. It then altered the message 1932 by affixing some footer text to the body, including some 1933 administrivia such as unsubscription instructions. Finally, the 1934 mailing list server affixes a second DKIM signature and begins 1935 distribution of the message. 1937 The border MTA for chicago.example.com explicitly trusts results from 1938 mail-router.example.net, so that header field is not removed. It 1939 performs evaluation of both signatures and determines that the first 1940 (most recent) is a "pass" but, because of the aforementioned 1941 modifications, the second is a "fail". However, the first signature 1942 included the Authentication-Results header added at mail- 1943 router.example.net that validated the second signature. Thus, 1944 indirectly, it can be determined that the authentications claimed by 1945 both signatures are indeed valid. 1947 Note that two styles of presenting metadata about the result are in 1948 use here. In one case, the "reason=" clause is present, which is 1949 intended for easy extraction by parsers; in the other case, the CFWS 1950 production of the ABNF is used to include such data as a header field 1951 comment. The latter can be harder for parsers to extract given the 1952 varied supported syntaxes of mail header fields. 1954 C.7. Comment-Heavy Example 1956 The formal syntax permits comments within the content in a number of 1957 places. For the sake of illustration, this example is also legal: 1959 Authentication-Results: foo.example.net (foobar) 1 (baz); 1960 dkim (Because I like it) / 1 (One yay) = (wait for it) fail 1961 policy (A dot can go here) . (like that) expired 1962 (this surprised me) = (as I wasn't expecting it) 1362471462 1964 Example 7: A Very Comment-Heavy but Perfectly Legal Example 1966 Appendix D. Operational Considerations about Message Authentication 1968 This protocol is predicated on the idea that authentication (and 1969 presumably in the future, reputation) work is typically done by 1970 border MTAs rather than MUAs or intermediate MTAs; the latter merely 1971 make use of the results determined by the former. Certainly this is 1972 not mandatory for participation in electronic mail or message 1973 authentication, but this protocol and its deployment to date are 1974 based on that model. The assumption satisfies several common ADMD 1975 requirements: 1977 1. Service operators prefer to resolve the handling of problem 1978 messages as close to the border of the ADMD as possible. This 1979 enables, for example, rejection of messages at the SMTP level 1980 rather than generating a DSN internally. Thus, doing any of the 1981 authentication or reputation work exclusively at the MUA or 1982 intermediate MTA renders this desire unattainable. 1984 2. Border MTAs are more likely to have direct access to external 1985 sources of authentication or reputation information since modern 1986 MUAs are more likely to be heavily firewalled. Thus, some MUAs 1987 might not even be able to complete the task of performing 1988 authentication or reputation evaluations without complex proxy 1989 configurations or similar burdens. 1991 3. MUAs rely upon the upstream MTAs within their trust boundaries to 1992 make correct (as much as is possible) evaluations about the 1993 message's envelope, header, and content. Thus, MUAs don't need 1994 to know how to do the work that upstream MTAs do; they only need 1995 the results of that work. 1997 4. Evaluations about the quality of a message, from simple token 1998 matching (e.g., a list of preferred DNS domains) to cryptanalysis 1999 (e.g., public/private key work), are at least a little bit 2000 expensive and thus need to be minimized. To that end, performing 2001 those tests at the border MTA is far preferred to doing that work 2002 at each MUA that handles a message. If an ADMD's environment 2003 adheres to common messaging protocols, a reputation query or an 2004 authentication check performed by a border MTA would return the 2005 same result as the same query performed by an MUA. By contrast, 2006 in an environment where the MUA does the work, a message arriving 2007 for multiple recipients would thus cause authentication or 2008 reputation evaluation to be done more than once for the same 2009 message (i.e., at each MUA), causing needless amplification of 2010 resource use and creating a possible denial-of-service attack 2011 vector. 2013 5. Minimizing change is good. As new authentication and reputation 2014 methods emerge, the list of methods supported by this header 2015 field would presumably be extended. If MUAs simply consume the 2016 contents of this header field rather than actually attempt to do 2017 authentication and/or reputation work, then MUAs only need to 2018 learn to parse this header field once; emergence of new methods 2019 requires only a configuration change at the MUAs and software 2020 changes at the MTAs (which are presumably fewer in number). When 2021 choosing to implement these functions in MTAs vs. MUAs, the 2022 issues of individual flexibility, infrastructure inertia, and 2023 scale of effort must be considered. It is typically easier to 2024 change a single MUA than an MTA because the modification affects 2025 fewer users and can be pursued with less care. However, changing 2026 many MUAs is more effort than changing a smaller number of MTAs. 2028 6. For decisions affecting message delivery and display, assessment 2029 based on authentication and reputation is best performed close to 2030 the time of message transit, as a message makes its journey 2031 toward a user's inbox, not afterwards. DKIM keys and IP address 2032 reputations, etc., can change over time or even become invalid, 2033 and users can take a long time to read a message once delivered. 2034 The value of this work thus degrades, perhaps quickly, once the 2035 delivery process has completed. This seriously diminishes the 2036 value of this work when done other than at MTAs. 2038 Many operational choices are possible within an ADMD, including the 2039 venue for performing authentication and/or reputation assessment. 2040 The current specification does not dictate any of those choices. 2041 Rather, it facilitates those cases in which information produced by 2042 one stage of analysis needs to be transported with the message to the 2043 next stage. 2045 Appendix E. Change History 2047 E.1. RFC7001 to -00 2049 o Remove "Changes since RFC5451" section; add this "Change History" 2050 section. 2052 o Restore XML to previous format. (No visible changes). 2054 o Reset "Acknowledgments". 2056 o Add "To-Do" section. 2058 E.2. -00 to -01 2060 o Apply RFC7410. 2062 o Update all the RFC4408 references to RFC7208. 2064 o Add section explaining "property" values. (Errata #4201) 2066 o Remove "To-Do" section. 2068 E.3. -01 to -02 2070 o Consolidate new sections. 2072 E.4. -02 to -03 2074 o Move the DKIM exception text down to where the DKIM results are 2075 defined, and add a forward reference to them. 2077 o More detail about registry creation and previous augmentations. 2079 o Add text explaining each of the method-ptype-property tuples 2080 registered by this document. 2082 o Change the meaning of the "Defined" column of the methods registry 2083 to be the place where each entry was created and described; it is 2084 expected that this will then refer to the method's defining 2085 document. Provide IANA with corresponding update instructions. 2087 o Add references: [DMARC], [PRA], [RFC6577], [RRVS], [SMIME-REG]. 2089 Author's Address 2091 Murray S. Kucherawy 2092 270 Upland Drive 2093 San Francisco, CA 94127 2094 US 2096 EMail: superuser@gmail.com