idnits 2.17.1 draft-ietf-appsawg-rfc5451bis-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 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 (April 3, 2013) is 4040 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 452, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AR-ORIG') (Obsoleted by RFC 7001) -- 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 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft April 3, 2013 4 Obsoletes: 5451, 6577 5 (if approved) 6 Intended status: Standards Track 7 Expires: October 5, 2013 9 Message Header Field for Indicating Message Authentication Status 10 draft-ietf-appsawg-rfc5451bis-00 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 October 5, 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 . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . 16 79 2.5.5. Extension Result Codes . . . . . . . . . . . . . . . . 16 80 2.6. Authentication Methods . . . . . . . . . . . . . . . . . . 17 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 [AR-ORIG] defined a new header field for electronic mail messages 128 that presents the results of a message authentication effort in a 129 machine-readable format. This document revises that definition based 130 on current use of various authentication protocols in use today and 131 incorporates errata logged since the publication of the original 132 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, [ADSP], [AUTH], [DKIM], 154 [SPF], and [VBR] are published DNS domain-level email authentication 155 methods in common use. [DOMAINKEYS] is also referenced here, though 156 it has "Historic" status as it is no longer common. This proposal is 157 not intended to be restricted to domain-based authentication, but 158 this has proven to be a good starting point for implementations. As 159 various methods emerge, it is necessary to prepare for their 160 appearance and encourage convergence in the area of interfacing 161 verifiers to filters and MUAs. 163 Although [SPF] defined a header field called Received-SPF and 164 [DOMAINKEYS] defined one called DomainKey-Status for this purpose, 165 those header fields are specific to the conveyance of their 166 respective results only and thus are insufficient to satisfy the 167 requirements enumerated below. In addition, many SPF implementations 168 have adopted the header field specified below, and DomainKeys has 169 been obsoleted by DKIM. 171 1.1. Purpose 173 The header field defined in this document is expected to serve 174 several purposes: 176 1. Convey the results of various message authentication checks being 177 applied by upstream filters and Mail Transfer Agents (MTAs) to 178 MUAs and downstream filters within the same "trust domain", as 179 such agents may wish to render those results to end users or use 180 that data to apply more or less stringent content checks based on 181 authentication results; 183 2. Provide a common location within a message for this data; 185 3. Create an extensible framework for reporting new authentication 186 methods as they emerge. 188 In particular, the mere presence of this header field SHOULD NOT be 189 construed as meaning that its data is valid, but rather that it is 190 asserting some kind of validity based on one or more authentication 191 schemes applied somewhere upstream. For an MUA or downstream filter 192 to treat the assertions as actually valid, there must be an 193 assessment of the trust relationship between such agents and the 194 validating MTA. 196 1.2. Trust Boundary 198 This document makes several references to the "trust boundary" of an 199 administrative management domain (ADMD). Given the diversity among 200 existing mail environments, a precise definition of this term isn't 201 possible. 203 Simply put, a transfer from the creator of the header field to the 204 consumer must occur within a context of trust that the creator's 205 information is correct. How this trust is obtained is outside the 206 scope of this document. It is entirely a local matter. 208 Thus, this document defines a "trust boundary" as the delineation 209 between "external" and "internal" entities; "external" here includes 210 all hosts that do not deliberately provide some kind of messaging 211 service for the receiving ADMD's users, and "internal" includes those 212 hosts that do. By this definition, the hosts within a "trust 213 boundary" may lie entirely within a receiving ADMD's direct control, 214 or they can include hosts managed by another ADMD (such as an ISP or 215 commercial filtering service) but that also provide services for the 216 former. 218 1.3. Processing Scope 220 This specification is intended to address the needs of authenticating 221 messages or properties of messages during their actual transport. It 222 is not meant to address the security of messages that might be 223 encapsulated within other messages, such as a message/rfc822 [MIME] 224 part within a message. 226 1.4. Requirements 228 This document establishes no new requirements on existing protocols 229 or servers. 231 In particular, this document establishes no requirement on MTAs to 232 reject or filter arriving messages that do not pass authentication 233 checks. The data conveyed by the specified header field's contents 234 are for the information of MUAs and filters and are to be used at 235 their discretion. 237 1.5. Definitions 239 This section defines various terms used throughout this document. 241 1.5.1. Key Words 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [KEYWORDS]. 247 1.5.2. Security 249 [SECURITY] discusses authentication and authorization and the 250 conflation of the two concepts. The use of those terms within the 251 context of recent message security work has given rise to slightly 252 different definitions, and this document reflects those current 253 usages, as follows: 255 o "Authorization" is the establishment of permission to use a 256 resource or represent an identity. In this context, authorization 257 indicates that a message from a particular ADMD arrived via a 258 route the ADMD has explicitly approved. 260 o "Authentication" is the assertion of validity of a piece of data 261 about a message (such as the sender's identity) or the message in 262 its entirety. 264 As examples: [SPF] and [SENDERID] are authorization mechanisms in 265 that they express a result that shows whether or not the ADMD that 266 apparently sent the message has explicitly authorized the connecting 267 [SMTP] client to relay messages on its behalf, but do not actually 268 validate any property of the message itself. By contrast, [DKIM] is 269 agnostic as to the routing of a message but uses cryptographic 270 signatures to authenticate agents claiming responsibility for the 271 message (which implies authorization) and ensure it was not modified 272 in transit. Since the signatures are not tied to SMTP connections, 273 they can be added by either the ADMD of origin, intermediate ADMDs 274 (such as a mailing list server), or both. 276 Rather than create a separate header field for each class of 277 solution, this proposal groups them both into a single header field. 279 1.5.3. Email Architecture 281 o A "border MTA" is an MTA that acts as a gateway between the 282 general Internet and the users within an organizational boundary. 283 (See also Section 1.2.) 285 o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that 286 actually enacts delivery of a message to a user's inbox or other 287 final delivery. 289 o An "intermediate MTA" is an MTA that handles messages after a 290 border MTA and before a delivery MTA. 292 The following diagram illustrates the flow of mail among these 293 defined components: 295 +-----+ +-----+ +------------+ 296 | MUA |-->| MSA |-->| Border MTA | 297 +-----+ +-----+ +------------+ 298 | 299 | 300 V 301 +----------+ 302 | Internet | 303 +----------+ 304 | 305 | 306 V 307 +-----+ +-----+ +------------------+ +------------+ 308 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 309 +-----+ +-----+ +------------------+ +------------+ 311 Generally, it is assumed that the work of applying message 312 authentication schemes takes place at a border MTA or a delivery MTA. 313 This specification is written with that assumption in mind. However, 314 there are some sites at which the entire mail infrastructure consists 315 of a single host. In such cases, such terms as "border MTA" and 316 "delivery MTA" might well apply to the same machine or even the very 317 same agent. It is also possible that some message authentication 318 tests could take place on an intermediate MTA. Although this 319 document doesn't specifically describe such cases, they are not meant 320 to be excluded. 322 See [EMAIL-ARCH] for further discussion on general email system 323 architecture, and Appendix D of this document for discussion about 324 the common aspects of email authentication in current environments. 326 1.6. Trust Environment 328 This header field permits one or more message validation mechanisms 329 to communicate output to one or more separate assessment mechanisms. 330 These mechanisms operate within a unified trust boundary that defines 331 an Administrative Management Domain (ADMD). An ADMD contains one or 332 more entities that perform validation and generate the header field, 333 and one or more that consume it for some type of assessment. The 334 field contains no integrity or validation mechanism of its own, so 335 its presence must be trusted implicitly. Hence, use of the header 336 field depends upon ensuring that mail entering the ADMD has instances 337 of the header field claiming to be valid within its boundaries 338 removed, so that occurrences of such header fields can be used safely 339 by consumers. 341 The "authserv-id" token defined in Section 2.2 can be used to label 342 an entire ADMD or a specific validation engine within an ADMD. 343 Although the labeling scheme is left as an operational choice, some 344 guidance for selecting a token is provided in later sections of this 345 document. 347 2. Definition and Format of the Header Field 349 This section gives a general overview of the format of the header 350 field being defined, and then provides more formal specification. 352 2.1. General Description 354 The header field specified here is called "Authentication-Results". 355 It is a Structured Header Field as defined in [MAIL] and thus all of 356 the related definitions in that document apply. 358 This header field is added at the top of the message as it transits 359 MTAs that do authentication checks so some idea of how far away the 360 checks were done can be inferred. It is therefore considered to be a 361 Trace Field as defined in [MAIL], and thus all of the related 362 definitions in that document apply. 364 The value of the header field (after removing [MAIL] comments) 365 consists of an authentication identifier, an optional version, and 366 then a series of "method=result" statements indicating which 367 authentication method(s) were applied and their respective results, 368 and then, for each applied method, an optional "reason" string, plus 369 optional "property=value" statements indicating which message 370 properties were evaluated to reach that conclusion. 372 The header field can appear more than once in a single message, or 373 more than one result MAY be represented in a single header field, or 374 a combination of these MAY be applied. 376 2.2. Formal Definition 378 Formally, the header field is specified as follows using [ABNF]: 380 authres-header = "Authentication-Results:" [CFWS] authserv-id 381 [ [CFWS] "/" [CFWS] authres-version ] 382 ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF 383 ; the special case of "none" is used to indicate that no 384 ; message authentication is performed 386 authserv-id = value 387 ; see below for a description of this element 389 authserv-version = 1*DIGIT [CFWS] 390 ; indicates which version of this specification is in use; 391 ; this specification is version "1", and the absence of a 392 ; version implies this version of the specification 394 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 395 *( CFWS propspec ) 397 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 398 ; indicates which authentication method was evaluated 399 ; and what its output was 401 reasonspec = "reason" [CFWS] "=" [CFWS] value 402 ; a free-form comment on the reason the given result 403 ; was returned 405 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 406 ; an indication of which properties of the message 407 ; were evaluated by the authentication scheme being 408 ; applied to yield the reported result, and would be 409 ; useful to reveal to end users as authenticated 411 method = Keyword [ [CFWS] "/" [CFWS] method-version ] 412 ; a method indicates which method's result is 413 ; represented by "result", and is one of the methods 414 ; explicitly defined as valid in this document 415 ; or is an extension method as defined below 417 method-version = 1*DIGIT [CFWS] 418 ; indicates which version of the method specification is 419 ; in use, corresponding to the matching entry in the IANA 420 ; Email Authentication Methods registry; a value of "1" 421 ; is assumed if this version string is absent 423 result = Keyword 424 ; indicates the results of the attempt to authenticate 425 ; the message; see below for details 427 ptype = "smtp" / "header" / "body" / "policy" 428 ; indicates whether the property being evaluated was 429 ; a parameter to an [SMTP] command, or was a value taken 430 ; from a message header field, or was some property of 431 ; the message body, or some other property evaluated by 432 ; the receiving MTA 434 special-smtp-verb = "mailfrom" / "rcptto" 435 ; special cases of [SMTP] commands that are made up 436 ; of multiple words 438 property = special-smtp-verb / Keyword 439 ; if "ptype" is "smtp", this indicates which [SMTP] 440 ; command provided the value that was evaluated by the 441 ; authentication scheme being applied; if "ptype" is 442 ; "header", this indicates from which header field the 443 ; value being evaluated was extracted; if "ptype" is 444 ; "body", this indicates where in the message body 445 ; a value being evaluated can be found (e.g., a specific 446 ; offset into the message or a reference to a MIME part); 447 ; if "ptype" is "policy" then this indicates the name 448 ; of the policy that caused this header field to be 449 ; added (see below) 451 pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name ) 452 [CFWS] 453 ; the value extracted from the message property defined 454 ; by the "ptype.property" construction; if the value 455 ; identifies something intended to be an e-mail identity, 456 ; then it MUST use the right hand portion of this ABNF 457 ; definition 459 "local-part" is defined in Section 3.4.1, and "CFWS" is defined in 460 Section 3.2.2, of [MAIL]. 462 "Keyword" is defined in Section 4.1.2 of [SMTP]. 464 The "value" is as defined in Section 5.1 of [MIME]. 466 The "domain-name" is as defined in Section 3.5 of [DKIM]. 468 The "Keyword" used in "result" above is further constrained by the 469 necessity of being enumerated in Section 2.5 or an amendment to it. 471 See Section 2.3 for a description of the "authserv-id" element. 473 The list of commands eligible for use with the "smtp" ptype can be 474 found in [SMTP] and subsequent amendments. 476 The "propspec" may be omitted if, for example, the method was unable 477 to extract any properties to do its evaluation yet has a result to 478 report. 480 The "ptype" and "property" values used by each authentication method 481 MUST be defined in the specification for that method (or its 482 amendments). 484 Where an SMTP command is being reported as a "property", the MAIL 485 FROM command MUST be represented by "mailfrom" and the RCPT TO 486 command MUST be represented by "rcptto". All other SMTP commands 487 MUST be represented unchanged. 489 A "ptype" value of "policy" indicates a policy decision about the 490 message not specific to a property of the message that could be 491 extracted. For example, if a method would normally report a 492 "ptype.property" of "header.From" and no From: header field was 493 present, the method can use "policy" to indicate that no conclusion 494 about the authenticity of the message could be reached. 496 2.3. Authentication Identifier Field 498 Every Authentication-Results header field has an authentication 499 service identifier field ("authserv-id" above). This is similar in 500 syntax to a fully-qualified domain name. 502 The authentication service identifier field provides a unique 503 identifier that refers to the authenticating service within a given 504 ADMD. The uniqueness of the identifier MUST be guaranteed by the 505 ADMD that generates it and MUST pertain to exactly that one ADMD. 506 This identifier is intended to be machine-readable and not 507 necessarily meaningful to users. MUAs or downstream filters SHOULD 508 use this identifier to determine whether or not the data contained in 509 an Authentication-Results header field ought to be used or ignored. 511 For simplicity and scalability, the authentication service identifier 512 SHOULD be a common token used throughout the ADMD, such as the DNS 513 domain name used by or within that ADMD. 515 For tracing and debugging purposes, the authentication identifier MAY 516 instead be the hostname of the MTA performing the authentication 517 check whose result is being reported. This is also useful for 518 another purpose, as described in Section 4. Moreover, some 519 implementations have considered appending a delimiter such as "/" and 520 following it with useful transport tracing data such as the [SMTP] 521 queue ID or a timestamp. 523 Note, however, that using a local, relative identifier like a single 524 hostname, rather than a hierarchical and globally unique ADMD 525 identifier like a DNS domain name, makes configuration more difficult 526 for large sites. The hierarchical identifier permits aggregating 527 related, trusted systems together under a single, parent identifier, 528 which in turn permits assessing the trust relationship with a single 529 reference. The alternative is a flat namespace requiring 530 individually listing each trusted system. Since consumers will use 531 the identifier to determine whether to use the contents of the header 532 field: 534 o Changes to the identifier impose a large, centralized 535 administrative burden. 537 o Ongoing administrative changes require constantly updating this 538 centralized table, making it difficult to ensure that an MUA or 539 downstream filter will have access to accurate information for 540 assessing the usability of the header field's content. In 541 particular, consumers of the header field will need to know not 542 only the current identifier(s) in use, but previous ones as well 543 to account for delivery latency or later re-assessment of the 544 header field's contents. 546 Examples of valid authentication identifiers are "example.com", 547 "mail.example.org", "ms1.newyork.example.com", and "example-auth". 549 2.4. Version Tokens 551 The grammar above provides for the optional inclusion of versions on 552 both the header field itself (attached to the authserv-id token) and 553 on each of the methods being reported. The method version refers to 554 the method itself, which is specified in the documents describing 555 those methods, while the authserv-id version refers to this document 556 and thus the syntax of this header field. 558 The purpose of including these is to avoid misinterpretation of the 559 results. That is, if a parser finds a version after an authserv-id 560 that it does not explicitly know, it can immediately discontinue 561 trying to parse since what follows might not be in an expected 562 format. For a method version, the parser SHOULD ignore a method 563 result if the version is not supported in case the semantics of the 564 result have a different meaning than what is expected. For example, 565 if a hypothetical DKIM version 2 yielded a "pass" result for 566 different reasons than version 1 does, a consumer of this field might 567 not want to use the altered semantics. Allowing versions in the 568 syntax is a way to indicate this and let the consumer of the header 569 field decide. 571 2.5. Result Values 573 Each individual authentication method returns one of a set of 574 specific result values. The subsections below define these results 575 for the authentication methods specifically supported by this 576 document, and verifiers SHOULD use these values as described below. 577 New methods not specified in this document intended to be supported 578 by the header field defined here MUST include a similar result table 579 either in its defining document or in a supplementary one. 581 2.5.1. DKIM and DomainKeys Results 583 The result values used by [DKIM] and [DOMAINKEYS] are as follows: 585 none: The message was not signed. 587 pass: The message was signed, the signature or signatures were 588 acceptable to the verifier, and the signature(s) passed 589 verification tests. 591 fail: The message was signed and the signature or signatures were 592 acceptable to the verifier, but they failed the verification 593 test(s). 595 policy: The message was signed but the signature or signatures were 596 not acceptable to the verifier. 598 neutral: The message was signed but the signature or signatures 599 contained syntax errors or were not otherwise able to be 600 processed. This result SHOULD also be used for other failures not 601 covered elsewhere in this list. 603 temperror: The message could not be verified due to some error that 604 is likely transient in nature, such as a temporary inability to 605 retrieve a public key. A later attempt may produce a final 606 result. 608 permerror: The message could not be verified due to some error that 609 is unrecoverable, such as a required header field being absent. A 610 later attempt is unlikely to produce a final result. 612 A signature is "acceptable to the verifier" if it passes local policy 613 checks (or there are no specific local policy checks). For example, 614 a verifier might require that the signature(s) on the message be 615 added using the DNS domain present in the From: header field of the 616 message, thus making third-party signatures unacceptable. 618 [DKIM] advises that if a message fails verification, it is to be 619 treated as an unsigned message. A report of "fail" here permits the 620 receiver of the report to decide how to handle the failure. A report 621 of "neutral" or "none" preempts that choice, ensuring the message 622 will be treated as if it had not been signed. 624 2.5.2. SPF and Sender-ID Results 626 The result values are used by [SPF] and [SENDERID] as follows: 628 none: No policy records were published at the sender's DNS domain. 630 neutral: The sender's ADMD has asserted that it cannot or does not 631 want to make a statement as to whether the sending IP address is 632 authorized to send mail using the sender's DNS domain. 634 pass: The client is authorized by the sender's ADMD to inject or 635 relay mail on behalf of the sender's DNS domain. 637 policy: The client is authorized to inject or relay mail on behalf 638 of the sender's DNS domain according to the authentication 639 method's algorithm, but local policy dictates that the result is 640 unacceptable. 642 fail: This client is explicitly not authorized to inject or relay 643 mail using the sender's DNS domain. 645 softfail: The sender's ADMD believes the client was not authorized 646 to inject or relay mail using the sender's DNS domain, but is 647 unwilling to make a strong assertion to that effect. 649 temperror: The message could not be verified due to some error that 650 is likely transient in nature, such as a temporary inability to 651 retrieve a policy record from DNS. A later attempt may produce a 652 final result. 654 permerror: The message could not be verified due to some error that 655 is unrecoverable, such as a required header field being absent or 656 a syntax error in a retrieved DNS TXT record. A later attempt is 657 unlikely to produce a final result. 659 The distinction between and interpretation of "none" and "neutral" 660 under these methods is discussed further in [SPF]. 662 The "policy" result would be returned if, for example, [SPF] returned 663 as "pass" result, but a local policy check matches the sending DNS 664 domain to one found in an explicit list of unacceptable DNS domains 665 (e.g., spammers). 667 If the retrieved sender policies used to evaluate [SPF] and 668 [SENDERID] do not contain explicit provisions for authenticating the 669 local-part (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" 670 reported along with results for these mechanisms SHOULD NOT include 671 the local-part. 673 2.5.3. "iprev" Results 675 The result values are used by the "iprev" method, defined in 676 Section 3, are as follows: 678 pass: The DNS evaluation succeeded, i.e., the "reverse" and 679 "forward" lookup results were returned and were in agreement. 681 fail: The DNS evaluation failed. In particular, the "reverse" and 682 "forward" lookups each produced results but they were not in 683 agreement, or the "forward" query completed but produced no 684 result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an 685 RCODE of 0 (NOERROR) in a reply containing no answers, was 686 returned. 688 temperror: The DNS evaluation could not be completed due to some 689 error that is likely transient in nature, such as a temporary DNS 690 error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or 691 other error condition resulted. A later attempt may produce a 692 final result. 694 permerror: The DNS evaluation could not be completed because no PTR 695 data are published for the connecting IP address, e.g., a DNS 696 RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) 697 in a reply containing no answers, was returned. This prevented 698 completion of the evaluation. A later attempt is unlikely to 699 produce a final result. 701 There is no "none" for this method since any TCP connection 702 delivering email has an IP address associated with it, so some kind 703 of evaluation will always be possible. 705 For discussion of the format of DNS replies, see [DNS]. 707 2.5.4. SMTP AUTH Results 709 The result values are used by the [AUTH] method are as follows: 711 none: SMTP authentication was not attempted. 713 pass: The SMTP client had authenticated to the server reporting the 714 result using the protocol described in [AUTH]. 716 fail: The SMTP client had attempted to authenticate to the server 717 using the protocol described in [AUTH] but was not successful, yet 718 continued to send the message about which a result is being 719 reported. 721 temperror: The SMTP client attempted to authenticate using the 722 protocol described in [AUTH] but was not able to complete the 723 attempt due to some error which is likely transient in nature, 724 such as a temporary Lightweight Directory Access Protocol (LDAP) 725 lookup error. A later attempt may produce a final result. 727 permerror: The SMTP client attempted to authenticate using the 728 protocol described in [AUTH] but was not able to complete the 729 attempt due to some error that is likely not transient in nature, 730 such as a permanent LDAP lookup error. A later attempt is not 731 likely produce a final result. 733 Note that an agent making use of the data provided by this header 734 field SHOULD consider "fail" and "temperror" to be the synonymous in 735 terms of message authentication, i.e., the client did not 736 authenticate. 738 2.5.5. Extension Result Codes 740 Additional result codes (extension results) might be defined in the 741 future by later revisions or extensions to this specification. 743 Result codes MUST be registered with the Internet Assigned Numbers 744 Authority (IANA) and preferably published in an RFC. See Section 6 745 for further details. 747 Extension results MUST only be used within ADMDs that have explicitly 748 consented to use them. These results and the parameters associated 749 with them are not formally documented. Therefore, they are subject 750 to change at any time and not suitable for production use. Any MTA, 751 MUA or downstream filter intended for production use SHOULD ignore or 752 delete any Authentication-Results header field that includes an 753 extension result. 755 2.6. Authentication Methods 757 This section defines the supported authentication methods and 758 discusses the proper means for applying experimental and other 759 extension methods. 761 2.6.1. Definitions for Existing Methods 763 As they are currently existing specifications for message 764 authentication, it is appropriate to define an authentication method 765 identifier for each of [ADSP], [ATPS], [AUTH], [DKIM], [DOMAINKEYS], 766 [SENDERID], [SPF], and [VBR]. Therefore, the authentication method 767 identifiers "dkim-adsp", "dkim-atps", "auth", "dkim", "domainkeys", 768 "sender-id", "spf", and "vbr", respectively are defined for MTAs 769 applying those specifications for email message authentication. 771 Furthermore, method "iprev" is defined in Section 3. 773 See Section 6 for details. 775 2.6.2. Extension Methods 777 Additional authentication method identifiers (extension methods) may 778 be defined in the future by later revisions or extensions to this 779 specification. Method identifiers MUST be registered with the 780 Internet Assigned Numbers Authority (IANA) and, preferably, published 781 in an RFC. See Section 6 for further details. 783 Extension methods can be defined for the following reasons: 785 1. To allow additional information from new authentication systems 786 to be communicated to MUAs or downstream filters. The names of 787 such identifiers SHOULD reflect the name of the method being 788 defined, but ought not be needlessly long. 790 2. To allow the creation of "sub-identifiers" that indicate 791 different levels of authentication and differentiate between 792 their relative strengths, e.g., "auth1-weak" and "auth1-strong". 794 Authentication method implementers are encouraged to provide adequate 795 information, via [MAIL] comments if necessary, to allow an MUA 796 developer to understand or relay anciliary details of authentication 797 results. For example, if it might be of interest to relay what data 798 was used to perform an evaluation, such information could be relayed 799 as a comment in the header field, such as: 801 Authentication-Results: example.com; 802 foo=pass bar.baz=blob (2 of 3 tests OK) 804 Experimental method identifiers MUST only be used within ADMDs that 805 have explicitly consented to use them. These method identifiers and 806 the parameters associated with them are not documented in RFCs. 807 Therefore, they are subject to change at any time and not suitable 808 for production use. Any MTA, MUA, or downstream filter intended for 809 production use SHOULD ignore or delete any Authentication-Results 810 header field that includes an experimental (unknown) method 811 identifier. 813 3. The "iprev" Authentication Method 815 This section defines an additional authentication method called 816 "iprev". 818 In general, "iprev" is an attempt to verify that a client appears to 819 be valid based on some DNS queries. Upon receiving a session 820 initiation of some kind from a client, the IP address of the client 821 peer is queried for matching names (i.e., a number-to-name 822 translation, also known as a "reverse lookup" or a "PTR" record 823 query). Once that result is acquired, a lookup of each of the names 824 (i.e., a name-to-number translation, or an "A" or "AAAA" record 825 query) thus retrieved is done. The response to this second check 826 will typically result in at least one mapping back to the client's IP 827 address. 829 Expressed as an algorithm: If the client peer's IP address is I, the 830 list of names to which I maps (after a "PTR" query) is the set N, and 831 the union of IP addresses to which each member of N maps (after 832 corresponding "A" and "AAAA" queries) is L, then this test is 833 successful if I is an element of L. 835 The response to a PTR query could contain multiple names. To prevent 836 heavy DNS loads, agents performing these queries MUST be implemented 837 such that the number of names evaluated by generation of 838 corresponding A or AAAA queries is finite, though it MAY be 839 configurable by an administrator. As an example, Section 5.5 of 840 [SPF] chose a limit of 10 for its implementation of this algorithm. 842 [DNS-IP6] discusses the query formats for the IPv6 case. 844 A successful test using this algorithm constitutes a result of "pass" 845 since the ADMD in which the client's PTR claims it belongs has 846 confirmed that claim by including corresponding data in its DNS 847 domain. A failure to match constitutes a "fail". There is no case 848 in which a "neutral" result can be returned. The remaining 849 "temperror" and "permerror" cases refer, respectively, to temporary 850 and permanent DNS query errors. 852 There is some contention regarding the wisdom and reliability of this 853 test. For example, in some regions it can be difficult for this test 854 ever to pass because the practice of arranging to match the forward 855 and reverse DNS is infrequently observed. Therefore, the precise 856 implementation details of how a verifier performs an "iprev" test are 857 not specified here. The verifier MAY report a successful or failed 858 "iprev" test at its discretion having done some kind of check of the 859 validity of the connection's identity using DNS. It is incumbent 860 upon an agent making use of the reported "iprev" result to understand 861 what exactly that particular verifier is attempting to report. 863 Extensive discussion of reverse DNS mapping and its implications can 864 be found in [DNSOP-REVERSE]. In particular, it recommends that 865 applications avoid using this test as a means of authentication or 866 security. Its presence in this document is not an endorsement, but 867 is merely acknowledgement that the method remains common and provides 868 the means to relay the results of that test. 870 4. Adding the Header Field to A Message 872 This specification makes no attempt to evaluate the relative 873 strengths of various message authentication methods that may become 874 available. As such, the order of the presented authentication 875 methods and results MUST NOT be used either to imply or infer the 876 importance or strength of any given method over another. Instead, 877 the MUA or downstream filter consuming this header field is to 878 interpret the result of each method based on its own knowledge of 879 what that method evaluates. 881 Each "method" MUST refer to an authentication method declared in the 882 IANA registry, or an extension method as described in Section 2.6.2, 883 and each "result" MUST refer to a result code declared in the IANA 884 registry, or an extension result code as defined in Section 2.5.5. 885 See Section 6 for further information about the registered methods 886 and result codes. 888 An MTA compliant with this specification MUST add this header field 889 (after performing one or more message authentication tests) to 890 indicate which MTA or ADMD performed the test, which test got applied 891 and what the result was. If an MTA applies more than one such test, 892 it MUST add this header field either once per test, or once 893 indicating all of the results. An MTA MUST NOT add a result to an 894 existing header field. 896 An MTA MAY add this header field containing only the authentication 897 identifier portion and the "none" token (see Section 2.2) to indicate 898 explicitly that no message authentication schemes were applied prior 899 to delivery of this message. 901 An MTA adding this header field MUST take steps to identify it as 902 legitimate to the MUAs or downstream filters that will ultimately 903 consume its content. One REQUIRED process to do so is described in 904 Section 5. Further measures may be necessary in some environments. 905 Some possible solutions are enumerated in Section 7.1. This document 906 does not mandate any specific solution to this issue as each 907 environment has its own facilities and limitations. 909 For MTAs that add this header field, adding header fields in order 910 (at the top), per Section 3.6 of [MAIL], is particularly important. 911 Moreover, this header field SHOULD be inserted above any other trace 912 header fields such MTAs might prepend. This allows easy detection of 913 header fields that can be trusted. 915 End users making direct use of this header field might inadvertently 916 trust information that has not been properly vetted. If, for 917 example, a basic [SPF] result were to be relayed that claims an 918 authenticated addr-spec, the local-part of that addr-spec has 919 actually not been authenticated. Thus, an MTA adding this header 920 field SHOULD NOT include any data that has not been authenticated by 921 the method(s) being applied. Moreover, MUAs SHOULD NOT render to 922 users such information if it is presented by a method known not to 923 authenticate it. 925 4.1. Header Field Position and Interpretation 927 In order to ensure non-ambiguous results and avoid the impact of 928 false header fields, MUAs and downstream filters SHOULD NOT interpret 929 this header field unless specifically instructed to do so by the user 930 or administrator. That is, this interpretation should not be "on by 931 default". Naturally then, users or administrators ought not activate 932 such a feature unless they are certain the header field will be added 933 by the border MTA that accepts the mail that is ultimately read by 934 the MUA, and instances of the header field appearing to originate 935 within the ADMD but are actually added by foreign MTAs will be 936 removed before delivery. 938 Furthermore, MUAs and downstream filters SHOULD NOT interpret this 939 header field unless the authentication service identifier it bears 940 appears to be one used within its own ADMD as configured by the user 941 or administrator. 943 MUAs and downstream filters MUST ignore any result reported using a 944 "result" not specified in the result code registry, or a "ptype" not 945 listed in the corresponding registry for such values as defined in 946 Section 6. Moreover, such agents MUST ignore a result indicated for 947 any "method" they do not specifically support. 949 An MUA SHOULD NOT reveal these results to end users unless the 950 results are accompanied by, at a minimum, some associated reputation 951 data about the authenticated origin identifiers within the message. 952 For example, an attacker could register examp1e.com (note the digit 953 "one") and send signed mail to intended victims; a verifier would 954 detect that the signature was valid and report a "pass" even though 955 it's clear the DNS domain name was intended to mislead. See 956 Section 7.2 for further discussion. 958 As stated in Section 2.1, this header field SHOULD be treated as 959 though it were a trace header field as defined in Section 3.6.7 of 960 [MAIL], and hence MUST NOT be reordered and MUST be prepended to the 961 message, so that there is generally some indication upon delivery of 962 where in the chain of handling MTAs the message authentication was 963 done. 965 MUAs SHOULD ignore instances of this header field discovered within 966 message/rfc822 [MIME] attachments. 968 Further discussion of this can be found in Section 7 below. 970 4.2. Local Policy Enforcement 972 If a site's local policy is to consider a non-recoverable failure 973 result (e.g., "fail" for DKIM, "hardfail" for SPF) for any particular 974 authentication method as justification to reject the message 975 completely, the border MTA SHOULD issue an [SMTP] rejection response 976 to the message rather than adding this header field with the failure 977 result and allowing it to proceed toward delivery. This is more 978 desirable than allowing the message to reach an internal host's MTA 979 or spam filter, thus possibly generating a local rejection such as a 980 [DSN] to a forged originator. Such generated rejections are 981 colloquially known as "backscatter". 983 The same MAY also be done for local policy decisions overriding the 984 results of the authentication methods (e.g., the "policy" result 985 codes described in Section 2.5). 987 Such rejections at the SMTP protocol level are not possible if local 988 policy is enforced at the MUA and not the MTA. 990 5. Removing the Header Field 992 For security reasons, any MTA conforming to this specification MUST 993 delete any discovered instance of this header field that claims, by 994 virtue of its authentication service identifier, to have been added 995 within its trust boundary and that did not come directly from another 996 trusted MTA. For example, an MTA for example.com receiving a message 997 MUST delete or otherwise obscure any instance of this header field 998 bearing an authentication service identifier indicating the header 999 field was added within example.com prior to adding its own header 1000 fields. This could mean each MTA will have to be equipped with a 1001 list of internal MTAs known to be compliant (and hence trustworthy). 1003 For simplicity and maximum security, a border MTA MAY remove all 1004 instances of this header field on mail crossing into its trust 1005 boundary. However, this may conflict with the desire to access 1006 authentication results performed by trusted external service 1007 providers. It may also invalidate signed messages whose signatures 1008 cover external instances of this header field. A more robust border 1009 MTA could allow a specific list of authenticating MTAs whose 1010 information is to be admitted, removing all others. 1012 As stated in Section 1.2, a formal definition of "trust boundary" is 1013 deliberately not made here. It is entirely possible that a border 1014 MTA for example.com will explicitly trust authentication results 1015 asserted by upstream host example.net even though they exist in 1016 completely disjoint administrative boundaries. In that case, the 1017 border MTA MAY elect not to delete those results; moreover, the 1018 upstream host doing some authentication work could apply a signing 1019 technology such as [DKIM] on its own results to assure downstream 1020 hosts of their authenticity. An example of this is provided in 1021 Appendix C. 1023 Similarly, in the case of messages signed using [DKIM] or other 1024 message signing methods that sign header fields, this removal action 1025 could invalidate one or more signatures on the message if they 1026 covered the header field to be removed. This behavior can be 1027 desirable since there's little value in validating the signature on a 1028 message with forged header fields. However, signing agents MAY 1029 therefore elect to omit these header fields from signing to avoid 1030 this situation. 1032 An MTA SHOULD remove any instance of this header field bearing a 1033 version (express or implied) that it does not support. However, an 1034 MTA MUST remove such a header field if the [SMTP] connection relaying 1035 the message is not from a trusted internal MTA. 1037 6. IANA Considerations 1039 IANA has registered the defined header field and created two tables 1040 as described below. These registry actions were originally defined 1041 by [AR-ORIG] and are repeated here to provide a single, current 1042 reference. 1044 6.1. The Authentication-Results Header Field 1046 [AR-ORIG] added the "Authentication-Results" header field to the IANA 1047 Permanent Message Header Field Registry, per the procedure found in 1048 [IANA-HEADERS]. That entry is to be updated to reference this 1049 document. The following is the registration template: 1051 Header field name: Authentication-Results 1052 Applicable protocol: mail ([MAIL]) 1053 Status: Standard 1054 Author/Change controller: IETF 1055 Specification document(s): [this memo] 1056 Related information: 1057 Requesting review of any proposed changes and additions to 1058 this field is recommended. 1060 6.2. Email Authentication Method Name Registry 1062 Names of message authentication methods supported by this 1063 specification are to be registered with IANA, with the exception of 1064 experimental names as described in Section 2.6.2. A registry was 1065 created by [AR-ORIG] for this purpose. This document changes the 1066 rules governing that registry. 1068 New entries are assigned only for values that have received Expert 1069 Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be 1070 appointed by the IESG. The Designated Expert has discretion to 1071 request that a publication be referenced if a clear, concise 1072 definition of the authentication method cannot be provided such that 1073 interoperability is assured. Registrations should otherwise be 1074 permitted. The Designated Expert can also handle requests to mark 1075 any current registration as "deprecated". 1077 Each method must register a name, the specification that defines it, 1078 a version number associated with the method being registered 1079 (preferably starting at "1"), and zero or more "ptype" values 1080 appropriate for use with that method, which "property" value(s) 1081 should be reported by that method, and a description of the "value" 1082 to be used with each. 1084 All existing registry entries that reference [AR-ORIG] are to be 1085 updated to reference this document. 1087 IANA is also requested to add a "version" field to all existing 1088 registry entries. All current methods are to be recorded as version 1089 "1". 1091 6.3. Email Authentication Result Name Registry 1093 Names of message authentication result codes supported by this 1094 specification must be registered with IANA, with the exception of 1095 experimental codes as described in Section 2.5.5. A registry was 1096 created by [AR-ORIG] for this purpose. This document changes the 1097 rules governing that registry. 1099 New entries are assigned only for values that have received Expert 1100 Review, per [IANA-CONSIDERATIONS]. The Designated Expert shall be 1101 appointed by the IESG. The Designated Expert has discretion to 1102 request that a publication be referenced if a clear, concise 1103 definition of the authentication result cannot be provided such that 1104 interoperability is assured. Registrations should otherwise be 1105 permitted. The Designated Expert can also handle requests to mark 1106 any current registration as "deprecated". 1108 All existing registry entries that reference [AR-ORIG] are to be 1109 updated to reference this document. 1111 7. Security Considerations 1113 The following security considerations apply when adding or processing 1114 the "Authentication-Results" header field: 1116 7.1. Forged Header Fields 1118 An MUA or filter that accesses a mailbox whose mail is handled by a 1119 non-conformant MTA, and understands Authentication-Results header 1120 fields, could potentially make false conclusions based on forged 1121 header fields. A malicious user or agent could forge a header field 1122 using the DNS domain of a receiving ADMD as the authserv-id token in 1123 the value of the header field, and with the rest of the value claim 1124 that the message was properly authenticated. The non-conformant MTA 1125 would fail to strip the forged header field, and the MUA could 1126 inappropriately trust it. 1128 It is for this reason an MUA should not have processing of the 1129 "Authentication-Results" header field enabled by default; instead it 1130 should be ignored, at least for the purposes of enacting filtering 1131 decisions, unless specifically enabled by the user or administrator 1132 after verifying that the border MTA is compliant. It is acceptable 1133 to have an MUA aware of this specification, but have an explicit list 1134 of hostnames whose "Authentication-Results" header fields are 1135 trustworthy; however, this list should initially be empty. 1137 Proposed alternate solutions to this problem are nascent: 1139 1. Possibly the simplest is a digital signature protecting the 1140 header field, such as using [DKIM], that can be verified by an 1141 MUA by using a posted public key. Although one of the main 1142 purposes of this document is to relieve the burden of doing 1143 message authentication work at the MUA, this only requires that 1144 the MUA learn a single authentication scheme even if a number of 1145 them are in use at the border MTA. Note that [DKIM] requires 1146 that the From header field be signed, although in this 1147 application, the signing agent (a trusted MTA) likely cannot 1148 authenticate that value, so the fact that it is signed should be 1149 ignored. 1151 2. Another would be a means to interrogate the MTA that added the 1152 header field to see if it is actually providing any message 1153 authentication services and saw the message in question, but this 1154 isn't especially palatable given the work required to craft and 1155 implement such a scheme. 1157 3. Yet another might be a method to interrogate the internal MTAs 1158 that apparently handled the message (based on Received: header 1159 fields) to determine whether any of them conform to Section 5 of 1160 this memo. This, too, has potentially high barriers to entry. 1162 4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to 1163 allow an MUA or filtering agent to acquire the "authserv-id" in 1164 use within an ADMD, thus allowing it to identify which 1165 Authentication-Results header fields it can trust. 1167 5. On the presumption that internal MTAs are fully compliant with 1168 Section 3.6 of [MAIL], and the compliant internal MTAs are using 1169 their own host names or the ADMD's DNS domain name as the 1170 "authserv-id" token, the header field proposed here should always 1171 appear above a Received: header added by a trusted MTA. This can 1172 be used as a test for header field validity. 1174 Support for some of these is being considered for future work. 1176 In any case, a mechanism needs to exist for an MUA or filter to 1177 verify that the host that appears to have added the header field (a) 1178 actually did so, and (b) is legitimately adding that header field for 1179 this delivery. Given the variety of messaging environments deployed 1180 today, consensus appears to be that specifying a particular mechanism 1181 for doing so is not appropriate for this document. 1183 Mitigation of the forged header field attack can also be accomplished 1184 by moving the authentication results data into meta-data associated 1185 with the message. In particular, an [SMTP] extension could be 1186 established that is used to communicate authentication results from 1187 the border MTA to intermediate and delivery MTAs; the latter of these 1188 could arrange to store the authentication results as meta-data 1189 retrieved and rendered along with the message by an [IMAP] client 1190 aware of a similar extension in that protocol. The delivery MTA 1191 would be told to trust data via this extension only from MTAs it 1192 trusts, and border MTAs would not accept data via this extension from 1193 any source. There is no vector in such an arrangement for forgery of 1194 authentication data by an outside agent. 1196 7.2. Misleading Results 1198 Until some form of service for querying the reputation of a sending 1199 agent is widely deployed, the existence of this header field 1200 indicating a "pass" does not render the message trustworthy. It is 1201 possible for an arriving piece of spam or other undesirable mail to 1202 pass checks by several of the methods enumerated above (e.g., a piece 1203 of spam signed using [DKIM] by the originator of the spam, which 1204 might be a spammer or a compromised system). In particular, this 1205 issue is not resolved by forged header field removal discussed above. 1207 Hence, MUAs and downstream filters must take some care with use of 1208 this header even after possibly malicious headers are scrubbed. 1210 7.3. Header Field Position 1212 Despite the requirements of [MAIL], header fields can sometimes be 1213 reordered enroute by intermediate MTAs. The goal of requiring header 1214 field addition only at the top of a message is an acknowledgement 1215 that some MTAs do reorder header fields, but most do not. Thus, in 1216 the general case, there will be some indication of which MTAs (if 1217 any) handled the message after the addition of the header field 1218 defined here. 1220 7.4. Reverse IP Query Denial-of-Service Attacks 1222 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 1223 for verifiers that attempt DNS-based identity verification of 1224 arriving client connections. A verifier wishing to do this check and 1225 report this information need to take care not to go to unbounded 1226 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1227 making use of an "iprev" result specified by this document need to be 1228 aware of the algorithm used by the verifier reporting the result and, 1229 especially, its limitations. 1231 7.5. Mitigation of Backscatter 1233 Failing to follow the instructions of Section 4.2 can result in a 1234 denial-of-service attack caused by the generation of [DSN] messages 1235 (or equivalent) to addresses that did not send the messages being 1236 rejected. 1238 7.6. Internal MTA Lists 1240 Section 5 describes a procedure for scrubbing header fields that may 1241 contain forged authentication results about a message. A compliant 1242 installation will have to include, at each MTA, a list of other MTAs 1243 known to be compliant and trustworthy. Failing to keep this list 1244 current as internal infrastructure changes may expose an ADMD to 1245 attack. 1247 7.7. Attacks against Authentication Methods 1249 If an attack becomes known against an authentication method, clearly 1250 then the agent verifying that method can be fooled into thinking an 1251 inauthentic message is authentic, and thus the value of this header 1252 field can be misleading. It follows that any attack against the 1253 authentication methods supported by this document (and later 1254 amendments to it) is also a security consideration here. 1256 7.8. Intentionally Malformed Header Fields 1258 It is possible for an attacker to add an Authentication-Results 1259 header field that is extraordinarily large or otherwise malformed in 1260 an attempt to discover or exploit weaknesses in header field parsing 1261 code. Implementers must thoroughly verify all such header fields 1262 received from MTAs and be robust against intentionally as well as 1263 unintentionally malformed header fields. 1265 7.9. Compromised Internal Hosts 1267 An internal MUA or MTA that has been compromised could generate mail 1268 with a forged From header field and a forged Authentication-Results 1269 header field that endorses it. Although it is clearly a larger 1270 concern to have compromised internal machines than it is to prove the 1271 value of this header field, this risk can be mitigated by arranging 1272 that internal MTAs will remove this header field if it claims to have 1273 been added by a trusted border MTA (as described above), yet the 1274 [SMTP] connection is not coming from an internal machine known to be 1275 running an authorized MTA. However, in such a configuration, 1276 legitimate MTAs will have to add this header field when legitimate 1277 internal-only messages are generated. This is also covered in 1278 Section 5. 1280 7.10. Encapsulated Instances 1282 [MIME] messages can contain attachments of type "message/rfc822", 1283 which contain other [MAIL] messages. Such an encapsulated message 1284 can also contain an Authentication-Results header field. Although 1285 the processing of these is outside of the intended scope of this 1286 document (see Section 1.3), some early guidance to MUA developers is 1287 appropriate here. 1289 Since MTAs are unlikely to strip Authentication-Results header fields 1290 after mailbox delivery, MUAs are advised in Section 4.1 to ignore 1291 such instances within [MIME] attachments. Moreover, when extracting 1292 a message digest to separate mail store messages or other media, such 1293 header fields should be removed so that they will never be 1294 interpreted improperly by MUAs that might later consume them. 1296 7.11. Reverse Mapping 1298 Although Section 3 of this memo includes explicit support for the 1299 "iprev" method, its value as an authentication mechanism is limited. 1300 Implementers of both this proposal and agents that use the data it 1301 relays are encouraged to become familiar with the issues raised by 1302 [DNSOP-REVERSE] when deciding whether or not to include support for 1303 "iprev". 1305 8. References 1307 8.1. Normative References 1309 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for 1310 Syntax Specifications: ABNF", STD 68, 1311 RFC 5234, January 2008. 1313 [AR-ORIG] Kucherawy, M., "Message Header Field for 1314 Indicating Message Authentication Status", 1315 RFC 5451, April 2009. 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 [SECURITY] Rescorla, E. and B. Korver, "Guidelines for 1386 Writing RFC Text on Security Considerations", 1387 BCP 72, RFC 3552, July 2003. 1389 [SENDERID] Lyon, J. and M. Wong, "Sender ID: 1390 Authenticating E-Mail", RFC 4406, April 2006. 1392 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 1393 RFC 5321, October 2008. 1395 [SPF] Wong, M. and W. Schlitt, "Sender Policy 1396 Framework (SPF) for Authorizing Use of Domains 1397 in E-Mail, Version 1", RFC 4408, April 2006. 1399 [VBR] Hoffman, P., Levine, J., and A. Hathcock, 1400 "Vouch By Reference", RFC 5518, April 2009. 1402 Appendix A. Acknowledgements 1404 The author wishes to acknowledge the following for their review and 1405 constructive criticism of this update: Dave Cridland, Scott 1406 Kitterman, S. Moonesamy, Alessandro Vesely, [other names] 1408 Appendix B. Legacy MUAs 1410 Implementers of this protocol should be aware that many MUAs are 1411 unlikely to be retrofitted to support the new header field and its 1412 semantics. In the interests of convenience and quicker adoption, a 1413 delivery MTA might want to consider adding things that are processed 1414 by existing MUAs in addition to the Authentication-Results header 1415 field. One suggestion is to include a Priority header field, on 1416 messages that don't already have such a header field, containing a 1417 value that reflects the strength of the authentication that was 1418 accomplished, e.g., "low" for weak or no authentication, "normal" or 1419 "high" for good or strong authentication. 1421 Some modern MUAs can already filter based on the content of this 1422 header field. However, there is keen interest in having MUAs make 1423 some kind of graphical representation of this header field's meaning 1424 to end users. Until this capability is added, other interim means of 1425 conveying authentication results may be necessary while this proposal 1426 and its successors are adopted. 1428 Appendix C. Authentication-Results Examples 1430 This section presents some examples of the use of this header field 1431 to indicate authentication results. 1433 C.1. Trivial Case; Header Field Not Present 1435 The trivial case: 1437 Received: from mail-router.example.com 1438 (mail-router.example.com [192.0.2.1]) 1439 by server.example.org (8.11.6/8.11.6) 1440 with ESMTP id g1G0r1kA003489; 1441 Fri, Feb 15 2002 17:19:07 -0800 1442 From: sender@example.com 1443 Date: Fri, Feb 15 2002 16:54:30 -0800 1444 To: receiver@example.org 1445 Message-Id: <12345.abc@example.com> 1446 Subject: here's a sample 1448 Hello! Goodbye! 1450 Example 1: Trivial case 1452 The "Authentication-Results" header field is completely absent. The 1453 MUA may make no conclusion about the validity of the message. This 1454 could be the case because the message authentication services were 1455 not available at the time of delivery, or no service is provided, or 1456 the MTA is not in compliance with this specification. 1458 C.2. Nearly Trivial Case; Service Provided, But No Authentication Done 1460 A message that was delivered by an MTA that conforms to this 1461 specification but provides no actual message authentication service: 1463 Authentication-Results: example.org/1; none 1464 Received: from mail-router.example.com 1465 (mail-router.example.com [192.0.2.1]) 1466 by server.example.org (8.11.6/8.11.6) 1467 with ESMTP id g1G0r1kA003489; 1468 Fri, Feb 15 2002 17:19:07 -0800 1469 From: sender@example.com 1470 Date: Fri, Feb 15 2002 16:54:30 -0800 1471 To: receiver@example.org 1472 Message-Id: <12345.abc@example.com> 1473 Subject: here's a sample 1475 Hello! Goodbye! 1477 Example 2: Header present but no authentication done 1479 The "Authentication-Results" header field is present, showing that 1480 the delivering MTA conforms to this specification. It used its DNS 1481 domain name as the authserv-id. The presence of "none" (and the 1482 absence of any method and result tokens) indicates that no message 1483 authentication was done. The version number of the specification to 1484 which the field's content conforms is explicitly provided. 1486 C.3. Service Provided, Authentication Done 1488 A message that was delivered by an MTA that conforms to this 1489 specification and applied some message authentication: 1491 Authentication-Results: example.com; 1492 spf=pass smtp.mailfrom=example.net 1493 Received: from dialup-1-2-3-4.example.net 1494 (dialup-1-2-3-4.example.net [192.0.2.200]) 1495 by mail-router.example.com (8.11.6/8.11.6) 1496 with ESMTP id g1G0r1kA003489; 1497 Fri, Feb 15 2002 17:19:07 -0800 1498 From: sender@example.net 1499 Date: Fri, Feb 15 2002 16:54:30 -0800 1500 To: receiver@example.com 1501 Message-Id: <12345.abc@example.net> 1502 Subject: here's a sample 1504 Hello! Goodbye! 1506 Example 3: Header reporting results 1508 The "Authentication-Results" header field is present, indicating that 1509 the border MTA conforms to this specification. The authserv-id is 1510 once again the DNS domain name. Furthermore, the message was 1511 authenticated by that MTA via the method specified in [SPF]. Note 1512 that since that method cannot authenticate the local-part, it has 1513 been omitted from the result's value. The MUA could extract and 1514 relay this extra information if desired. 1516 C.4. Service Provided, Several Authentications Done, Single MTA 1518 A message that was relayed inbound via a single MTA that conforms to 1519 this specification and applied three different message authentication 1520 checks: 1522 Authentication-Results: example.com; 1523 auth=pass (cram-md5) smtp.auth=sender@example.com; 1524 spf=pass smtp.mailfrom=example.com 1525 Authentication-Results: example.com; 1526 sender-id=pass header.from=example.com 1527 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1528 (dialup-1-2-3-4.example.net [192.0.2.200]) 1529 by mail-router.example.com (8.11.6/8.11.6) 1530 with ESMTP id g1G0r1kA003489; 1531 Fri, Feb 15 2002 17:19:07 -0800 1532 Date: Fri, Feb 15 2002 16:54:30 -0800 1533 To: receiver@example.net 1534 From: sender@example.com 1535 Message-Id: <12345.abc@example.com> 1536 Subject: here's a sample 1538 Hello! Goodbye! 1540 Example 4: Headers reporting results from one MTA 1542 The "Authentication-Results" header field is present, indicating the 1543 delivering MTA conforms to this specification. Once again, the 1544 receiving DNS domain name is used as the authserv-id. Furthermore, 1545 the sender authenticated herself/himself to the MTA via a method 1546 specified in [AUTH], and both [SPF] and [SENDERID] checks were done 1547 and passed. The MUA could extract and relay this extra information 1548 if desired. 1550 Two "Authentication-Results" header fields are not required since the 1551 same host did all of the checking. The authenticating agent could 1552 have consolidated all the results into one header field. 1554 This example illustrates a scenario in which a remote user on a 1555 dialup connection (example.net) sends mail to a border MTA 1556 (example.com) using SMTP authentication to prove identity. The 1557 dialup provider has been explicitly authorized to relay mail as 1558 "example.com" resulting in passes by the SPF and SenderID checks. 1560 C.5. Service Provided, Several Authentications Done, Different MTAs 1562 A message that was relayed inbound by two different MTAs that conform 1563 to this specification and applied multiple message authentication 1564 checks: 1566 Authentication-Results: example.com; 1567 sender-id=fail header.from=example.com; 1568 dkim=pass (good signature) header.d=example.com 1569 Received: from mail-router.example.com 1570 (mail-router.example.com [192.0.2.1]) 1571 by auth-checker.example.com (8.11.6/8.11.6) 1572 with ESMTP id i7PK0sH7021929; 1573 Fri, Feb 15 2002 17:19:22 -0800 1574 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1575 t=1188964191; c=simple/simple; h=From:Date:To:Subject: 1576 Message-Id:Authentication-Results; 1577 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1578 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1579 Authentication-Results: example.com; 1580 auth=pass (cram-md5) smtp.auth=sender@example.com; 1581 spf=fail smtp.mailfrom=example.com 1582 Received: from dialup-1-2-3-4.example.net 1583 (dialup-1-2-3-4.example.net [192.0.2.200]) 1584 by mail-router.example.com (8.11.6/8.11.6) 1585 with ESMTP id g1G0r1kA003489; 1586 Fri, Feb 15 2002 17:19:07 -0800 1587 From: sender@example.com 1588 Date: Fri, Feb 15 2002 16:54:30 -0800 1589 To: receiver@example.com 1590 Message-Id: <12345.abc@example.com> 1591 Subject: here's a sample 1593 Hello! Goodbye! 1595 Example 5: Headers reporting results from multiple MTAs 1597 The "Authentication-Results" header field is present, indicating 1598 conformance to this specification. Once again, the authserv-id used 1599 is the recipient's DNS domain name. The header field is present 1600 twice because two different MTAs in the chain of delivery did 1601 authentication tests. The first, "mail-router.example.com" reports 1602 that [AUTH] and [SPF] were both used, and [AUTH] passed but [SPF] 1603 failed. In the [AUTH] case, additional data is provided in the 1604 comment field, which the MUA can choose to render if desired. 1606 The second MTA, "auth-checker.example.com", reports that it did a 1607 [SENDERID] test (which failed) and a [DKIM] test (which passed). 1609 Again, additional data about one of the tests is provided as a 1610 comment, which the MUA may choose to render. Also noteworthy here is 1611 the fact that there is a DKIM signature added by example.com that 1612 assured the integrity of the lower Authentication-Results field. 1614 Since different hosts did the two sets of authentication checks, the 1615 header fields cannot be consolidated in this example. 1617 This example illustrates more typical transmission of mail into 1618 "example.com" from a user on a dialup connection "example.net". The 1619 user appears to be legitimate as he/she had a valid password allowing 1620 authentication at the border MTA using [AUTH]. The [SPF] and 1621 [SENDERID] tests failed since "example.com" has not granted 1622 "example.net" authority to relay mail on its behalf. However, the 1623 [DKIM] test passed because the sending user had a private key 1624 matching one of "example.com"'s published public keys and used it to 1625 sign the message. 1627 C.6. Service Provided, Multi-Tiered Authentication Done 1629 A message that had authentication done at various stages, one of 1630 which was outside the receiving ADMD: 1632 Authentication-Results: example.com; 1633 dkim=pass reason="good signature" 1634 header.i=@mail-router.example.net; 1635 dkim=fail reason="bad signature" 1636 header.i=@newyork.example.com 1637 Received: from mail-router.example.net 1638 (mail-router.example.net [192.0.2.250]) 1639 by chicago.example.com (8.11.6/8.11.6) 1640 for 1641 with ESMTP id i7PK0sH7021929; 1642 Fri, Feb 15 2002 17:19:22 -0800 1643 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1644 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1645 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1646 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1647 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1648 Authentication-Results: example.net; 1649 dkim=pass (good signature) header.i=@newyork.example.com 1650 Received: from smtp.newyork.example.com 1651 (smtp.newyork.example.com [192.0.2.220]) 1652 by mail-router.example.net (8.11.6/8.11.6) 1653 with ESMTP id g1G0r1kA003489; 1654 Fri, Feb 15 2002 17:19:07 -0800 1655 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; 1656 d=newyork.example.com; 1657 t=1188964191; c=simple/simple; 1658 h=From:Date:To:Message-Id:Subject; 1659 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1660 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1661 From: sender@newyork.example.com 1662 Date: Fri, Feb 15 2002 16:54:30 -0800 1663 To: meetings@example.net 1664 Message-Id: <12345.abc@newyork.example.com> 1665 Subject: here's a sample 1667 Example 6: Headers reporting results from multiple MTAs in different 1668 ADMDs 1670 In this example we see multi-tiered authentication with an extended 1671 trust boundary. 1673 The message was sent from someone at example.com's New York office 1674 (newyork.example.com) to a mailing list managed at an intermediary. 1676 The message was signed at the origin using [DKIM]. 1678 The message was sent to a mailing list service provider called 1679 example.net, which is used by example.com. There, 1680 meetings@example.net is expanded to a long list of recipients, one of 1681 that is at the Chicago office. In this example, we will assume that 1682 the trust boundary for chicago.example.com includes the mailing list 1683 server at example.net. 1685 The mailing list server there first authenticated the message and 1686 affixed an Authentication-Results header field indicating such using 1687 its DNS domain name for the authserv-id. It then altered the message 1688 by affixing some footer text to the body, including some 1689 administrivia such as unsubscription instructions. Finally, the 1690 mailing list server affixes a second [DKIM] signature and begins 1691 distribution of the message. 1693 The border MTA for chicago.example.com explicitly trusts results from 1694 mail-router.example.net so that header field is not removed. It 1695 performs evaluation of both signatures and determines that the first 1696 (most recent) is a "pass" but, because of the aforementioned 1697 modifications, the second is a "fail". However, the first signature 1698 included the Authentication-Results header added at mail- 1699 router.example.net that validated the second signature. Thus, 1700 indirectly, it can be determined that the authentications claimed by 1701 both signatures are indeed valid. 1703 Note that two styles of presenting meta-data about the result are in 1704 use here. In one case, the "reason=" clause is present which is 1705 intended for easy extraction by parsers; in the other case, the CFWS 1706 production of the ABNF is used to include such data as a header field 1707 comment. The latter can be harder for parsers to extract given the 1708 varied supported syntaxes of mail header fields. 1710 C.7. Comment-Heavy Example 1712 The formal syntax permits comments within the content in a number of 1713 places. For the sake of illustration, this example is also legal: 1715 Authentication-Results: foo.example.net (foo) / (bar) 1 (baz); 1716 dkim (Because I like it) / 1 (One yay) = (wait for it) fail 1717 policy (A dot can go here) . (like that) expired 1718 (this surprised me) = (as I wasn't expecting it) 1362471462 1720 Example 7: A very comment-heavy but perfectly legal example 1722 Appendix D. Operational Considerations about Message Authentication 1724 This protocol is predicated on the idea that authentication (and 1725 presumably in the future, reputation) work is typically done by 1726 border MTAs rather than MUAs or intermediate MTAs; the latter merely 1727 make use of the results determined by the former. Certainly this is 1728 not mandatory for participation in electronic mail or message 1729 authentication, but this protocol and its deployment to date are 1730 based on that model. The assumption satisfies several common ADMD 1731 requirements: 1733 1. Service operators prefer to resolve the handling of problem 1734 messages as close to the border of the ADMD as possible. This 1735 enables, for example, rejections of messages at the SMTP level 1736 rather than generating a DSN internally. Thus, doing any of the 1737 authentication or reputation work exclusively at the MUA or 1738 intermediate MTA renders this desire unattainable. 1740 2. Border MTAs are more likely to have direct access to external 1741 sources of authentication or reputation information since modern 1742 MUAs are more likely to be heavily firewalled. Thus, some MUAs 1743 might not even be able to complete the task of performing 1744 authentication or reputation evaluations without complex proxy 1745 configurations or similar burdens. 1747 3. MUAs rely upon the upstream MTAs within their trust boundaries to 1748 make correct (as much as that is possible) evaluations about the 1749 message's envelope, header and content. Thus, MUAs don't need to 1750 know how to do the work that upstream MTAs do; they only need the 1751 results of that work. 1753 4. Evaluations about the quality of a message, from simple token 1754 matching (e.g., a list of preferred DNS domains) to cryptanalysis 1755 (e.g., public/private key work), are at least a little bit 1756 expensive and thus need to be minimized. To that end, performing 1757 those tests at the border MTA is far preferred to doing that work 1758 at each MUA that handles a message. If an ADMD's environment 1759 adheres to common messaging protocols, a reputation query or an 1760 authentication check performed by a border MTA would return the 1761 same result as the same query performed by an MUA. By contrast, 1762 in an environment where the MUA does the work, a message arriving 1763 for multiple recipients would thus cause authentication or 1764 reputation evaluation to be done more than once for the same 1765 message (i.e., at each MUA) causing needless amplification of 1766 resource use and creating a possible denial-of-service attack 1767 vector. 1769 5. Minimizing change is good. As new authentication and reputation 1770 methods emerge, the list of methods supported by this header 1771 field would presumably be extended. If MUAs simply consume the 1772 contents of this header field rather than actually attempting to 1773 do authentication and/or reputation work, then MUAs only need to 1774 learn to parse this header field once; emergence of new methods 1775 requires only a configuration change at the MUAs and software 1776 changes at the MTAs (which are presumably fewer in number). When 1777 choosing to implement these functions in MTAs vs MUAs, the issues 1778 of individual flexibility, infrastructure inertia and scale of 1779 effort must be considered. It is typically easier to change a 1780 single MUA than an MTA because the modification affects fewer 1781 users and can be pursued with less care. However, changing many 1782 MUAs is more effort than changing a smaller number of MTAs. 1784 6. For decisions affecting message delivery and display, assessment 1785 based on authentication and reputation is best performed close to 1786 the time of message transit, as a message makes its journey 1787 toward a user's inbox, not afterwards. DKIM keys and IP address 1788 reputations, etc., can change over time or even become invalid, 1789 and users can take a long time to read a message once delivered. 1790 The value of this work thus degrades, perhaps quickly, once the 1791 delivery process has completed. This seriously diminishes the 1792 value of this work when done other than at MTAs. 1794 Many operational choices are possible within an ADMD, including the 1795 venue for performing authentication and/or reputation assessment. 1796 The current specification does not dictate any of those choices. 1797 Rather, it facilitates those cases in which information produced by 1798 one stage of analysis needs to be transported with the message to the 1799 next stage. 1801 Appendix E. Known Implementations 1803 [Note to IESG: This can be dropped prior to publication unless it's 1804 desirable to carry the information visibly in this way.] 1806 o Google Mail (Gmail) 1808 o Yahoo! Mail 1810 o Hotmail 1812 o Courier MTA (http://www.courier-mta.org) 1814 o sid-milter (http://sourceforge.net/projects/sid-milter) 1815 o OpenDKIM (http://www.opendkim.org) 1817 o OpenDMARC (http://www.trusteddomain.org/opendmarc.html) 1819 o An open source Python module 1820 (https://pypi.python.org/pypi/authres/0.402) 1822 Appendix F. Changes since RFC5451 1824 [Note to IESG: This can be dropped prior to publication unless it's 1825 desirable to carry the changes visibly in this way.] 1827 o Errata #2617 was addressed in RFC6577 and was incorporated here 1829 o Request Internet Standard status 1831 o Change IANA rules to Designated Expert from IETF Review 1833 o Update existing IANA registries from the old RFC to this one 1835 o Add references to ADSP, ATPS, VBR 1837 o Remove all the "X-" stuff, per BCP178 1839 o Adjust language to indicate that this header field was already 1840 defined, and we're just refreshing and revising 1842 o In a few places, RFC2119 language had been used in lowercase 1843 terms; fixed here 1845 o Errata #2818 addressed 1847 o Errata #3195 addressed 1849 o Some minor wordsmithing and removal of odd prose 1851 o ABNF: change "dot-atom" to "Keyword" since "dot-atom" allows "=", 1852 which leads to ambiguous productions 1854 o Call out the SMTP verb exceptions ("mailfrom" and "rcptto"); the 1855 previous RFC didn't do this, leading to interoperability problems 1857 o Rather then deleting suspect header fields, they could also be 1858 renamed to something harmless; there is at least one 1859 implementation of this 1861 o Update IANA method registry to include version numbers 1862 o Review "should" vs. SHOULD 1864 Author's Address 1866 Murray S. Kucherawy 1867 270 Upland Drive 1868 San Francisco, CA 94127 1869 US 1871 EMail: superuser@gmail.com