idnits 2.17.1 draft-ietf-appsawg-rfc5451bis-02.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 RFC5451, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2013) is 3973 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 461, but not defined -- Obsolete informational reference (is this intentional?): RFC 4870 (ref. 'DOMAINKEYS') (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 0 errors (**), 0 flaws (~~), 2 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 May 12, 2013 4 Obsoletes: 5451, 6577 5 (if approved) 6 Intended status: Standards Track 7 Expires: November 13, 2013 9 Message Header Field for Indicating Message Authentication Status 10 draft-ietf-appsawg-rfc5451bis-02 12 Abstract 14 This document specifies a header field for use with electronic mail 15 messages to indicate the results of message authentication efforts. 16 Any receiver-side software, such as mail filters or Mail User Agents 17 (MUAs), can use this header field to relay that information in a 18 convenient and meaningful way to users, or make sorting and filtering 19 decisions. 21 This document is a candidate for Internet Standard status. [RFC 22 Editor: Please delete this notation, as I imagine it will be 23 indicated some other way.] 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 13, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 6 63 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6 66 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 7 68 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8 69 2. Definition and Format of the Header Field . . . . . . . . . . 8 70 2.1. General Description . . . . . . . . . . . . . . . . . . . 8 71 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 72 2.3. Authentication Identifier Field . . . . . . . . . . . . . 11 73 2.4. Version Tokens . . . . . . . . . . . . . . . . . . . . . . 13 74 2.5. Result Values . . . . . . . . . . . . . . . . . . . . . . 13 75 2.5.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 13 76 2.5.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 14 77 2.5.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 15 78 2.5.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 15 79 2.5.5. Extension Result Codes . . . . . . . . . . . . . . . . 16 80 2.6. Authentication Methods . . . . . . . . . . . . . . . . . . 16 81 2.6.1. Definitions for Existing Methods . . . . . . . . . . . 17 82 2.6.2. Extension Methods . . . . . . . . . . . . . . . . . . 17 83 3. The "iprev" Authentication Method . . . . . . . . . . . . . . 18 84 4. Adding the Header Field to A Message . . . . . . . . . . . . . 19 85 4.1. Header Field Position and Interpretation . . . . . . . . . 20 86 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 21 87 5. Removing the Header Field . . . . . . . . . . . . . . . . . . 22 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 6.1. The Authentication-Results Header Field . . . . . . . . . 23 90 6.2. Email Authentication Method Name Registry . . . . . . . . 23 91 6.3. Email Authentication Result Name Registry . . . . . . . . 24 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 93 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 24 94 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 26 95 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 26 96 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 26 97 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 27 98 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 27 99 7.7. Attacks against Authentication Methods . . . . . . . . . . 27 100 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 27 101 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 27 102 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 28 103 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 28 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 106 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 107 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 108 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 30 109 Appendix C. Authentication-Results Examples . . . . . . . . . . . 31 110 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 31 111 C.2. Nearly Trivial Case; Service Provided, But No 112 Authentication Done . . . . . . . . . . . . . . . . . . . 32 113 C.3. Service Provided, Authentication Done . . . . . . . . . . 33 114 C.4. Service Provided, Several Authentications Done, Single 115 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 C.5. Service Provided, Several Authentications Done, 117 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 35 118 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 37 119 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 38 120 Appendix D. Operational Considerations about Message 121 Authentication . . . . . . . . . . . . . . . . . . . 39 122 Appendix E. Known Implementations . . . . . . . . . . . . . . . . 40 123 Appendix F. Changes since RFC5451 . . . . . . . . . . . . . . . . 41 125 1. Introduction 127 The first version of this document [RFC5451] defined a new header 128 field for electronic mail messages that presents the results of a 129 message authentication effort in a machine-readable format. This 130 document revises that definition based on current use of various 131 authentication protocols in use today and incorporates errata logged 132 since the publication of the original specification. 134 The intent of the header field is to create a place to collect such 135 data when message authentication mechanisms are in use so that a Mail 136 User Agent (MUA) and downstream filters can make filtering decisions 137 and/or provide a recommendation to the user as to the validity of the 138 message's origin and possibly the safety and integrity of its 139 content. 141 End users are not expected to be direct consumers of this header 142 field. This header field is intended for consumption by programs 143 that will then use or render such data in a human-usable form. 145 This document specifies both the format of this header field and 146 discusses the implications of its presence or absence. However, it 147 does not discuss how the data contained in the header field ought to 148 be used (i.e. what filtering decisions are appropriate, or how an MUA 149 might render those results) as these are local policy and/or user 150 interface design questions that are not appropriate for this 151 document. 153 At the time of publication of this document, Author Domain Signing 154 Practices ([ADSP]), SMTP Service Extension for Authentication 155 ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender 156 Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are 157 published DNS domain-level email authentication methods in common 158 use. DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also 159 referenced here, though they respectively have "Historic" and 160 "Experimental" status, and are no longer common. 162 This proposal is not intended to be restricted to domain-based 163 authentication, but this has proven to be a good starting point for 164 implementations. As various methods emerge, it is necessary to 165 prepare for their appearance and encourage convergence in the area of 166 interfacing verifiers to filters and MUAs. 168 Although SPF defined a header field called "Received-SPF" and 169 DomainKeys defined one called "DomainKey-Status" for this purpose, 170 those header fields are specific to the conveyance of their 171 respective results only and thus are insufficient to satisfy the 172 requirements enumerated below. In addition, many SPF implementations 173 have adopted the header field specified below, and DomainKeys has 174 been obsoleted by DKIM. 176 1.1. Purpose 178 The header field defined in this document is expected to serve 179 several purposes: 181 1. Convey the results of various message authentication checks being 182 applied by upstream filters and Mail Transfer Agents (MTAs) to 183 MUAs and downstream filters within the same "trust domain", as 184 such agents may wish to render those results to end users or use 185 that data to apply more or less stringent content checks based on 186 authentication results; 188 2. Provide a common location within a message for this data; 190 3. Create an extensible framework for reporting new authentication 191 methods as they emerge. 193 In particular, the mere presence of this header field SHOULD NOT be 194 construed as meaning that its data is valid, but rather that it is 195 asserting some kind of validity based on one or more authentication 196 schemes applied somewhere upstream. For an MUA or downstream filter 197 to treat the assertions as actually valid, there must be an 198 assessment of the trust relationship between such agents and the 199 validating MTA. 201 1.2. Trust Boundary 203 This document makes several references to the "trust boundary" of an 204 administrative management domain (ADMD). Given the diversity among 205 existing mail environments, a precise definition of this term isn't 206 possible. 208 Simply put, a transfer from the creator of the header field to the 209 consumer must occur within a context of trust that the creator's 210 information is correct. How this trust is obtained is outside the 211 scope of this document. It is entirely a local matter. 213 Thus, this document defines a "trust boundary" as the delineation 214 between "external" and "internal" entities; "external" here includes 215 all hosts that do not deliberately provide some kind of messaging 216 service for the receiving ADMD's users, and "internal" includes those 217 hosts that do. By this definition, the hosts within a "trust 218 boundary" may lie entirely within a receiving ADMD's direct control, 219 or they can include hosts managed by another ADMD (such as an ISP or 220 commercial filtering service) but that also provide services for the 221 former. 223 1.3. Processing Scope 225 This specification is intended to address the needs of authenticating 226 messages or properties of messages during their actual transport. It 227 is not meant to address the security of messages that might be 228 encapsulated within other messages, such as a message/rfc822 (see 229 Multipurpose Internet Mail Extensions [MIME]) part within a message. 231 1.4. Requirements 233 This document establishes no new requirements on existing protocols 234 or servers. 236 In particular, this document establishes no requirement on MTAs to 237 reject or filter arriving messages that do not pass authentication 238 checks. The data conveyed by the specified header field's contents 239 are for the information of MUAs and filters and are to be used at 240 their discretion. 242 1.5. Definitions 244 This section defines various terms used throughout this document. 246 1.5.1. Key Words 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [KEYWORDS]. 252 1.5.2. Security 254 Guidelines for Writing RFC Text on Security Considerations 255 ([SECURITY]) discusses authentication and authorization and the 256 conflation of the two concepts. The use of those terms within the 257 context of recent message security work has given rise to slightly 258 different definitions, and this document reflects those current 259 usages, as follows: 261 o "Authorization" is the establishment of permission to use a 262 resource or represent an identity. In this context, authorization 263 indicates that a message from a particular ADMD arrived via a 264 route the ADMD has explicitly approved. 266 o "Authentication" is the assertion of validity of a piece of data 267 about a message (such as the sender's identity) or the message in 268 its entirety. 270 As examples: SPF and Sender-ID are authorization mechanisms in that 271 they express a result that shows whether or not the ADMD that 272 apparently sent the message has explicitly authorized the connecting 273 Simple Mail Transfer Protocol ([SMTP]) client to relay messages on 274 its behalf, but do not actually validate any property of the message 275 itself. By contrast, DKIM is agnostic as to the routing of a message 276 but uses cryptographic signatures to authenticate agents claiming 277 responsibility for the message (which implies authorization) and 278 ensure it was not modified in transit. Since the signatures are not 279 tied to SMTP connections, they can be added by either the ADMD of 280 origin, intermediate ADMDs (such as a mailing list server), or both. 282 Rather than create a separate header field for each class of 283 solution, this proposal groups them both into a single header field. 285 1.5.3. Email Architecture 287 o A "border MTA" is an MTA that acts as a gateway between the 288 general Internet and the users within an organizational boundary. 289 (See also Section 1.2.) 291 o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that 292 actually enacts delivery of a message to a user's inbox or other 293 final delivery. 295 o An "intermediate MTA" is an MTA that handles messages after a 296 border MTA and before a delivery MTA. 298 The following diagram illustrates the flow of mail among these 299 defined components: 301 +-----+ +-----+ +------------+ 302 | MUA |-->| MSA |-->| Border MTA | 303 +-----+ +-----+ +------------+ 304 | 305 | 306 V 307 +----------+ 308 | Internet | 309 +----------+ 310 | 311 | 312 V 313 +-----+ +-----+ +------------------+ +------------+ 314 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 315 +-----+ +-----+ +------------------+ +------------+ 317 Generally, it is assumed that the work of applying message 318 authentication schemes takes place at a border MTA or a delivery MTA. 319 This specification is written with that assumption in mind. However, 320 there are some sites at which the entire mail infrastructure consists 321 of a single host. In such cases, such terms as "border MTA" and 322 "delivery MTA" might well apply to the same machine or even the very 323 same agent. It is also possible that some message authentication 324 tests could take place on an intermediate MTA. Although this 325 document doesn't specifically describe such cases, they are not meant 326 to be excluded. 328 See Internet Mail Architecture ([EMAIL-ARCH]) for further discussion 329 on general email system architecture, and Appendix D of this document 330 for discussion about the common aspects of email authentication in 331 current environments. 333 1.6. Trust Environment 335 This header field permits one or more message validation mechanisms 336 to communicate output to one or more separate assessment mechanisms. 337 These mechanisms operate within a unified trust boundary that defines 338 an Administrative Management Domain (ADMD). An ADMD contains one or 339 more entities that perform validation and generate the header field, 340 and one or more that consume it for some type of assessment. The 341 field contains no integrity or validation mechanism of its own, so 342 its presence must be trusted implicitly. Hence, use of the header 343 field depends upon ensuring that mail entering the ADMD has instances 344 of the header field claiming to be valid within its boundaries 345 removed, so that occurrences of such header fields can be used safely 346 by consumers. 348 The "authserv-id" token defined in Section 2.2 can be used to label 349 an entire ADMD or a specific validation engine within an ADMD. 350 Although the labeling scheme is left as an operational choice, some 351 guidance for selecting a token is provided in later sections of this 352 document. 354 2. Definition and Format of the Header Field 356 This section gives a general overview of the format of the header 357 field being defined, and then provides more formal specification. 359 2.1. General Description 361 The header field specified here is called "Authentication-Results". 362 It is a Structured Header Field as defined in Internet Message Format 363 ([MAIL]) and thus all of the related definitions in that document 364 apply. 366 This header field is added at the top of the message as it transits 367 MTAs that do authentication checks so some idea of how far away the 368 checks were done can be inferred. It is therefore considered to be a 369 Trace Field as defined in [MAIL], and thus all of the related 370 definitions in that document apply. 372 The value of the header field (after removing comments) consists of 373 an authentication identifier, an optional version, and then a series 374 of "method=result" statements indicating which authentication 375 method(s) were applied and their respective results, and then, for 376 each applied method, an optional "reason" string, plus optional 377 "property=value" statements indicating which message properties were 378 evaluated to reach that conclusion. 380 The header field can appear more than once in a single message, or 381 more than one result MAY be represented in a single header field, or 382 a combination of these MAY be applied. 384 2.2. Formal Definition 386 Formally, the header field is specified as follows using Augmented 387 Backus-Naur Form ([ABNF]): 389 authres-header = "Authentication-Results:" [CFWS] authserv-id 390 [ [CFWS] "/" [CFWS] authres-version ] 391 ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF 392 ; the special case of "none" is used to indicate that no 393 ; message authentication is performed 395 authserv-id = value 396 ; see below for a description of this element 398 authres-version = 1*DIGIT [CFWS] 399 ; indicates which version of this specification is in use; 400 ; this specification is version "1", and the absence of a 401 ; version implies this version of the specification 403 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 404 *( CFWS propspec ) 406 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 407 ; indicates which authentication method was evaluated 408 ; and what its output was 410 reasonspec = "reason" [CFWS] "=" [CFWS] value 411 ; a free-form comment on the reason the given result 412 ; was returned 414 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 415 ; an indication of which properties of the message 416 ; were evaluated by the authentication scheme being 417 ; applied to yield the reported result, and would be 418 ; useful to reveal to end users as authenticated 420 method = Keyword [ [CFWS] "/" [CFWS] method-version ] 421 ; a method indicates which method's result is 422 ; represented by "result", and is one of the methods 423 ; explicitly defined as valid in this document 424 ; or is an extension method as defined below 426 method-version = 1*DIGIT [CFWS] 427 ; indicates which version of the method specification is 428 ; in use, corresponding to the matching entry in the IANA 429 ; Email Authentication Methods registry; a value of "1" 430 ; is assumed if this version string is absent 432 result = Keyword 433 ; indicates the results of the attempt to authenticate 434 ; the message; see below for details 436 ptype = "smtp" / "header" / "body" / "policy" 437 ; indicates whether the property being evaluated was 438 ; a parameter to an [SMTP] command, or was a value taken 439 ; from a message header field, or was some property of 440 ; the message body, or some other property evaluated by 441 ; the receiving MTA 443 special-smtp-verb = "mailfrom" / "rcptto" 444 ; special cases of [SMTP] commands that are made up 445 ; of multiple words 447 property = special-smtp-verb / Keyword 448 ; if "ptype" is "smtp", this indicates which [SMTP] 449 ; command provided the value that was evaluated by the 450 ; authentication scheme being applied; if "ptype" is 451 ; "header", this indicates from which header field the 452 ; value being evaluated was extracted; if "ptype" is 453 ; "body", this indicates where in the message body 454 ; a value being evaluated can be found (e.g., a specific 455 ; offset into the message or a reference to a MIME part); 456 ; if "ptype" is "policy" then this indicates the name 457 ; of the policy that caused this header field to be 458 ; added (see below) 460 pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) 461 [CFWS] 463 ; the value extracted from the message property defined 464 ; by the "ptype.property" construction; if the value 465 ; identifies something intended to be an e-mail identity, 466 ; then it MUST use the right hand portion of this ABNF 467 ; definition 469 "local-part" is defined in Section 3.4.1, and "CFWS" is defined in 470 Section 3.2.2, of [MAIL]. 472 "Keyword" is defined in Section 4.1.2 of [SMTP]. 474 The "value" is as defined in Section 5.1 of [MIME]. 476 The "domain-name" is as defined in Section 3.5 of [DKIM]. 478 The "Keyword" used in "result" above is further constrained by the 479 necessity of being enumerated in Section 2.5 or an amendment to it. 481 See Section 2.3 for a description of the "authserv-id" element. 483 The list of commands eligible for use with the "smtp" ptype can be 484 found in [SMTP] and subsequent amendments. 486 The "propspec" may be omitted if, for example, the method was unable 487 to extract any properties to do its evaluation yet has a result to 488 report. 490 The "ptype" and "property" values used by each authentication method 491 MUST be defined in the specification for that method (or its 492 amendments). 494 Where an SMTP command is being reported as a "property", the MAIL 495 FROM command MUST be represented by "mailfrom" and the RCPT TO 496 command MUST be represented by "rcptto". All other SMTP commands 497 MUST be represented unchanged. 499 A "ptype" value of "policy" indicates a policy decision about the 500 message not specific to a property of the message that could be 501 extracted. For example, if a method would normally report a 502 "ptype.property" of "header.From" and no From: header field was 503 present, the method can use "policy" to indicate that no conclusion 504 about the authenticity of the message could be reached. 506 2.3. Authentication Identifier Field 508 Every Authentication-Results header field has an authentication 509 service identifier field ("authserv-id" above). Generally, this is 510 an arbitrary string intended to identify the authentication service 511 within the ADMD that conducted authentication checks on the message. 512 This identifier is intended to be machine-readable and not 513 necessarily meaningful to users. 515 Since agents consuming this field will use this identifier to 516 determine whether its contents are of interest (and are safe to use), 517 the uniqueness of the identifier MUST be guaranteed by the ADMD that 518 generates it and MUST pertain to exactly that one ADMD. MUAs or 519 downstream filters SHOULD use this identifier to determine whether or 520 not the data contained in an Authentication-Results header field 521 ought to be used or ignored. 523 For simplicity and scalability, the authentication service identifier 524 SHOULD be a common token used throughout the ADMD. Common practice 525 is to use the DNS domain name used by or within that ADMD, but this 526 is not strictly necessary. 528 For tracing and debugging purposes, the authentication identifier MAY 529 instead be the hostname of the MTA performing the authentication 530 check whose result is being reported. This is also useful for 531 another purpose, as described in Section 4. Moreover, some 532 implementations have considered appending a delimiter such as "/" and 533 following it with useful transport tracing data such as the SMTP 534 queue ID or a timestamp. 536 Note, however, that using a local, relative identifier like a single 537 hostname, rather than a hierarchical and globally unique ADMD 538 identifier like a DNS domain name, makes configuration more difficult 539 for large sites. The hierarchical identifier permits aggregating 540 related, trusted systems together under a single, parent identifier, 541 which in turn permits assessing the trust relationship with a single 542 reference. The alternative is a flat namespace requiring 543 individually listing each trusted system. Since consumers will use 544 the identifier to determine whether to use the contents of the header 545 field: 547 o Changes to the identifier impose a large, centralized 548 administrative burden. 550 o Ongoing administrative changes require constantly updating this 551 centralized table, making it difficult to ensure that an MUA or 552 downstream filter will have access to accurate information for 553 assessing the usability of the header field's content. In 554 particular, consumers of the header field will need to know not 555 only the current identifier(s) in use, but previous ones as well 556 to account for delivery latency or later re-assessment of the 557 header field's contents. 559 Examples of valid authentication identifiers are "example.com", 560 "mail.example.org", "ms1.newyork.example.com", and "example-auth". 562 2.4. Version Tokens 564 The grammar above provides for the optional inclusion of versions on 565 both the header field itself (attached to the authserv-id token) and 566 on each of the methods being reported. The method version refers to 567 the method itself, which is specified in the documents describing 568 those methods, while the authserv-id version refers to this document 569 and thus the syntax of this header field. 571 The purpose of including these is to avoid misinterpretation of the 572 results. That is, if a parser finds a version after an authserv-id 573 that it does not explicitly know, it can immediately discontinue 574 trying to parse since what follows might not be in an expected 575 format. For a method version, the parser SHOULD ignore a method 576 result if the version is not supported in case the semantics of the 577 result have a different meaning than what is expected. For example, 578 if a hypothetical DKIM version 2 yielded a "pass" result for 579 different reasons than version 1 does, a consumer of this field might 580 not want to use the altered semantics. Allowing versions in the 581 syntax is a way to indicate this and let the consumer of the header 582 field decide. 584 2.5. Result Values 586 Each individual authentication method returns one of a set of 587 specific result values. The subsections below define these results 588 for the authentication methods specifically supported by this 589 document, and verifiers SHOULD use these values as described below. 590 New methods not specified in this document intended to be supported 591 by the header field defined here MUST include a similar result table 592 either in its defining document or in a supplementary one. 594 2.5.1. DKIM and DomainKeys Results 596 The result values used by DKIM and DomainKeys are as follows: 598 none: The message was not signed. 600 pass: The message was signed, the signature or signatures were 601 acceptable to the verifier, and the signature(s) passed 602 verification tests. 604 fail: The message was signed and the signature or signatures were 605 acceptable to the verifier, but they failed the verification 606 test(s). 608 policy: The message was signed but the signature or signatures were 609 not acceptable to the verifier. 611 neutral: The message was signed but the signature or signatures 612 contained syntax errors or were not otherwise able to be 613 processed. This result SHOULD also be used for other failures not 614 covered elsewhere in this list. 616 temperror: The message could not be verified due to some error that 617 is likely transient in nature, such as a temporary inability to 618 retrieve a public key. A later attempt may produce a final 619 result. 621 permerror: The message could not be verified due to some error that 622 is unrecoverable, such as a required header field being absent. A 623 later attempt is unlikely to produce a final result. 625 A signature is "acceptable to the verifier" if it passes local policy 626 checks (or there are no specific local policy checks). For example, 627 a verifier might require that the signature(s) on the message be 628 added using the DNS domain present in the From: header field of the 629 message, thus making third-party signatures unacceptable. 631 [DKIM] advises that if a message fails verification, it is to be 632 treated as an unsigned message. A report of "fail" here permits the 633 receiver of the report to decide how to handle the failure. A report 634 of "neutral" or "none" preempts that choice, ensuring the message 635 will be treated as if it had not been signed. 637 2.5.2. SPF and Sender-ID Results 639 The result values for SPF are defined in [SPF], and those definitions 640 are included here by reference. They are used in the context of this 641 specification to reflect the result returned by the component 642 conducting SPF evaluation. Similarly, the results for Sender-ID are 643 listed and described in [SENDERID]. The values are case-insensitive, 644 but are typically used all-lowercase in this context. 646 In both cases, an additional result of "policy" is defined, which 647 means the client is authorized to inject or relay mail on behalf of 648 the sender's DNS domain according to the authentication method's 649 algorithm, but local policy dictates that the result is unacceptable, 650 such as, for example, SPF returned as "pass" result, but a local 651 policy check matches the sending DNS domain to one found in an 652 explicit list of unacceptable DNS domains (e.g., spammers). 654 If the retrieved sender policies used to evaluate SPF and Sender ID 655 do not contain explicit provisions for authenticating the local-part 656 (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported 657 along with results for these mechanisms SHOULD NOT include the local- 658 part. 660 2.5.3. "iprev" Results 662 The result values are used by the "iprev" method, defined in 663 Section 3, are as follows: 665 pass: The DNS evaluation succeeded, i.e., the "reverse" and 666 "forward" lookup results were returned and were in agreement. 668 fail: The DNS evaluation failed. In particular, the "reverse" and 669 "forward" lookups each produced results but they were not in 670 agreement, or the "forward" query completed but produced no 671 result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an 672 RCODE of 0 (NOERROR) in a reply containing no answers, was 673 returned. 675 temperror: The DNS evaluation could not be completed due to some 676 error that is likely transient in nature, such as a temporary DNS 677 error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or 678 other error condition resulted. A later attempt may produce a 679 final result. 681 permerror: The DNS evaluation could not be completed because no PTR 682 data are published for the connecting IP address, e.g., a DNS 683 RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) 684 in a reply containing no answers, was returned. This prevented 685 completion of the evaluation. A later attempt is unlikely to 686 produce a final result. 688 There is no "none" for this method since any TCP connection 689 delivering email has an IP address associated with it, so some kind 690 of evaluation will always be possible. 692 For discussion of the format of DNS replies, see Domain Names - 693 Implementation And Specification ([DNS]). 695 2.5.4. SMTP AUTH Results 697 The result values are used by the "auth" method are as follows: 699 none: SMTP authentication was not attempted. 701 pass: The SMTP client had authenticated to the server reporting the 702 result using the protocol described in [AUTH]. 704 fail: The SMTP client had attempted to authenticate to the server 705 using the protocol described in [AUTH] but was not successful, yet 706 continued to send the message about which a result is being 707 reported. 709 temperror: The SMTP client attempted to authenticate using the 710 protocol described in [AUTH] but was not able to complete the 711 attempt due to some error which is likely transient in nature, 712 such as a temporary Lightweight Directory Access Protocol (LDAP) 713 lookup error. A later attempt may produce a final result. 715 permerror: The SMTP client attempted to authenticate using the 716 protocol described in [AUTH] but was not able to complete the 717 attempt due to some error that is likely not transient in nature, 718 such as a permanent LDAP lookup error. A later attempt is not 719 likely produce a final result. 721 Note that an agent making use of the data provided by this header 722 field SHOULD consider "fail" and "temperror" to be the synonymous in 723 terms of message authentication, i.e., the client did not 724 authenticate. 726 2.5.5. Extension Result Codes 728 Additional result codes (extension results) might be defined in the 729 future by later revisions or extensions to this specification. 730 Result codes MUST be registered with the Internet Assigned Numbers 731 Authority (IANA) and preferably published in an RFC. See Section 6 732 for further details. 734 Extension results MUST only be used within ADMDs that have explicitly 735 consented to use them. These results and the parameters associated 736 with them are not formally documented. Therefore, they are subject 737 to change at any time and not suitable for production use. Any MTA, 738 MUA or downstream filter intended for production use SHOULD ignore or 739 delete any Authentication-Results header field that includes an 740 extension result. 742 2.6. Authentication Methods 744 This section defines the supported authentication methods and 745 discusses the proper means for applying experimental and other 746 extension methods. 748 2.6.1. Definitions for Existing Methods 750 As they are currently existing specifications for message 751 authentication, it is appropriate to define an authentication method 752 identifier for each of ADSP, Authorized Third-Party Signatures 753 ([ATPS]), SMTP Authentication, DKIM, DomainKeys, Sender ID, SPF and 754 VBR. Therefore, the authentication method identifiers "dkim-adsp", 755 "dkim-atps", "auth", "dkim", "domainkeys", "sender-id", "spf", and 756 "vbr", respectively are defined for MTAs applying those 757 specifications for email message authentication. 759 Furthermore, method "iprev" is defined in Section 3. 761 See Section 6 for details. 763 2.6.2. Extension Methods 765 Additional authentication method identifiers (extension methods) may 766 be defined in the future by later revisions or extensions to this 767 specification. Method identifiers MUST be registered with the 768 Internet Assigned Numbers Authority (IANA) and, preferably, published 769 in an RFC. See Section 6 for further details. 771 Extension methods can be defined for the following reasons: 773 1. To allow additional information from new authentication systems 774 to be communicated to MUAs or downstream filters. The names of 775 such identifiers SHOULD reflect the name of the method being 776 defined, but ought not be needlessly long. 778 2. To allow the creation of "sub-identifiers" that indicate 779 different levels of authentication and differentiate between 780 their relative strengths, e.g., "auth1-weak" and "auth1-strong". 782 Authentication method implementers are encouraged to provide adequate 783 information, via message header field comments if necessary, to allow 784 an MUA developer to understand or relay anciliary details of 785 authentication results. For example, if it might be of interest to 786 relay what data was used to perform an evaluation, such information 787 could be relayed as a comment in the header field, such as: 789 Authentication-Results: example.com; 790 foo=pass bar.baz=blob (2 of 3 tests OK) 792 Experimental method identifiers MUST only be used within ADMDs that 793 have explicitly consented to use them. These method identifiers and 794 the parameters associated with them are not documented in RFCs. 795 Therefore, they are subject to change at any time and not suitable 796 for production use. Any MTA, MUA, or downstream filter intended for 797 production use SHOULD ignore or delete any Authentication-Results 798 header field that includes an experimental (unknown) method 799 identifier. 801 3. The "iprev" Authentication Method 803 This section defines an additional authentication method called 804 "iprev". 806 In general, "iprev" is an attempt to verify that a client appears to 807 be valid based on some DNS queries. Upon receiving a session 808 initiation of some kind from a client, the IP address of the client 809 peer is queried for matching names (i.e., a number-to-name 810 translation, also known as a "reverse lookup" or a "PTR" record 811 query). Once that result is acquired, a lookup of each of the names 812 (i.e., a name-to-number translation, or an "A" or "AAAA" record 813 query) thus retrieved is done. The response to this second check 814 will typically result in at least one mapping back to the client's IP 815 address. 817 Expressed as an algorithm: If the client peer's IP address is I, the 818 list of names to which I maps (after a "PTR" query) is the set N, and 819 the union of IP addresses to which each member of N maps (after 820 corresponding "A" and "AAAA" queries) is L, then this test is 821 successful if I is an element of L. 823 The response to a PTR query could contain multiple names. To prevent 824 heavy DNS loads, agents performing these queries MUST be implemented 825 such that the number of names evaluated by generation of 826 corresponding A or AAAA queries is finite, though it MAY be 827 configurable by an administrator. As an example, Section 5.5 of 828 [SPF] chose a limit of 10 for its implementation of this algorithm. 830 DNS Extensions to Support IP Version 6 ([DNS-IP6]) discusses the 831 query formats for the IPv6 case. 833 A successful test using this algorithm constitutes a result of "pass" 834 since the ADMD in which the client's PTR claims it belongs has 835 confirmed that claim by including corresponding data in its DNS 836 domain. A failure to match constitutes a "fail". There is no case 837 in which a "neutral" result can be returned. The remaining 838 "temperror" and "permerror" cases refer, respectively, to temporary 839 and permanent DNS query errors. 841 There is some contention regarding the wisdom and reliability of this 842 test. For example, in some regions it can be difficult for this test 843 ever to pass because the practice of arranging to match the forward 844 and reverse DNS is infrequently observed. Therefore, the precise 845 implementation details of how a verifier performs an "iprev" test are 846 not specified here. The verifier MAY report a successful or failed 847 "iprev" test at its discretion having done some kind of check of the 848 validity of the connection's identity using DNS. It is incumbent 849 upon an agent making use of the reported "iprev" result to understand 850 what exactly that particular verifier is attempting to report. 852 Extensive discussion of reverse DNS mapping and its implications can 853 be found in Considerations for the use of DNS Reverse Mapping 854 ([DNSOP-REVERSE]). In particular, it recommends that applications 855 avoid using this test as a means of authentication or security. Its 856 presence in this document is not an endorsement, but is merely 857 acknowledgement that the method remains common and provides the means 858 to relay the results of that test. 860 4. Adding the Header Field to A Message 862 This specification makes no attempt to evaluate the relative 863 strengths of various message authentication methods that may become 864 available. As such, the order of the presented authentication 865 methods and results MUST NOT be used either to imply or infer the 866 importance or strength of any given method over another. Instead, 867 the MUA or downstream filter consuming this header field is to 868 interpret the result of each method based on its own knowledge of 869 what that method evaluates. 871 Each "method" MUST refer to an authentication method declared in the 872 IANA registry, or an extension method as described in Section 2.6.2, 873 and each "result" MUST refer to a result code declared in the IANA 874 registry, or an extension result code as defined in Section 2.5.5. 875 See Section 6 for further information about the registered methods 876 and result codes. 878 An MTA compliant with this specification MUST add this header field 879 (after performing one or more message authentication tests) to 880 indicate which MTA or ADMD performed the test, which test got applied 881 and what the result was. If an MTA applies more than one such test, 882 it MUST add this header field either once per test, or once 883 indicating all of the results. An MTA MUST NOT add a result to an 884 existing header field. 886 An MTA MAY add this header field containing only the authentication 887 identifier portion and the "none" token (see Section 2.2) to indicate 888 explicitly that no message authentication schemes were applied prior 889 to delivery of this message. 891 An MTA adding this header field MUST take steps to identify it as 892 legitimate to the MUAs or downstream filters that will ultimately 893 consume its content. One REQUIRED process to do so is described in 894 Section 5. Further measures may be necessary in some environments. 895 Some possible solutions are enumerated in Section 7.1. This document 896 does not mandate any specific solution to this issue as each 897 environment has its own facilities and limitations. 899 For MTAs that add this header field, adding header fields in order 900 (at the top), per Section 3.6 of [MAIL], is particularly important. 901 Moreover, this header field SHOULD be inserted above any other trace 902 header fields such MTAs might prepend. This allows easy detection of 903 header fields that can be trusted. 905 The set of message properties registered for a given method, upon 906 which the reported result is based, can be numerous. However, the 907 ones included in the header field being generated SHOULD NOT include 908 any that were not included in the computation of the result. Doing 909 so can confound consumers of the field when the method includes 910 multiple evaluation methods. For example, SPF can base its 911 conclusion on the RFC5321.Helo parameter or on the RFC5321.MailFrom 912 domain; including both of those in the header field makes it 913 impossible for the consumer to determine which property of the 914 message envelope was actually used. 916 End users making direct use of this header field might inadvertently 917 trust information that has not been properly vetted. If, for 918 example, a basic SPF result were to be relayed that claims an 919 authenticated addr-spec, the local-part of that addr-spec has 920 actually not been authenticated. Thus, an MTA adding this header 921 field SHOULD NOT include any data that has not been authenticated by 922 the method(s) being applied. Moreover, MUAs SHOULD NOT render to 923 users such information if it is presented by a method known not to 924 authenticate it. 926 4.1. Header Field Position and Interpretation 928 In order to ensure non-ambiguous results and avoid the impact of 929 false header fields, MUAs and downstream filters SHOULD NOT interpret 930 this header field unless specifically instructed to do so by the user 931 or administrator. That is, this interpretation should not be "on by 932 default". Naturally then, users or administrators ought not activate 933 such a feature unless they are certain the header field will be added 934 by the border MTA that accepts the mail that is ultimately read by 935 the MUA, and instances of the header field appearing to originate 936 within the ADMD but are actually added by foreign MTAs will be 937 removed before delivery. 939 Furthermore, MUAs and downstream filters SHOULD NOT interpret this 940 header field unless the authentication service identifier it bears 941 appears to be one used within its own ADMD as configured by the user 942 or administrator. 944 MUAs and downstream filters MUST ignore any result reported using a 945 "result" not specified in the result code registry, or a "ptype" not 946 listed in the corresponding registry for such values as defined in 947 Section 6. Moreover, such agents MUST ignore a result indicated for 948 any "method" they do not specifically support. 950 An MUA SHOULD NOT reveal these results to end users unless the 951 results are accompanied by, at a minimum, some associated reputation 952 data about the authenticated origin identifiers within the message. 953 For example, an attacker could register examp1e.com (note the digit 954 "one") and send signed mail to intended victims; a verifier would 955 detect that the signature was valid and report a "pass" even though 956 it's clear the DNS domain name was intended to mislead. See 957 Section 7.2 for further discussion. 959 As stated in Section 2.1, this header field SHOULD be treated as 960 though it were a trace header field as defined in Section 3.6.7 of 961 [MAIL], and hence MUST NOT be reordered and MUST be prepended to the 962 message, so that there is generally some indication upon delivery of 963 where in the chain of handling MTAs the message authentication was 964 done. 966 MUAs SHOULD ignore instances of this header field discovered within 967 message/rfc822 MIME attachments. 969 Further discussion of this can be found in Section 7 below. 971 4.2. Local Policy Enforcement 973 If a site's local policy is to consider a non-recoverable failure 974 result (typically "fail" or similar) for any particular 975 authentication method as justification to reject the message 976 completely, the border MTA SHOULD issue an [SMTP] rejection response 977 to the message rather than adding this header field with the failure 978 result and allowing it to proceed toward delivery. This is more 979 desirable than allowing the message to reach an internal host's MTA 980 or spam filter, thus possibly generating a local rejection such as a 981 [DSN] to a forged originator. Such generated rejections are 982 colloquially known as "backscatter". 984 The same MAY also be done for local policy decisions overriding the 985 results of the authentication methods (e.g., the "policy" result 986 codes described in Section 2.5). 988 Such rejections at the SMTP protocol level are not possible if local 989 policy is enforced at the MUA and not the MTA. 991 5. Removing the Header Field 993 For security reasons, any MTA conforming to this specification MUST 994 delete any discovered instance of this header field that claims, by 995 virtue of its authentication service identifier, to have been added 996 within its trust boundary and that did not come directly from another 997 trusted MTA. For example, an MTA for example.com receiving a message 998 MUST delete or otherwise obscure any instance of this header field 999 bearing an authentication service identifier indicating the header 1000 field was added within example.com prior to adding its own header 1001 fields. This could mean each MTA will have to be equipped with a 1002 list of internal MTAs known to be compliant (and hence trustworthy). 1004 For simplicity and maximum security, a border MTA MAY remove all 1005 instances of this header field on mail crossing into its trust 1006 boundary. However, this may conflict with the desire to access 1007 authentication results performed by trusted external service 1008 providers. It may also invalidate signed messages whose signatures 1009 cover external instances of this header field. A more robust border 1010 MTA could allow a specific list of authenticating MTAs whose 1011 information is to be admitted, removing all others. 1013 As stated in Section 1.2, a formal definition of "trust boundary" is 1014 deliberately not made here. It is entirely possible that a border 1015 MTA for example.com will explicitly trust authentication results 1016 asserted by upstream host example.net even though they exist in 1017 completely disjoint administrative boundaries. In that case, the 1018 border MTA MAY elect not to delete those results; moreover, the 1019 upstream host doing some authentication work could apply a signing 1020 technology such as [DKIM] on its own results to assure downstream 1021 hosts of their authenticity. An example of this is provided in 1022 Appendix C. 1024 Similarly, in the case of messages signed using [DKIM] or other 1025 message signing methods that sign header fields, this removal action 1026 could invalidate one or more signatures on the message if they 1027 covered the header field to be removed. This behavior can be 1028 desirable since there's little value in validating the signature on a 1029 message with forged header fields. However, signing agents MAY 1030 therefore elect to omit these header fields from signing to avoid 1031 this situation. 1033 An MTA SHOULD remove any instance of this header field bearing a 1034 version (express or implied) that it does not support. However, an 1035 MTA MUST remove such a header field if the [SMTP] connection relaying 1036 the message is not from a trusted internal MTA. 1038 6. IANA Considerations 1040 IANA has registered the defined header field and created two tables 1041 as described below. These registry actions were originally defined 1042 by [RFC5451] and are repeated here to provide a single, current 1043 reference. 1045 6.1. The Authentication-Results Header Field 1047 [RFC5451] added the "Authentication-Results" header field to the IANA 1048 Permanent Message Header Field Registry, per the procedure found in 1049 [IANA-HEADERS]. That entry is to be updated to reference this 1050 document. The following is the registration template: 1052 Header field name: Authentication-Results 1053 Applicable protocol: mail ([MAIL]) 1054 Status: Standard 1055 Author/Change controller: IETF 1056 Specification document(s): [this memo] 1057 Related information: 1058 Requesting review of any proposed changes and additions to 1059 this field is recommended. 1061 6.2. Email Authentication Method Name Registry 1063 Names of message authentication methods supported by this 1064 specification are to be registered with IANA, with the exception of 1065 experimental names as described in Section 2.6.2. A registry was 1066 created by [RFC5451] for this purpose. This document changes the 1067 rules governing that registry. 1069 New entries are assigned only for values that have received Expert 1070 Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be 1071 appointed by the IESG. The Designated Expert has discretion to 1072 request that a publication be referenced if a clear, concise 1073 definition of the authentication method cannot be provided such that 1074 interoperability is assured. Registrations should otherwise be 1075 permitted. The Designated Expert can also handle requests to mark 1076 any current registration as "deprecated". 1078 Each method must register a name, the specification that defines it, 1079 a version number associated with the method being registered 1080 (preferably starting at "1"), and zero or more "ptype" values 1081 appropriate for use with that method, which "property" value(s) 1082 should be reported by that method, and a description of the "value" 1083 to be used with each. 1085 All existing registry entries that reference [RFC5451] are to be 1086 updated to reference this document. [RFC Editor note: Section 1087 numbers may have to change as well since they appear in the registry, 1088 but numbering may change between now and publication. We can deal 1089 with this during the IANA phase and/or AUTH48.]. 1091 IANA is also requested to add a "version" field to all existing 1092 registry entries. All current methods are to be recorded as version 1093 "1". 1095 6.3. Email Authentication Result Name Registry 1097 Names of message authentication result codes supported by this 1098 specification must be registered with IANA, with the exception of 1099 experimental codes as described in Section 2.5.5. A registry was 1100 created by [RFC5451] for this purpose. This document changes the 1101 rules governing that registry. 1103 New entries are assigned only for values that have received Expert 1104 Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be 1105 appointed by the IESG. The Designated Expert has discretion to 1106 request that a publication be referenced if a clear, concise 1107 definition of the authentication result cannot be provided such that 1108 interoperability is assured. Registrations should otherwise be 1109 permitted. The Designated Expert can also handle requests to mark 1110 any current registration as "deprecated". 1112 All existing registry entries that reference [RFC5451] are to be 1113 updated to reference this document. 1115 7. Security Considerations 1117 The following security considerations apply when adding or processing 1118 the "Authentication-Results" header field: 1120 7.1. Forged Header Fields 1122 An MUA or filter that accesses a mailbox whose mail is handled by a 1123 non-conformant MTA, and understands Authentication-Results header 1124 fields, could potentially make false conclusions based on forged 1125 header fields. A malicious user or agent could forge a header field 1126 using the DNS domain of a receiving ADMD as the authserv-id token in 1127 the value of the header field, and with the rest of the value claim 1128 that the message was properly authenticated. The non-conformant MTA 1129 would fail to strip the forged header field, and the MUA could 1130 inappropriately trust it. 1132 It is for this reason an MUA should not have processing of the 1133 "Authentication-Results" header field enabled by default; instead it 1134 should be ignored, at least for the purposes of enacting filtering 1135 decisions, unless specifically enabled by the user or administrator 1136 after verifying that the border MTA is compliant. It is acceptable 1137 to have an MUA aware of this specification, but have an explicit list 1138 of hostnames whose "Authentication-Results" header fields are 1139 trustworthy; however, this list should initially be empty. 1141 Proposed alternate solutions to this problem are nascent: 1143 1. Possibly the simplest is a digital signature protecting the 1144 header field, such as using [DKIM], that can be verified by an 1145 MUA by using a posted public key. Although one of the main 1146 purposes of this document is to relieve the burden of doing 1147 message authentication work at the MUA, this only requires that 1148 the MUA learn a single authentication scheme even if a number of 1149 them are in use at the border MTA. Note that [DKIM] requires 1150 that the From header field be signed, although in this 1151 application, the signing agent (a trusted MTA) likely cannot 1152 authenticate that value, so the fact that it is signed should be 1153 ignored. 1155 2. Another would be a means to interrogate the MTA that added the 1156 header field to see if it is actually providing any message 1157 authentication services and saw the message in question, but this 1158 isn't especially palatable given the work required to craft and 1159 implement such a scheme. 1161 3. Yet another might be a method to interrogate the internal MTAs 1162 that apparently handled the message (based on Received: header 1163 fields) to determine whether any of them conform to Section 5 of 1164 this memo. This, too, has potentially high barriers to entry. 1166 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to 1167 allow an MUA or filtering agent to acquire the "authserv-id" in 1168 use within an ADMD, thus allowing it to identify which 1169 Authentication-Results header fields it can trust. 1171 5. On the presumption that internal MTAs are fully compliant with 1172 Section 3.6 of [MAIL], and the compliant internal MTAs are using 1173 their own host names or the ADMD's DNS domain name as the 1174 "authserv-id" token, the header field proposed here should always 1175 appear above a Received: header added by a trusted MTA. This can 1176 be used as a test for header field validity. 1178 Support for some of these is being considered for future work. 1180 In any case, a mechanism needs to exist for an MUA or filter to 1181 verify that the host that appears to have added the header field (a) 1182 actually did so, and (b) is legitimately adding that header field for 1183 this delivery. Given the variety of messaging environments deployed 1184 today, consensus appears to be that specifying a particular mechanism 1185 for doing so is not appropriate for this document. 1187 Mitigation of the forged header field attack can also be accomplished 1188 by moving the authentication results data into meta-data associated 1189 with the message. In particular, an [SMTP] extension could be 1190 established that is used to communicate authentication results from 1191 the border MTA to intermediate and delivery MTAs; the latter of these 1192 could arrange to store the authentication results as meta-data 1193 retrieved and rendered along with the message by an [IMAP] client 1194 aware of a similar extension in that protocol. The delivery MTA 1195 would be told to trust data via this extension only from MTAs it 1196 trusts, and border MTAs would not accept data via this extension from 1197 any source. There is no vector in such an arrangement for forgery of 1198 authentication data by an outside agent. 1200 7.2. Misleading Results 1202 Until some form of service for querying the reputation of a sending 1203 agent is widely deployed, the existence of this header field 1204 indicating a "pass" does not render the message trustworthy. It is 1205 possible for an arriving piece of spam or other undesirable mail to 1206 pass checks by several of the methods enumerated above (e.g., a piece 1207 of spam signed using [DKIM] by the originator of the spam, which 1208 might be a spammer or a compromised system). In particular, this 1209 issue is not resolved by forged header field removal discussed above. 1211 Hence, MUAs and downstream filters must take some care with use of 1212 this header even after possibly malicious headers are scrubbed. 1214 7.3. Header Field Position 1216 Despite the requirements of [MAIL], header fields can sometimes be 1217 reordered enroute by intermediate MTAs. The goal of requiring header 1218 field addition only at the top of a message is an acknowledgement 1219 that some MTAs do reorder header fields, but most do not. Thus, in 1220 the general case, there will be some indication of which MTAs (if 1221 any) handled the message after the addition of the header field 1222 defined here. 1224 7.4. Reverse IP Query Denial-of-Service Attacks 1226 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 1227 for verifiers that attempt DNS-based identity verification of 1228 arriving client connections. A verifier wishing to do this check and 1229 report this information need to take care not to go to unbounded 1230 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1231 making use of an "iprev" result specified by this document need to be 1232 aware of the algorithm used by the verifier reporting the result and, 1233 especially, its limitations. 1235 7.5. Mitigation of Backscatter 1237 Failing to follow the instructions of Section 4.2 can result in a 1238 denial-of-service attack caused by the generation of [DSN] messages 1239 (or equivalent) to addresses that did not send the messages being 1240 rejected. 1242 7.6. Internal MTA Lists 1244 Section 5 describes a procedure for scrubbing header fields that may 1245 contain forged authentication results about a message. A compliant 1246 installation will have to include, at each MTA, a list of other MTAs 1247 known to be compliant and trustworthy. Failing to keep this list 1248 current as internal infrastructure changes may expose an ADMD to 1249 attack. 1251 7.7. Attacks against Authentication Methods 1253 If an attack becomes known against an authentication method, clearly 1254 then the agent verifying that method can be fooled into thinking an 1255 inauthentic message is authentic, and thus the value of this header 1256 field can be misleading. It follows that any attack against the 1257 authentication methods supported by this document (and later 1258 amendments to it) is also a security consideration here. 1260 7.8. Intentionally Malformed Header Fields 1262 It is possible for an attacker to add an Authentication-Results 1263 header field that is extraordinarily large or otherwise malformed in 1264 an attempt to discover or exploit weaknesses in header field parsing 1265 code. Implementers must thoroughly verify all such header fields 1266 received from MTAs and be robust against intentionally as well as 1267 unintentionally malformed header fields. 1269 7.9. Compromised Internal Hosts 1271 An internal MUA or MTA that has been compromised could generate mail 1272 with a forged From header field and a forged Authentication-Results 1273 header field that endorses it. Although it is clearly a larger 1274 concern to have compromised internal machines than it is to prove the 1275 value of this header field, this risk can be mitigated by arranging 1276 that internal MTAs will remove this header field if it claims to have 1277 been added by a trusted border MTA (as described above), yet the 1278 [SMTP] connection is not coming from an internal machine known to be 1279 running an authorized MTA. However, in such a configuration, 1280 legitimate MTAs will have to add this header field when legitimate 1281 internal-only messages are generated. This is also covered in 1282 Section 5. 1284 7.10. Encapsulated Instances 1286 [MIME] messages can contain attachments of type "message/rfc822", 1287 which contain other [MAIL] messages. Such an encapsulated message 1288 can also contain an Authentication-Results header field. Although 1289 the processing of these is outside of the intended scope of this 1290 document (see Section 1.3), some early guidance to MUA developers is 1291 appropriate here. 1293 Since MTAs are unlikely to strip Authentication-Results header fields 1294 after mailbox delivery, MUAs are advised in Section 4.1 to ignore 1295 such instances within [MIME] attachments. Moreover, when extracting 1296 a message digest to separate mail store messages or other media, such 1297 header fields should be removed so that they will never be 1298 interpreted improperly by MUAs that might later consume them. 1300 7.11. Reverse Mapping 1302 Although Section 3 of this memo includes explicit support for the 1303 "iprev" method, its value as an authentication mechanism is limited. 1304 Implementers of both this proposal and agents that use the data it 1305 relays are encouraged to become familiar with the issues raised by 1306 [DNSOP-REVERSE] when deciding whether or not to include support for 1307 "iprev". 1309 8. References 1311 8.1. Normative References 1313 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 1314 Syntax Specifications: ABNF", STD 68, 1315 RFC 5234, January 2008. 1317 [IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, 1318 "Registration Procedures for Message Header 1319 Fields", BCP 90, RFC 3864, September 2004. 1321 [KEYWORDS] Bradner, S., "Key words for use in RFCs to 1322 Indicate Requirement Levels", BCP 14, 1323 RFC 2119, March 1997. 1325 [MAIL] Resnick, P., Ed., "Internet Message Format", 1326 RFC 5322, October 2008. 1328 [MIME] Freed, N. and N. Borenstein, "Multipurpose 1329 Internet Mail Extensions (MIME) Part One: 1330 Format of Internet Message Bodies", RFC 2045, 1331 November 1996. 1333 8.2. Informative References 1335 [ADSP] Allman, E., Fenton, J., Delany, M., and J. 1336 Levine, "DomainKeys Identified Mail (DKIM) 1337 Author Domain Signing Practices (ADSP)", 1338 RFC 5617, August 2009. 1340 [ATPS] Kucherawy, M., "DomainKeys Identified Mail 1341 (DKIM) Authorized Third-Party Signatures", 1342 RFC 6541, February 2012. 1344 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service 1345 Extension for Authentication", RFC 4954, 1346 July 2007. 1348 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, 1349 "DomainKeys Identified Mail (DKIM) 1350 Signatures", RFC 6376, September 2011. 1352 [DNS] Mockapetris, P., "Domain names - 1353 implementation and specification", STD 13, 1354 RFC 1035, November 1987. 1356 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. 1357 Souissi, "DNS Extensions to Support IP Version 1358 6", RFC 3596, October 2003. 1360 [DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for 1361 the use of DNS Reverse Mapping", Work 1362 in Progress, March 2008. 1364 [DOMAINKEYS] Delany, M., "Domain-Based Email Authentication 1365 Using Public Keys Advertised in the DNS 1366 (DomainKeys)", RFC 4870, May 2007. 1368 [DSN] Moore, K. and G. Vaudreuil, "An Extensible 1369 Message Format for Delivery Status 1370 Notifications", RFC 3464, January 2003. 1372 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", 1373 RFC 5598, October 2008. 1375 [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for 1376 Writing an IANA Considerations Section in 1377 RFCs", BCP 26, RFC 5226, May 2008. 1379 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL 1380 - VERSION 4rev1", RFC 3501, March 2003. 1382 [POP3] Myers, J. and M. Rose, "Post Office Protocol - 1383 Version 3", STD 53, RFC 1939, May 1996. 1385 [RFC5451] Kucherawy, M., "Message Header Field for 1386 Indicating Message Authentication Status", 1387 RFC 5451, April 2009. 1389 [SECURITY] Rescorla, E. and B. Korver, "Guidelines for 1390 Writing RFC Text on Security Considerations", 1391 BCP 72, RFC 3552, July 2003. 1393 [SENDERID] Lyon, J. and M. Wong, "Sender ID: 1394 Authenticating E-Mail", RFC 4406, April 2006. 1396 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 1397 RFC 5321, October 2008. 1399 [SPF] Wong, M. and W. Schlitt, "Sender Policy 1400 Framework (SPF) for Authorizing Use of Domains 1401 in E-Mail, Version 1", RFC 4408, April 2006. 1403 [VBR] Hoffman, P., Levine, J., and A. Hathcock, 1404 "Vouch By Reference", RFC 5518, April 2009. 1406 Appendix A. Acknowledgements 1408 The author wishes to acknowledge the following for their review and 1409 constructive criticism of this update: Dave Cridland, Scott 1410 Kitterman, S. Moonesamy, Alessandro Vesely, [other names] 1412 Appendix B. Legacy MUAs 1414 Implementers of this protocol should be aware that many MUAs are 1415 unlikely to be retrofitted to support the new header field and its 1416 semantics. In the interests of convenience and quicker adoption, a 1417 delivery MTA might want to consider adding things that are processed 1418 by existing MUAs in addition to the Authentication-Results header 1419 field. One suggestion is to include a Priority header field, on 1420 messages that don't already have such a header field, containing a 1421 value that reflects the strength of the authentication that was 1422 accomplished, e.g., "low" for weak or no authentication, "normal" or 1423 "high" for good or strong authentication. 1425 Some modern MUAs can already filter based on the content of this 1426 header field. However, there is keen interest in having MUAs make 1427 some kind of graphical representation of this header field's meaning 1428 to end users. Until this capability is added, other interim means of 1429 conveying authentication results may be necessary while this proposal 1430 and its successors are adopted. 1432 Appendix C. Authentication-Results Examples 1434 This section presents some examples of the use of this header field 1435 to indicate authentication results. 1437 C.1. Trivial Case; Header Field Not Present 1439 The trivial case: 1441 Received: from mail-router.example.com 1442 (mail-router.example.com [192.0.2.1]) 1443 by server.example.org (8.11.6/8.11.6) 1444 with ESMTP id g1G0r1kA003489; 1445 Fri, Feb 15 2002 17:19:07 -0800 1446 From: sender@example.com 1447 Date: Fri, Feb 15 2002 16:54:30 -0800 1448 To: receiver@example.org 1449 Message-Id: <12345.abc@example.com> 1450 Subject: here's a sample 1452 Hello! Goodbye! 1454 Example 1: Trivial case 1456 The "Authentication-Results" header field is completely absent. The 1457 MUA may make no conclusion about the validity of the message. This 1458 could be the case because the message authentication services were 1459 not available at the time of delivery, or no service is provided, or 1460 the MTA is not in compliance with this specification. 1462 C.2. Nearly Trivial Case; Service Provided, But No Authentication Done 1464 A message that was delivered by an MTA that conforms to this 1465 specification but provides no actual message authentication service: 1467 Authentication-Results: example.org/1; none 1468 Received: from mail-router.example.com 1469 (mail-router.example.com [192.0.2.1]) 1470 by server.example.org (8.11.6/8.11.6) 1471 with ESMTP id g1G0r1kA003489; 1472 Fri, Feb 15 2002 17:19:07 -0800 1473 From: sender@example.com 1474 Date: Fri, Feb 15 2002 16:54:30 -0800 1475 To: receiver@example.org 1476 Message-Id: <12345.abc@example.com> 1477 Subject: here's a sample 1479 Hello! Goodbye! 1481 Example 2: Header present but no authentication done 1483 The "Authentication-Results" header field is present, showing that 1484 the delivering MTA conforms to this specification. It used its DNS 1485 domain name as the authserv-id. The presence of "none" (and the 1486 absence of any method and result tokens) indicates that no message 1487 authentication was done. The version number of the specification to 1488 which the field's content conforms is explicitly provided. 1490 C.3. Service Provided, Authentication Done 1492 A message that was delivered by an MTA that conforms to this 1493 specification and applied some message authentication: 1495 Authentication-Results: example.com; 1496 spf=pass smtp.mailfrom=example.net 1497 Received: from dialup-1-2-3-4.example.net 1498 (dialup-1-2-3-4.example.net [192.0.2.200]) 1499 by mail-router.example.com (8.11.6/8.11.6) 1500 with ESMTP id g1G0r1kA003489; 1501 Fri, Feb 15 2002 17:19:07 -0800 1502 From: sender@example.net 1503 Date: Fri, Feb 15 2002 16:54:30 -0800 1504 To: receiver@example.com 1505 Message-Id: <12345.abc@example.net> 1506 Subject: here's a sample 1508 Hello! Goodbye! 1510 Example 3: Header reporting results 1512 The "Authentication-Results" header field is present, indicating that 1513 the border MTA conforms to this specification. The authserv-id is 1514 once again the DNS domain name. Furthermore, the message was 1515 authenticated by that MTA via the method specified in [SPF]. Note 1516 that since that method cannot authenticate the local-part, it has 1517 been omitted from the result's value. The MUA could extract and 1518 relay this extra information if desired. 1520 C.4. Service Provided, Several Authentications Done, Single MTA 1522 A message that was relayed inbound via a single MTA that conforms to 1523 this specification and applied three different message authentication 1524 checks: 1526 Authentication-Results: example.com; 1527 auth=pass (cram-md5) smtp.auth=sender@example.com; 1528 spf=pass smtp.mailfrom=example.com 1529 Authentication-Results: example.com; 1530 sender-id=pass header.from=example.com 1531 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1532 (dialup-1-2-3-4.example.net [192.0.2.200]) 1533 by mail-router.example.com (8.11.6/8.11.6) 1534 with ESMTP id g1G0r1kA003489; 1535 Fri, Feb 15 2002 17:19:07 -0800 1536 Date: Fri, Feb 15 2002 16:54:30 -0800 1537 To: receiver@example.net 1538 From: sender@example.com 1539 Message-Id: <12345.abc@example.com> 1540 Subject: here's a sample 1542 Hello! Goodbye! 1544 Example 4: Headers reporting results from one MTA 1546 The "Authentication-Results" header field is present, indicating the 1547 delivering MTA conforms to this specification. Once again, the 1548 receiving DNS domain name is used as the authserv-id. Furthermore, 1549 the sender authenticated herself/himself to the MTA via a method 1550 specified in [AUTH], and both SPF and Sender ID checks were done and 1551 passed. The MUA could extract and relay this extra information if 1552 desired. 1554 Two "Authentication-Results" header fields are not required since the 1555 same host did all of the checking. The authenticating agent could 1556 have consolidated all the results into one header field. 1558 This example illustrates a scenario in which a remote user on a 1559 dialup connection (example.net) sends mail to a border MTA 1560 (example.com) using SMTP authentication to prove identity. The 1561 dialup provider has been explicitly authorized to relay mail as 1562 "example.com" resulting in passes by the SPF and SenderID checks. 1564 C.5. Service Provided, Several Authentications Done, Different MTAs 1566 A message that was relayed inbound by two different MTAs that conform 1567 to this specification and applied multiple message authentication 1568 checks: 1570 Authentication-Results: example.com; 1571 sender-id=fail header.from=example.com; 1572 dkim=pass (good signature) header.d=example.com 1573 Received: from mail-router.example.com 1574 (mail-router.example.com [192.0.2.1]) 1575 by auth-checker.example.com (8.11.6/8.11.6) 1576 with ESMTP id i7PK0sH7021929; 1577 Fri, Feb 15 2002 17:19:22 -0800 1578 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1579 t=1188964191; c=simple/simple; h=From:Date:To:Subject: 1580 Message-Id:Authentication-Results; 1581 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1582 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1583 Authentication-Results: example.com; 1584 auth=pass (cram-md5) smtp.auth=sender@example.com; 1585 spf=fail smtp.mailfrom=example.com 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.com 1592 Date: Fri, Feb 15 2002 16:54:30 -0800 1593 To: receiver@example.com 1594 Message-Id: <12345.abc@example.com> 1595 Subject: here's a sample 1597 Hello! Goodbye! 1599 Example 5: Headers reporting results from multiple MTAs 1601 The "Authentication-Results" header field is present, indicating 1602 conformance to this specification. Once again, the authserv-id used 1603 is the recipient's DNS domain name. The header field is present 1604 twice because two different MTAs in the chain of delivery did 1605 authentication tests. The first, "mail-router.example.com" reports 1606 that SMTP AUTH and SPF were both used, and the former passed while 1607 the latter failed. In the SMTP AUTH case, additional information is 1608 provided in the comment field, which the MUA can choose to render if 1609 desired. 1611 The second MTA, "auth-checker.example.com", reports that it did a 1612 Sender ID test (which failed) and a DKIM test (which passed). Again, 1613 additional data about one of the tests is provided as a comment, 1614 which the MUA may choose to render. Also noteworthy here is the fact 1615 that there is a DKIM signature added by example.com that assured the 1616 integrity of the lower Authentication-Results field. 1618 Since different hosts did the two sets of authentication checks, the 1619 header fields cannot be consolidated in this example. 1621 This example illustrates more typical transmission of mail into 1622 "example.com" from a user on a dialup connection "example.net". The 1623 user appears to be legitimate as he/she had a valid password allowing 1624 authentication at the border MTA using SMTP AUTH. The SPF and Sender 1625 ID tests failed since "example.com" has not granted "example.net" 1626 authority to relay mail on its behalf. However, the DKIM test passed 1627 because the sending user had a private key matching one of 1628 "example.com"'s published public keys and used it to sign the 1629 message. 1631 C.6. Service Provided, Multi-Tiered Authentication Done 1633 A message that had authentication done at various stages, one of 1634 which was outside the receiving ADMD: 1636 Authentication-Results: example.com; 1637 dkim=pass reason="good signature" 1638 header.i=@mail-router.example.net; 1639 dkim=fail reason="bad signature" 1640 header.i=@newyork.example.com 1641 Received: from mail-router.example.net 1642 (mail-router.example.net [192.0.2.250]) 1643 by chicago.example.com (8.11.6/8.11.6) 1644 for 1645 with ESMTP id i7PK0sH7021929; 1646 Fri, Feb 15 2002 17:19:22 -0800 1647 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1648 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1649 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1650 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1651 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1652 Authentication-Results: example.net; 1653 dkim=pass (good signature) header.i=@newyork.example.com 1654 Received: from smtp.newyork.example.com 1655 (smtp.newyork.example.com [192.0.2.220]) 1656 by mail-router.example.net (8.11.6/8.11.6) 1657 with ESMTP id g1G0r1kA003489; 1658 Fri, Feb 15 2002 17:19:07 -0800 1659 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; 1660 d=newyork.example.com; 1661 t=1188964191; c=simple/simple; 1662 h=From:Date:To:Message-Id:Subject; 1663 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1664 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1665 From: sender@newyork.example.com 1666 Date: Fri, Feb 15 2002 16:54:30 -0800 1667 To: meetings@example.net 1668 Message-Id: <12345.abc@newyork.example.com> 1669 Subject: here's a sample 1671 Example 6: Headers reporting results from multiple MTAs in different 1672 ADMDs 1674 In this example we see multi-tiered authentication with an extended 1675 trust boundary. 1677 The message was sent from someone at example.com's New York office 1678 (newyork.example.com) to a mailing list managed at an intermediary. 1680 The message was signed at the origin using DKIM. 1682 The message was sent to a mailing list service provider called 1683 example.net, which is used by example.com. There, 1684 meetings@example.net is expanded to a long list of recipients, one of 1685 that is at the Chicago office. In this example, we will assume that 1686 the trust boundary for chicago.example.com includes the mailing list 1687 server at example.net. 1689 The mailing list server there first authenticated the message and 1690 affixed an Authentication-Results header field indicating such using 1691 its DNS domain name for the authserv-id. It then altered the message 1692 by affixing some footer text to the body, including some 1693 administrivia such as unsubscription instructions. Finally, the 1694 mailing list server affixes a second DKIM signature and begins 1695 distribution of the message. 1697 The border MTA for chicago.example.com explicitly trusts results from 1698 mail-router.example.net so that header field is not removed. It 1699 performs evaluation of both signatures and determines that the first 1700 (most recent) is a "pass" but, because of the aforementioned 1701 modifications, the second is a "fail". However, the first signature 1702 included the Authentication-Results header added at mail- 1703 router.example.net that validated the second signature. Thus, 1704 indirectly, it can be determined that the authentications claimed by 1705 both signatures are indeed valid. 1707 Note that two styles of presenting meta-data about the result are in 1708 use here. In one case, the "reason=" clause is present which is 1709 intended for easy extraction by parsers; in the other case, the CFWS 1710 production of the ABNF is used to include such data as a header field 1711 comment. The latter can be harder for parsers to extract given the 1712 varied supported syntaxes of mail header fields. 1714 C.7. Comment-Heavy Example 1716 The formal syntax permits comments within the content in a number of 1717 places. For the sake of illustration, this example is also legal: 1719 Authentication-Results: foo.example.net (foo) / (bar) 1 (baz); 1720 dkim (Because I like it) / 1 (One yay) = (wait for it) fail 1721 policy (A dot can go here) . (like that) expired 1722 (this surprised me) = (as I wasn't expecting it) 1362471462 1724 Example 7: A very comment-heavy but perfectly legal example 1726 Appendix D. Operational Considerations about Message Authentication 1728 This protocol is predicated on the idea that authentication (and 1729 presumably in the future, reputation) work is typically done by 1730 border MTAs rather than MUAs or intermediate MTAs; the latter merely 1731 make use of the results determined by the former. Certainly this is 1732 not mandatory for participation in electronic mail or message 1733 authentication, but this protocol and its deployment to date are 1734 based on that model. The assumption satisfies several common ADMD 1735 requirements: 1737 1. Service operators prefer to resolve the handling of problem 1738 messages as close to the border of the ADMD as possible. This 1739 enables, for example, rejections of messages at the SMTP level 1740 rather than generating a DSN internally. Thus, doing any of the 1741 authentication or reputation work exclusively at the MUA or 1742 intermediate MTA renders this desire unattainable. 1744 2. Border MTAs are more likely to have direct access to external 1745 sources of authentication or reputation information since modern 1746 MUAs are more likely to be heavily firewalled. Thus, some MUAs 1747 might not even be able to complete the task of performing 1748 authentication or reputation evaluations without complex proxy 1749 configurations or similar burdens. 1751 3. MUAs rely upon the upstream MTAs within their trust boundaries to 1752 make correct (as much as that is possible) evaluations about the 1753 message's envelope, header and content. Thus, MUAs don't need to 1754 know how to do the work that upstream MTAs do; they only need the 1755 results of that work. 1757 4. Evaluations about the quality of a message, from simple token 1758 matching (e.g., a list of preferred DNS domains) to cryptanalysis 1759 (e.g., public/private key work), are at least a little bit 1760 expensive and thus need to be minimized. To that end, performing 1761 those tests at the border MTA is far preferred to doing that work 1762 at each MUA that handles a message. If an ADMD's environment 1763 adheres to common messaging protocols, a reputation query or an 1764 authentication check performed by a border MTA would return the 1765 same result as the same query performed by an MUA. By contrast, 1766 in an environment where the MUA does the work, a message arriving 1767 for multiple recipients would thus cause authentication or 1768 reputation evaluation to be done more than once for the same 1769 message (i.e., at each MUA) causing needless amplification of 1770 resource use and creating a possible denial-of-service attack 1771 vector. 1773 5. Minimizing change is good. As new authentication and reputation 1774 methods emerge, the list of methods supported by this header 1775 field would presumably be extended. If MUAs simply consume the 1776 contents of this header field rather than actually attempting to 1777 do authentication and/or reputation work, then MUAs only need to 1778 learn to parse this header field once; emergence of new methods 1779 requires only a configuration change at the MUAs and software 1780 changes at the MTAs (which are presumably fewer in number). When 1781 choosing to implement these functions in MTAs vs MUAs, the issues 1782 of individual flexibility, infrastructure inertia and scale of 1783 effort must be considered. It is typically easier to change a 1784 single MUA than an MTA because the modification affects fewer 1785 users and can be pursued with less care. However, changing many 1786 MUAs is more effort than changing a smaller number of MTAs. 1788 6. For decisions affecting message delivery and display, assessment 1789 based on authentication and reputation is best performed close to 1790 the time of message transit, as a message makes its journey 1791 toward a user's inbox, not afterwards. DKIM keys and IP address 1792 reputations, etc., can change over time or even become invalid, 1793 and users can take a long time to read a message once delivered. 1794 The value of this work thus degrades, perhaps quickly, once the 1795 delivery process has completed. This seriously diminishes the 1796 value of this work when done other than at MTAs. 1798 Many operational choices are possible within an ADMD, including the 1799 venue for performing authentication and/or reputation assessment. 1800 The current specification does not dictate any of those choices. 1801 Rather, it facilitates those cases in which information produced by 1802 one stage of analysis needs to be transported with the message to the 1803 next stage. 1805 Appendix E. Known Implementations 1807 [Note to IESG: This can be dropped prior to publication unless it's 1808 desirable to carry the information visibly in this way.] 1810 o Google Mail (Gmail) 1812 o Yahoo! Mail 1814 o Hotmail 1816 o Courier MTA (http://www.courier-mta.org) 1818 o sid-milter (http://sourceforge.net/projects/sid-milter) 1819 o OpenDKIM (http://www.opendkim.org) 1821 o OpenDMARC (http://www.trusteddomain.org/opendmarc.html) 1823 o An open source Python module 1824 (https://pypi.python.org/pypi/authres/0.402) 1826 Appendix F. Changes since RFC5451 1828 [Note to IESG: This can be dropped prior to publication unless it's 1829 desirable to carry the changes visibly in this way.] 1831 o Errata #2617 was addressed in RFC6577 and was incorporated here 1833 o Request Internet Standard status 1835 o Change IANA rules to Designated Expert from IETF Review 1837 o Update existing IANA registries from the old RFC to this one 1839 o Add references to ADSP, ATPS, VBR 1841 o Remove all the "X-" stuff, per BCP178 1843 o Adjust language to indicate that this header field was already 1844 defined, and we're just refreshing and revising 1846 o In a few places, RFC2119 language had been used in lowercase 1847 terms; fixed here 1849 o Errata #2818 addressed 1851 o Errata #3195 addressed 1853 o Some minor wordsmithing and removal of odd prose 1855 o ABNF: change "dot-atom" to "Keyword" since "dot-atom" allows "=", 1856 which leads to ambiguous productions 1858 o Call out the SMTP verb exceptions ("mailfrom" and "rcptto"); the 1859 previous RFC didn't do this, leading to interoperability problems 1861 o Rather then deleting suspect header fields, they could also be 1862 renamed to something harmless; there is at least one 1863 implementation of this 1865 o Update IANA method registry to include version numbers 1866 o Constrain inclusion of unnecessary properties to avoid confusing 1867 consumers 1869 o Review "should" vs. SHOULD 1871 Author's Address 1873 Murray S. Kucherawy 1874 270 Upland Drive 1875 San Francisco, CA 94127 1876 US 1878 EMail: superuser@gmail.com