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