idnits 2.17.00 (12 Aug 2021) /tmp/idnits27168/draft-kucherawy-sender-auth-header-20.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 21, 2009) is 4861 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 425, but not defined == Missing Reference: 'TBD' is mentioned on line 1068, but not defined -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4870 (ref. 'DOMAINKEYS') (Obsoleted by RFC 4871) == Outdated reference: draft-crocker-email-arch has been published as RFC 5598 == Outdated reference: draft-ietf-dkim-ssp has been published as RFC 5617 -- 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: 0 errors (**), 0 flaws (~~), 5 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 Sendmail, Inc. 4 Intended status: Standards Track January 21, 2009 5 Expires: July 25, 2009 7 Message Header Field for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-header-20 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 25, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This memo defines a new header field for use with electronic mail 48 messages to indicate the results of message authentication efforts. 49 Any receiver-side software, such as mail filters or Mail User Agents 50 (MUAs), may use this message header field to relay that information 51 in a convenient way to users or to make sorting and filtering 52 decisions. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 5 60 1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 62 1.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 63 1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.5.3. E-Mail Architecture . . . . . . . . . . . . . . . . . 7 65 1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8 66 2. Definition and Format of the Header Field . . . . . . . . . . 9 67 2.1. General Description . . . . . . . . . . . . . . . . . . . 9 68 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 9 69 2.3. Authentication Identifier Field . . . . . . . . . . . . . 12 70 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 13 71 2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 13 72 2.4.2. DKIM ADSP Results . . . . . . . . . . . . . . . . . . 14 73 2.4.3. SPF and Sender-ID Results . . . . . . . . . . . . . . 14 74 2.4.4. iprev Results . . . . . . . . . . . . . . . . . . . . 16 75 2.4.5. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 16 76 2.4.6. Extension Result Codes . . . . . . . . . . . . . . . . 17 77 2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 17 78 2.5.1. Definition Of Initial Methods . . . . . . . . . . . . 17 79 2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 18 80 3. The 'iprev' Authentication Method . . . . . . . . . . . . . . 20 81 4. Adding The Header Field To A Message . . . . . . . . . . . . . 22 82 4.1. Header Field Position and Interpretation . . . . . . . . . 23 83 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 24 84 5. Removing The Header Field . . . . . . . . . . . . . . . . . . 25 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 86 6.1. The Authentication-Results Header Field . . . . . . . . . 26 87 6.2. Email Authentication Method Name Registry . . . . . . . . 26 88 6.3. Email Authentication Result Name Registry . . . . . . . . 27 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 90 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 30 91 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 31 92 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 32 93 7.4. Reverse IP Query Denial-Of-Service Attacks . . . . . . . . 32 94 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 32 95 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 32 96 7.7. Attacks Against Authentication Methods . . . . . . . . . . 32 97 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 33 98 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 33 99 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 33 100 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 33 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 102 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 103 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 104 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 105 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 38 106 Appendix C. Authentication-Results Examples . . . . . . . . . . . 39 107 C.1. Trivial case; header field not present . . . . . . . . . . 39 108 C.2. Nearly-trivial case; service provided, but no 109 authentication done . . . . . . . . . . . . . . . . . . . 40 110 C.3. Service provided, authentication done . . . . . . . . . . 40 111 C.4. Service provided, several authentications done, single 112 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 C.5. Service provided, several authentications done, 114 different MTAs . . . . . . . . . . . . . . . . . . . . . . 42 115 C.6. Service provided, multi-tiered authentication done . . . . 44 116 Appendix D. Operational Considerations About Message 117 Authentication . . . . . . . . . . . . . . . . . . . 46 118 Appendix E. Public Discussion, History and Support . . . . . . . 48 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50 121 1. Introduction 123 This memo defines a new header field for electronic mail messages 124 which presents the results of a message authentication effort in a 125 machine-readable format. The intent is to create a place to collect 126 such data when message authentication mechanisms are in use so that a 127 Mail User Agent (MUA) and downstream filters can make filtering 128 decisions and/or provide a recommendation to the user as to the 129 validity of the message's origin and possibly the integrity of its 130 content. 132 End users are not expected to be direct consumers of this header 133 field. This header field is intended for consumption by programs 134 which will then use or render such data in a human-usable form. 136 This memo defines both the format of this new header field and 137 discusses the implications of its presence or absence. However, it 138 does not discuss how the data contained in the header field should be 139 used (i.e. what filtering decisions are appropriate, or how an MUA 140 might render these results) as these are local policy and/or user 141 interface design questions which are not appropriate for this memo. 143 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 144 memo, [AUTH], [DKIM], [DOMAINKEYS], [I-D.DRAFT-IETF-DKIM-SSP], 145 [SENDERID] and [SPF] are published DNS domain-level e-mail 146 authentication methods in common use. This proposal is not intended 147 to be restricted to domain-based authentication, but this has proven 148 to be a good starting point for implementations. As various methods 149 emerge, it is necessary to prepare for their appearance and encourage 150 convergence in the area of interfacing verifiers to filters and MUAs. 152 Although [SPF] defined a header field called Received-SPF and 153 [DOMAINKEYS] one called DomainKey-Status for this purpose, those 154 header fields are specific to the conveyance of their respective 155 results only and thus are insufficient to satisfy the requirements 156 enumerated below. 158 1.1. Purpose 160 The header field defined in this memo is expected to serve several 161 purposes: 163 1. Convey the results of various message authentication checks being 164 applied by upstream filters and Mail Transfer agents (MTAs) to 165 MUAs and downstream filters within the same "trust domain", as 166 such agents may wish to render those results to end users or use 167 that data to apply more or less stringent content checks based on 168 authentication results; 170 2. Provide a common location within a message for this data; 172 3. Create an extensible framework for reporting new authentication 173 methods as they emerge. 175 In particular, the mere presence of this header field should not be 176 construed as meaning that its data is valid, but rather that it is 177 asserting validity based on one or more authentication schemes 178 somewhere upstream. For an MUA or downstream filter to treat the 179 assertions as actually valid, there must be an assessment of the 180 trust relationship between such agents and the validating MTA. 182 1.2. Trust Boundary 184 This document makes several references to the "trust boundary" of an 185 administrative management domain (ADMD). Given the diversity among 186 existing mail environments, a precise definition of this term isn't 187 possible. 189 Simply put, a transfer from the creator of the header field to the 190 consumer must occur within a context of trust that the creator's 191 information is correct. How this trust is obtained is outside the 192 scope of this document. It is entirely a local matter. 194 Thus, this document defines a "trust boundary" as the delineation 195 between "external" and "internal" entities; "external" here includes 196 all hosts which do not deliberately provide some kind of messaging 197 service for the receiving ADMD's users, and "internal" includes those 198 hosts which do. By this definition, the hosts within a "trust 199 boundary" may lie entirely within a receiving ADMD's direct control, 200 or they can include hosts managed by another ADMD (such as an ISP or 201 commercial filtering service) but which also provide services for the 202 former. 204 1.3. Processing Scope 206 This proposal is intended to address the needs of authenticating 207 messages or properties of messages during their actual transport. It 208 is not meant to address the security of messages that might be 209 encapsulated within other messages, such as a message/rfc822 [MIME] 210 part within a message. 212 1.4. Requirements 214 This memo establishes no new requirements on existing protocols or 215 servers. 217 In particular, this memo establishes no requirement on MTAs to reject 218 or filter arriving messages which do not pass authentication checks. 219 The data conveyed by the defined header field's contents are for the 220 information of MUAs and filters and should be used at their 221 discretion. 223 1.5. Definitions 225 This section defines various terms used throughout this document. 227 1.5.1. General 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [KEYWORDS]. 233 1.5.2. Security 235 [SECURITY] discusses authentication and authorization and the 236 conflation of the two concepts. The use of those terms within the 237 context of recent message security work has given rise to slightly 238 different definitions, and this document reflects those current 239 usages, as follows: 241 o "Authorization" is the establishment of permission to use a 242 resource or represent an identity. In this context, authorization 243 indicates that a message from a particular ADMD arrived via a 244 route the ADMD has explicitly approved. 246 o "Authentication" is the assertion of validity of a piece of data 247 about a message (such as the sender's identity) or the message in 248 its entirety. 250 As examples: [SPF] and [SENDERID] are authorization mechanisms in 251 that they express a result that shows whether or not the ADMD that 252 apparently sent the message has explicitly authorized the connecting 253 [SMTP] client to relay messages on its behalf but do not actually 254 validate any property of the message itself. By contrast, [DKIM] is 255 agnostic as to the routing of a message but uses cryptographic 256 signatures to authenticate agents claiming responsibility for the 257 message (which implies authorization) and ensure it was not modified 258 in transit. Since the signatures are not tied to SMTP conections, 259 they can be added by either the ADMD of origin, intermediate ADMDs 260 (such as a mailing list server), or both. 262 Rather than create a separate header field for each class of 263 solution, this proposal groups them both into a single header field. 265 1.5.3. E-Mail Architecture 267 o A "border MTA" is an MTA which acts as a gateway between the 268 general Internet and the users within an organizational boundary. 269 (See also Section 1.2.) 271 o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which 272 actually enacts delivery of a message to a user's inbox or other 273 final delivery. 275 o An "intermediate MTA" is an MTA which handles messages after a 276 border MTAs and before a delivery MTA. 278 The following diagram illustrates the flow of mail among these 279 defined components: 281 +-----+ +-----+ +------------+ 282 | MUA |-->| MSA |-->| Border MTA | 283 +-----+ +-----+ +------------+ 284 | 285 | 286 V 287 +----------+ 288 | Internet | 289 +----------+ 290 | 291 | 292 V 293 +-----+ +-----+ +------------------+ +------------+ 294 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 295 +-----+ +-----+ +------------------+ +------------+ 297 Generally it is assumed that the work of applying message 298 authentication schemes takes place at a border MTA or a delivery MTA. 299 This specification is written with that assumption in mind. However, 300 there are some sites at which the entire mail infrastructure consists 301 of a single host. In such cases, such terms as "border MTA" and 302 "delivery MTA" may well apply to the same machine or even the very 303 same agent. It is also possible that some message authentication 304 tests could take place on an intermediate MTA. Although this 305 document doesn't specifically describe such cases, they are not meant 306 to be excluded from this specification. 308 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on general 309 e-mail system architecture, and Appendix D of this memo for 310 discussion about the common aspects of e-mail authentication in 311 current environments. 313 1.6. Trust Environment 315 This new header field permits one or more message validation 316 mechanisms to communicate its output to one or more separate 317 assessment mechanisms. These mechanisms operate within a unified 318 trust boundary that defines an Administrative Management Domain 319 (ADMD). An ADMD contains one or more entities that perform 320 validation and generate the header field, and one or more that 321 consume it for some type of assessment. The field contains no 322 integrity or validation mechanism of its own, so its presence must be 323 trusted implicitly. Hence, use of the header field depends upon 324 ensuring that mail entering the ADMD has instances of the header 325 field claiming to be valid within its boundaries removed, so that 326 occurrences of such header fields can be used safely by consumers. 328 The "authserv-id" token defined in Section 2.2 can be used to label 329 an entire ADMD or a specific validation engine within an ADMD. 330 Although the labeling scheme is left as an operational choice, some 331 guidance for selecting a token is provided within this proposal. 333 2. Definition and Format of the Header Field 335 This section gives a general overview of the format of the header 336 field being defined, and then provides more formal specification. 338 2.1. General Description 340 The new header field being defined here is called "Authentication- 341 Results". It is a Structured Header Field as defined in [MAIL] and 342 thus all of the related definitions in that document apply. 344 This new header field SHOULD be added at the top of the message as it 345 transits MTAs which do authentication checks so some idea of how far 346 away the checks were done can be inferred. It therefore should be 347 treated as a Trace Field as defined in [MAIL] and thus all of the 348 related definitions in that document apply. 350 The value of the header field (after removing [MAIL] comments) 351 consists of an authentication identifier, an optional version, and 352 then a series of "method=result" statements indicating which 353 authentication method(s) were applied and their respective results, 354 and then, for each applied method, an optional "reason" string plus 355 optional "property=value" statements indicating which message 356 properties were evaluated to reach that conclusion. 358 The header field MAY appear more than once in a single message, or 359 more than one result MAY be represented in a single header field, or 360 a combination of these MAY be applied. 362 2.2. Formal Definition 364 Formally, the header field is specified as follows using [ABNF]: 366 authres-header = "Authentication-Results:" [CFWS] authserv-id 367 [ CFWS version ] 368 ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF 369 ; the special case of "none" is used to indicate that no 370 ; message authentication is performed 372 authserv-id = dot-atom-text 373 ; see below for a description of this element; 374 ; "dot-atom-text" is defined in section 3.2.3 of [MAIL] 376 version = 1*DIGIT [CFWS] 377 ; indicates which version of this specification is in use; 378 ; this specification is version "1"; the absence of a 379 ; version implies this version of the specification 381 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 382 *( CFWS propspec ) 384 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 385 ; indicates which authentication method was evaluated 387 reasonspec = "reason" [CFWS] "=" [CFWS] value 388 ; a free-form comment on the reason the given result 389 ; was returned 391 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 392 ; an indication of which properties of the message 393 ; were evaluated by the authentication scheme being 394 ; applied to yield the reported result and would be 395 ; useful to reveal to end users as authenticated 397 method = token [ [CFWS] "/" [CFWS] version ] 398 ; a method indicates which method's result is 399 ; represented by "result", and is one of the methods 400 ; explicitly defined as valid in this document 401 ; or is an extension method as defined below 403 result = token 404 ; indicates the results of the attempt to authenticate 405 ; the message; see below for details 407 ptype = "smtp" / "header" / "body" / "policy" 408 ; indicates whether the property being evaluated was 409 ; a parameter to an [SMTP] command, or was a value taken 410 ; from a message header field, or was some property of 411 ; the message body, or some other property evaluated by 412 ; the receiving MTA 414 property = token 415 ; if "ptype" is "smtp", this indicates which [SMTP] 416 ; command provided the value which was evaluated by the 417 ; authentication scheme being applied; if "ptype" is 418 ; "header", this indicates from which header field the 419 ; value being evaluated was extracted; if "ptype" is 420 ; "body", this indicates the offset into the body at which 421 ; content of interest was detected; if "ptype" is "policy" 422 ; then this indicates the name of the policy which caused 423 ; this header field to be added (see below) 425 pvalue = [CFWS] ( token / addr-spec ) [CFWS] 426 ; the value extracted from the message property defined 427 ; by the "ptype.property" construction; if the value 428 ; identifies an address, then it is an "addr-spec" 430 The "token" and "value" are as defined in section 5.1 of [MIME]. 432 The "addr-spec" is as defined in section 3.4.1 of [MAIL]. 434 The "token" used in a "result" above is further constrained by the 435 necessity of being enumerated in Section 2.4 or an amendment to it. 437 See Section 2.3 for a description of the "authserv-id" element. 439 The list of commands eligible for use with the "smtp" ptype can be 440 found in [SMTP] and subsequent amendments. 442 "CFWS" is as defined in section 3.2.2 of [MAIL]. 444 The "propspec" may be omitted if for example the method was unable to 445 extract any properties to do its evaluation yet has a result to 446 report. 448 The "ptype" and "property" values used by each authentication method 449 should be defined in the specification for that method (or its 450 amendments). 452 The "ptype" and "property" are case-insensitive. 454 A "ptype" value of "policy" indicates a policy decision about the 455 message not specific to a property of the message that could be 456 extracted. For example, if a method would normally report a 457 "ptype.property" of "header.From" and no From: header field was 458 present, the method can use "policy" to indicate that no conclusion 459 about the authenticity of the message could be reached. 461 2.3. Authentication Identifier Field 463 Every Authentication-Results header field has an authentication 464 identifier field ("authserv-id" above). This is similar in syntax to 465 a fully-qualified domain name. 467 The authentication identifier field provides a unique identifier that 468 refers to the authenticating service within a given ADMD. The 469 uniqueness of the identifier MUST be guaranteed by the ADMD that 470 generates it and must pertain to exactly that one ADMD. This 471 identifier is intended to be machine-readable and not necessarily 472 meaningful to users. MUAs or downstream filters SHOULD use this 473 identifier to determine whether or not the data contained in an 474 Authentication-Results header field should be used. 476 For simplicity and scalability, the authentication identifier SHOULD 477 be a common token used throughout the ADMD, such as the DNS domain 478 name used by or within that ADMD. 480 For tracing and debugging purposes, the authentication identifier MAY 481 instead be the hostname of the MTA performing the authentication 482 check whose result is being reported. This is also useful for 483 another purpose, as described in Section 4. Moreover, some 484 implementations have considered appending a delimiter such as "/" and 485 following it with useful transport tracing data such as the [SMTP] 486 queue ID or a timestamp. 488 It should be noted, however, that using a local, relative identifier 489 like a single hostname, rather than a hierarchical and globally 490 unique ADMD identifier like a DNS domain name, makes configuration 491 more difficult for large sites. The hierarchical identifier permits 492 aggregating related, trusted systems together under a single, parent 493 identifier, which in turn permits assessing the trust relationship 494 with a single reference. The alternative is a flat namespace 495 requiring individually listing each trusted system. Since consumers 496 must use the identifier to determine whether to use the contents of 497 the header field: 499 o Changes to the identifier impose a large, centralized 500 administrative burden. 502 o Ongoing administrative changes require constantly updating this 503 centralized table, making it difficult to ensure that an MUA or 504 downstream filter will have access to accurate information for 505 assessing the usability of the header field's content. In 506 particular, consumers of the header field will need to know not 507 only the current identifier(s) in use, but previous ones as well 508 to account for delivery latency or later re-assessment of the 509 header field's contents. 511 Examples of valid authentication identifiers are "example.com", 512 "mail.example.org", "ms1.newyork.example.com" and "example-auth". 514 2.4. Result Values 516 Each individual authentication method returns one of a set of 517 specific result values. The subsections below define these results 518 for the authentication methods specifically supported by this memo, 519 and verifiers SHOULD use these values as described below. New 520 methods not specified in this document intended to be supported by 521 the header field defined in this memo MUST include a similar result 522 table either in its defining memo or in a supplementary one. 524 2.4.1. DKIM and DomainKeys Results 526 The result values used by [DKIM] and [DOMAINKEYS] are as follows: 528 none: The message was not signed. 530 pass: The message was signed, the signature(s) is (were) acceptable 531 to the verifier, and the signature(s) passed verification tests. 533 fail: The message was signed and the signature(s) is (were) 534 acceptable to the verifier, but it (they) failed the verification 535 test(s). 537 policy: The message was signed but the signature(s) is (were) not 538 acceptable to the verifier. 540 neutral: The message was signed but the signature(s) contained 541 syntax errors or were not otherwise able to be processed. This 542 result SHOULD also be used for other failures not covered 543 elsewhere in this list. 545 temperror: The message could not be verified due to some error which 546 is likely transient in nature, such as a temporary inability to 547 retrieve a public key. A later attempt may produce a final 548 result. 550 permerror: The message could not be verified due to some error which 551 is unrecoverable, such as a required header field being absent. A 552 later attempt is unlikely to produce a final result. 554 A signature is "acceptable to the verifier" if it passes local policy 555 checks (or there are no specific local policy checks). For example, 556 a verifier might require that the signature(s) on the message be 557 added using the DNS domain present in the From: header field of the 558 message, thus making third-party signatures unacceptable. 560 [DKIM] advises that if a message fails verification, it should be 561 treated as an unsigned message. A report of "fail" here permits the 562 receiver of the report to decide how to handle the failure. A report 563 of "neutral" or "none" pre-empts that choice, ensuring the message 564 will be treated as if it had not been signed. 566 2.4.2. DKIM ADSP Results 568 The result values are used by [I-D.DRAFT-IETF-DKIM-SSP] as follows: 570 none: No DKIM author domain signing practises (ADSP) record was 571 published. 573 pass: This message had an author signature which validated. (An 574 ADSP check is not strictly required to be performed for this 575 result, since a valid author domain signature satisfies all 576 possible ADSP policies.) 578 unknown: No valid author signature was found on the message and the 579 published ADSP was "unknown". 581 fail: No valid author signature was found on the message and the 582 published ASDP record indicated an "all" policy. 584 discard: No valid author signature was found on the message and the 585 published ADSP record indicated a "discardable" policy. 587 nxdomain: Evaluating the ADSP for the author's DNS domain indicated 588 that the author's DNS domain does not exist. 590 temperror: A DKIM policy could not be retrieved due to some error 591 which is likely transient in nature, such as a temporary DNS 592 error. A later attempt may produce a final result. 594 permerror: A DKIM policy could not be retrieved due to some error 595 which is likely not transient in nature, such as a permanent DNS 596 error. A later attempt is unlikely to produce a final result. 598 2.4.3. SPF and Sender-ID Results 600 The result values are used by [SPF] and [SENDERID] as follows: 602 none: No policy records were published at the sender's DNS domain. 604 neutral: The sender's ADMD has asserted that it cannot or does not 605 want to assert whether or not the sending IP address is authorized 606 to send mail using the sender's DNS domain. 608 pass: The client is authorized by the sender's ADMD to inject or 609 relay mail on behalf of the sender's DNS domain. 611 policy: The client is authorized to inject or relay mail on behalf 612 of the sender's DNS domain according to the authentication 613 method's algorithm, but local policy dictates that the result is 614 unacceptable. 616 hardfail: This client is explicitly not authorized to inject or 617 relay mail using the sender's DNS domain. 619 softfail: The sender's ADMD believes the client was not authorized 620 to inject or relay mail using the sender's DNS domain, but is 621 unwilling to make a strong assertion to that effect. 623 temperror: The message could not be verified due to some error which 624 is likely transient in nature, such as a temporary inability to 625 retrieve a policy record from DNS. A later attempt may produce a 626 final result. 628 permerror: The message could not be verified due to some error which 629 is unrecoverable, such as a required header field being absent or 630 a syntax error in a retrieved DNS TXT record. A later attempt is 631 unlikely to produce a final result. 633 The distinction between and interpretation of "none" and "neutral" 634 under these methods is discussed further in [SPF]. 636 The "policy" result would be returned if, for example, [SPF] returned 637 as "pass" result, but a local policy check matches the sending DNS 638 domain to one found in an explicit list of unacceptable DNS domains 639 (e.g. spammers). 641 If the retrieved sender policies used to evaluate [SPF] and 642 [SENDERID] do not contain explicit provisions for authenticating the 643 local-part (see section 3.4.1 of [MAIL]) of an address, the "pvalue" 644 reported along with results for these mechanisms SHOULD NOT include 645 the local-part. 647 2.4.4. iprev Results 649 The result values are used by the "iprev" method, defined in 650 Section 3, are as follows: 652 pass: The DNS evaluation succeeded, i.e. the "reverse" and "forward" 653 lookup results were returned and were in agreement. 655 fail: The DNS evaluation failed. In particular, the "reverse" and 656 "forward" lookups each produced results but they were not in 657 agreement, or the "forward" query completed but produced no 658 result, e.g. a DNS RCODE of 3, commonly known as NXDOMAIN, or an 659 RCODE of 0 (NOERROR, in a reply containing no answers), was 660 returned. 662 temperror: The DNS evaluation could not be completed due to some 663 error which is likely transient in nature, such as a temporary DNS 664 error, e.g. a DNS RCODE of 2, commonly known as SERVFAIL, or other 665 error condition resulted. A later attempt may produce a final 666 result. 668 permerror: The DNS evaluation could not be completed because no PTR 669 data are published for the connecting IP address, e.g. a DNS RCODE 670 of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR, in a 671 reply containing no answers), was returned. This prevented 672 completion of the evaluation. 674 There is no "none" for this method since any TCP connection 675 delivering e-mail has an IP address associated with it, so some kind 676 of evaluation will always be possible. 678 For discussion of the format of DNS replies, see [DNS]. 680 2.4.5. SMTP AUTH Results 682 The result values are used by the [AUTH] method are as follows: 684 none: SMTP authentication was not attempted. 686 pass: The SMTP client had authenticated to the server reporting the 687 result using the protocol described in [AUTH]. 689 fail: The SMTP client had attempted to authenticate to the server 690 using the protocol described in [AUTH] but was not successful, yet 691 continued to send the message about which a result is being 692 reported. 694 temperror: The SMTP client attempted to authenticate using the 695 protocol described in [AUTH] but was not able to complete the 696 attempt due to some error which is likely transient in nature, 697 such as a temporary LDAP lookup error. A later attempt may 698 produce a final result. 700 permerror: The SMTP client attempted to authenticate using the 701 protocol described in [AUTH] but was not able to complete the 702 attempt due to some error which is likely not transient in nature, 703 such as a permanent LDAP lookup error. A later attempt is not 704 likely produce a final result. 706 Note that an agent making use of the data provided by this header 707 field SHOULD consider "fail" and "temperror" to be the synonymous in 708 terms of message authentication, i.e. the client did not 709 authenticate. 711 2.4.6. Extension Result Codes 713 Additional result codes (extension results) might be defined in the 714 future by later revisions or extensions to this specification. 715 Extension results beginning with "x-" will never be defined as 716 standard fields; such names are reserved for experimental use. 717 Result codes not beginning with "x-" MUST be registered with the 718 Internet Assigned Numbers Authority (IANA) and published in an RFC. 719 See Section 6 for further details. 721 Implementations reporting new result codes MUST use the "x-" prefix 722 until such time as the new method is registered by IANA. 724 Extension results MUST only be used within ADMDs that have explicitly 725 consented to use them. These results and the parameters associated 726 with them are not documented in RFCs. Therefore, they are subject to 727 change at any time and not suitable for production use. Any MTA, MUA 728 or downstream filter intended for production use SHOULD ignore or 729 delete any Authentication-Results header field that includes an 730 extension result. 732 2.5. Authentication Methods 734 This section defines the supported authentication methods and 735 discusses the proper means for applying experimental and other 736 extension methods. 738 2.5.1. Definition Of Initial Methods 740 As they are currently existing specifications for message 741 authentication, it is appropriate to define an authentication method 742 identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and 743 [SPF]. Therefore, the authentication method identifiers "auth", 744 "dkim", "domainkeys", "senderid" and "spf" respectively are hereby 745 defined for MTAs applying those specifications for e-mail message 746 authentication. 748 Furthermore, method "iprev" is defined in Section 3. 750 Finally, as its publication is imminent, this document also defines 751 "dkim-adsp" per [I-D.DRAFT-IETF-DKIM-SSP]. 753 See Section 6 for details. 755 2.5.2. Extension Methods 757 Additional authentication method identifiers (extension methods) may 758 be defined in the future by later revisions or extensions to this 759 specification. Extension methods beginning with "x-" will never be 760 defined as standard fields; such names are reserved for experimental 761 use. Method identifiers not beginning with "x-" MUST be registered 762 with the Internet Assigned Numbers Authority (IANA) and published in 763 an RFC. See Section 6 for further details. 765 Extension methods may be defined for the following reasons: 767 1. To allow additional information from new authentication systems 768 to be communicated to MUAs or downstream filters. The names of 769 such identifiers should reflect the name of the method being 770 defined, but should not be needlessly long. 772 2. To allow the creation of "sub-identifiers" which indicate 773 different levels of authentication and differentiate between 774 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 776 Implementations of new methods MUST use the "x-" prefix until such 777 time as the new method is registered by IANA. 779 Authentication method implementors are encouraged to provide adequate 780 information, via [MAIL] comments if necessary, to allow an MUA 781 developer to understand or relay ancilliary details of authentication 782 results. For example, if it might be of interest to relay what data 783 was used to perform an evaluation, such information could be relayed 784 as a comment in the header field, such as: 786 Authentication-Results: example.com; 787 foo=pass bar.baz=blob (2 of 3 tests OK) 789 Experimental method identifiers MUST only be used within ADMDs that 790 have explicitly consented to use them. These method identifiers and 791 the parameters associated with them are not documented in RFCs. 792 Therefore, they are subject to change at any time and not suitable 793 for production use. Any MTA, MUA or downstream filter intended for 794 production use SHOULD ignore or delete any Authentication-Results 795 header field that includes an experimental method identifier. 797 3. The 'iprev' Authentication Method 799 This section defines an additional authentication method called 800 "iprev". 802 In general, "iprev" is an attempt to verify that a client appears to 803 be valid based on some DNS queries. Upon receiving a session 804 initiation of some kind from a client, the IP address of the client 805 peer is queried for matching names (i.e. a number-to-name 806 translation, also known as a "reverse lookup" or a "PTR" record 807 query). Once that result is acquired, a lookup of each of the names 808 (i.e. a name-to-number translation, or an "A" or "AAAA" record query) 809 thus retrieved is done. The response to this second check should 810 result in at least one mapping back to the client's IP address. 812 More algorithmically: If the client peer's IP address is I, the list 813 of names to which I maps (after a "PTR" query) is the set N, and the 814 union of IP addresses to which each member of N maps (after 815 corresponding "A" and "AAAA" queries) is L, then this test is 816 successful if I is an element of L. 818 The response to a PTR query could contain multiple names. To prevent 819 heavy DNS loads, agents performing these queries MUST be implemented 820 such that the number of names evaluated by generation of 821 corresponding A or AAAA queries is finite, though it MAY be 822 configurable by an administrator. As an example, Section 5.5 of 823 [SPF] chose a limit of 10 for its implementation of this algorithm. 825 [DNS-IP6] discusses the query formats for for the IPv6 case. 827 A successful test using this algorithm constitutes a result of "pass" 828 since the ADMD in which the client's PTR claims it belongs has 829 confirmed that claim by including corresponding data in its DNS 830 domain. A failure to match constitutes a "fail". There is no case 831 in which a "neutral" result can be returned. The remaining 832 "temperror" and "permerror" cases refer respectively to temporary and 833 permanent DNS query errors. 835 There is some contention regarding the wisdom and reliability of this 836 test. For example, in some regions it can be difficult for this test 837 ever to pass because the practise of arranging to match the forward 838 and reverse DNS is infrequently observed. Therefore, the actual 839 implementation details of how a verifier performs an "iprev" test are 840 not specified here. The verifier MAY report a successful or failed 841 "iprev" test at its discretion having done some kind of check of the 842 validity of the connection's identity using DNS. It is incumbent 843 upon an agent making use of the reported "iprev" result to understand 844 what exactly that particular verifier is attempting to report. 846 Extensive discussion of reverse DNS mapping and its implications can 847 be found in [I-D.DRAFT-IETF-DNSOP-REVERSE]. In particular, it 848 recommends that applications avoid using this test as a means of 849 authentication or security. Its presence in this memo is not an 850 endorsement, but is merely acknowledgement that the method remains 851 common and provides the means to relay the results of that test. 853 4. Adding The Header Field To A Message 855 This specification makes no attempt to evaluate the relative 856 strengths of various message authentication methods that may become 857 available. As such, the order of the presented authentication 858 methods and results MUST NOT be used either to imply or infer the 859 importance or strength of any given method over another. Instead, 860 the MUA or downstream filter consuming this header field must 861 interpret the result of each method based on its own knowledge of 862 what that method evaluates. 864 Each "method" MUST refer to an authentication method declared in the 865 IANA registry, or an extension method as defined in Section 2.5.2, 866 and each "result" MUST refer to a result code declared in the IANA 867 registry, or an extension result code as defined in Section 2.4.6. 868 See Section 6 for further information about the registered methods 869 and result codes. 871 An MTA compliant with this specification MUST add this header field 872 (after performing one or more message authentication tests) to 873 indicate which MTA or ADMD performed the test, which test got applied 874 and what the result was. If an MTA applies more than one such test, 875 it MUST add this header field either once per test, or once 876 indicating all of the results. An MTA MUST NOT add a result to an 877 existing header field. 879 An MTA MAY add this header field containing only the authentication 880 identifier portion to indicate explicitly that no message 881 authentication schemes were applied prior to delivery of this 882 message. 884 An MTA adding this header field must take steps to identify it as 885 legitimate to the MUAs or downstream filters that will ultimately 886 consume its content. One required process to do so is described in 887 Section 5. Further measures may be required in some environments. 888 Some possible solutions are enumerated in Section 7.1. This memo 889 does not mandate any specific solution to this issue as each 890 environment has its own facilities and limitations. 892 For MTAs that add this header field, adding header fields in order 893 (at the top) per [MAIL] section 3.6 is particularly important. 894 Moreover, this header field SHOULD be inserted above any other trace 895 header fields such MTAs might prepend. This allows easy detection of 896 header fields that can be trusted. 898 End users making direct use of this header field may inadvertently 899 trust information that has not been properly vetted. If, for 900 example, a basic [SPF] result were to be relayed which claims an 901 authenticated addr-spec, the local-part of that addr-spec has 902 actually not been authenticated. Thus, an MTA adding this header 903 field SHOULD NOT include any data which has not been authenticated by 904 the method(s) being applied. Moreover, MUAs SHOULD NOT render to 905 users such information if it is presented by a method known not to 906 authenticate it. 908 4.1. Header Field Position and Interpretation 910 In order to ensure non-ambiguous results and avoid the impact of 911 false header fields, MUAs and downstream filters SHOULD NOT interpret 912 this header field unless specifically instructed to do so by the user 913 or administrator. That is, this interpretation should not be "on by 914 default". Naturally then, users or administrators should not 915 activate such a feature unless they are certain the header field will 916 be added by the border MTA that accepts the mail that is ultimately 917 read by the MUA, and instances of the header field appearing to be 918 from within the ADMD but actually added by foreign MTAs will be 919 removed before delivery. 921 Furthermore, MUAs and downstream filters SHOULD NOT interpret this 922 header field unless the authentication identifier it bears appears to 923 be one used within its own ADMD as configured by the user or 924 administrator. 926 MUAs and downstream filters MUST ignore any result reported using a 927 "result" not specified in the result code registry, or a "ptype" not 928 listed in the corresponding registry for such values as defined in 929 Section 6. Moreover, such agents MUST ignore a result indicated for 930 any "method" they do not specifically support. 932 An MUA SHOULD NOT reveal these results to end users unless the 933 results are accompanied by, at a minimum, some associated reputation 934 data about the authenticated origin identifiers within the message. 935 For example, an attacker could register examp1e.com (note the digit 936 "one") and send signed mail to intended victims; a verifier would 937 detect that the signature was valid and report a "pass" even though 938 it's clear the DNS domain name was intended to mislead. See 939 Section 7.2 for further discussion. 941 As stated in Section 2.1, this header field SHOULD be treated as 942 though it were a trace header field as defined in section 3.6.7 of 943 [MAIL], and hence MUST NOT be reordered and MUST be prepended to the 944 message, so that there is generally some indication upon delivery of 945 where in the chain of handling MTAs the message authentication was 946 done. 948 MUAs SHOULD ignore instances of this header field discovered within 949 message/rfc822 [MIME] attachments. 951 Further discussion of this can be found in Section 7 below. 953 4.2. Local Policy Enforcement 955 If a site's local policy is to consider a non-recoverable failure 956 result (e.g. "fail" for DKIM, "hardfail" for SPF or "discard" for 957 DKIM-ADSP) for any particular authentication method as justification 958 to reject the message completely, the border MTA SHOULD issue an 959 [SMTP] rejection response to the message rather than adding this 960 header field with the failure result and allowing it to proceed 961 toward delivery. This is more desirable than allowing the message to 962 reach an internal host's MTA or spam filter, thus possibly generating 963 a local rejection such as a [DSN] to a forged originator. 965 The same MAY also be done for local policy decisions overriding the 966 results of the authentication methods (e.g. the "policy" result codes 967 described in Section 2.4). 969 Such rejections at the SMTP protocol level are not possible if local 970 policy is enforced at the MUA and not the MTA. Unfortunately, this 971 may be a common scenario. 973 5. Removing The Header Field 975 For security reasons, any MTA conforming to this specification MUST 976 delete any discovered instance of this header field which claims to 977 have been added within its trust boundary and did not come from 978 another trusted MTA. For example, an MTA (border or otherwise) for 979 example.com receiving a message MUST delete any instance of this 980 header field bearing an authentication identifier indicating the 981 header field was added within example.com prior to adding its own 982 header fields. This may mean each MTA will have to be equipped with 983 a list of internal MTAs known to be compliant (and hence 984 trustworthy). 986 For simplicity and maximum security, a border MTA MAY remove all 987 instances of this header field on mail crossing into its trust 988 boundary. However, this may conflict with the desire to access 989 authentication results performed by trusted external service 990 providers. It may also invalidate signed messages whose signatures 991 cover external instances of this header field. A more robust border 992 MTA could allow a specific list of authenticating MTAs whose 993 information should be let in, removing all others. 995 As stated in Section 1.2, a formal definition of "trust boundary" is 996 deliberately not made here. It is entirely possible that a border 997 MTA for example.com might explicitly trust authentication results 998 asserted by upstream host example.net even though they exist in 999 completely disjoint administrative boundaries. In that case the 1000 border MTA MAY elect not to delete those results; moreover, the 1001 upstream host doing some authentication work could apply a signing 1002 technology such as [DKIM] on its own results to assure downstream 1003 hosts of their authenticity. An example of this is provided in 1004 Appendix C. 1006 Similarly, in the case of messages signed using [DKIM] or other 1007 message signing methods that sign header fields, this may invalidate 1008 one or more signatures on the message if they covered the header 1009 field to be removed at the time of signing. This behaviour can be 1010 desirable since there's little value in validating the signature on a 1011 message with forged headers. However, signing agents MAY therefore 1012 elect to omit these header fields from signing to avoid this 1013 situation. 1015 An MTA SHOULD remove any instance of this header field bearing a 1016 version (express or implied) that it does not support. However, an 1017 MTA MUST remove such a header if the [SMTP] connection relaying the 1018 message is not from a trusted internal MTA. 1020 6. IANA Considerations 1022 IANA is requested to register a new header field and to create two 1023 new tables as described below. 1025 6.1. The Authentication-Results Header Field 1027 Per [IANA-HEADERS], the "Authentication-Results" header field is 1028 added to the IANA Permanent Message Header Field Registry. The 1029 following is the registration template: 1031 Header field name: Authentication-Results 1032 Applicable protocol: mail ([MAIL]) 1033 Status: Standard 1034 Author/Change controller: IETF 1035 Specification document(s): [TBD] 1036 Related information: 1037 Requesting review of any proposed changes and additions to 1038 this field is recommended. 1040 6.2. Email Authentication Method Name Registry 1042 Names of message authentication methods supported by this 1043 specification must be registered with IANA, with the exception of 1044 experimental names as described in Section 2.5.2. 1046 New entries are assigned only for values that have been documented in 1047 a published RFC that has IETF Review, per [IANA-CONSIDERATIONS]. 1048 Each method must register a name, the specification that defines it, 1049 one or more "ptype" values appropriate for use with that method, 1050 which "property" value(s) should be reported by that method, and a 1051 description of the "value" to be used with each. 1053 The initial set of entries in this registry is as follows: 1055 +------------+----------+--------+----------------+--------------------+ 1056 | Method | Defined | ptype | property | value | 1057 +------------+----------+--------+----------------+--------------------+ 1058 | auth | RFC4954 | smtp | auth | AUTH parameter of | 1059 | | | | | the SMTP MAIL | 1060 | | | | | command | 1061 +------------+----------+--------+----------------+--------------------+ 1062 | dkim | RFC4871 | header | d | value of | 1063 | | | | | signature "d" tag | 1064 | | | +----------------+--------------------+ 1065 | | | | i | value of | 1066 | | | | | signature "i" tag | 1067 +------------+----------+--------+----------------+--------------------+ 1068 | dkim-adsp | [TBD] | header | from | value of From | 1069 | | | | | header field | 1070 | | | | | w/comments and | 1071 | | | | | local-part removed | 1072 +------------+----------+--------+----------------+--------------------+ 1073 | domainkeys | RFC4870 | header | d | value of | 1074 | | | | | signature "d" tag | 1075 | | | +----------------+--------------------+ 1076 | | | | from | value of From | 1077 | | | | | header field after | 1078 | | | | | removing comments | 1079 | | | | | and local-part if | 1080 | | | | | not authenticated | 1081 | | | +----------------+--------------------+ 1082 | | | | sender | value of Sender | 1083 | | | | | header field after | 1084 | | | | | removing comments | 1085 | | | | | and local-part if | 1086 | | | | | not authenticated | 1087 +------------+----------+--------+----------------+--------------------+ 1088 | iprev | this | policy | iprev | client IP address | 1089 | | document | | | | 1090 +------------+----------+--------+----------------+--------------------+ 1091 | senderid | RFC4406 | header | name of header | value of header | 1092 | | | | field used by | field used by PRA | 1093 | | | | PRA | after removing | 1094 | | | | | comments and parts | 1095 | | | | | not authenticated | 1096 +------------+----------+--------+----------------+--------------------+ 1097 | spf | RFC4408 | smtp | mailfrom | envelope sender | 1098 | | | | | after removing | 1099 | | | | | parts not | 1100 | | | | | authenticated | 1101 | | +--------+----------------+--------------------+ 1102 | | | smtp | helo | HELO/EHLO value | 1103 +------------+----------+--------+----------------+--------------------+ 1105 6.3. Email Authentication Result Name Registry 1107 Names of message authentication result codes supported by this 1108 specification must be registered with IANA, with the exception of 1109 experimental codes as described in Section 2.4.6. 1111 New entries are assigned only for result codes that have been 1112 documented in a published RFC that has IETF Review, per 1113 [IANA-CONSIDERATIONS]. Each code must register a name, the document 1114 which establishes the registration, the authentication method(s) 1115 which uses it, and either a definition of the semantics of its use or 1116 a reference to the place where those semantics are defined. 1118 The initial set of entries in this registry is as follows: 1120 +-----------+----------+----------------+------------------------------+ 1121 | Code | Defined | Auth Method(s) | Meaning | 1122 +-----------+----------+----------------+------------------------------+ 1123 | none | this | dkim | section 2.4.1 | 1124 | | document | domainkeys | | 1125 | | +----------------+------------------------------+ 1126 | | | dkim-adsp | section 2.4.2 | 1127 | | +----------------+------------------------------+ 1128 | | | spf | section 2.4.3 | 1129 | | | sender-id | | 1130 | | +----------------+------------------------------+ 1131 | | | auth | section 2.4.5 | 1132 +-----------+----------+----------------+------------------------------+ 1133 | pass | this | dkim | section 2.4.1 | 1134 | | document | domainkeys | | 1135 | | +----------------+------------------------------+ 1136 | | | dkim-adsp | section 2.4.2 | 1137 | | +----------------+------------------------------+ 1138 | | | spf | section 2.4.3 | 1139 | | | sender-id | | 1140 | | +----------------+------------------------------+ 1141 | | | iprev | section 2.4.4 | 1142 | | +----------------+------------------------------+ 1143 | | | auth | section 2.4.5 | 1144 +-----------+----------+----------------+------------------------------+ 1145 | fail | this | dkim | section 2.4.1 | 1146 | | document | domainkeys | | 1147 | | +----------------+------------------------------+ 1148 | | | dkim-adsp | section 2.4.2 | 1149 | | +----------------+------------------------------+ 1150 | | | auth | section 2.4.5 | 1151 +-----------+----------+----------------+------------------------------+ 1152 | policy | this | dkim | section 2.4.1 | 1153 | | document | domainkeys | | 1154 +-----------+----------+----------------+------------------------------+ 1155 | neutral | this | dkim | section 2.4.1 | 1156 | | document | domainkeys | | 1157 | | +----------------+------------------------------+ 1158 | | | spf | section 2.4.3 | 1159 | | | sender-id | | 1160 +-----------+----------+----------------+------------------------------+ 1161 | temperror | this | dkim | section 2.4.1 | 1162 | | document | domainkeys | | 1163 | | +----------------+------------------------------+ 1164 | | | dkim-adsp | section 2.4.2 | 1165 | | +----------------+------------------------------+ 1166 | | | spf | section 2.4.3 | 1167 | | | sender-id | | 1168 | | +----------------+------------------------------+ 1169 | | | iprev | section 2.4.4 | 1170 | | +----------------+------------------------------+ 1171 | | | auth | section 2.4.5 | 1172 +-----------+----------+----------------+------------------------------+ 1173 | permerror | this | dkim | section 2.4.1 | 1174 | | document | domainkeys | | 1175 | | +----------------+------------------------------+ 1176 | | | dkim-adsp | section 2.4.2 | 1177 | | +----------------+------------------------------+ 1178 | | | spf | section 2.4.3 | 1179 | | | sender-id | | 1180 | | +----------------+------------------------------+ 1181 | | | iprev | section 2.4.4 | 1182 | | +----------------+------------------------------+ 1183 | | | auth | section 2.4.5 | 1184 +-----------+----------+----------------+------------------------------+ 1185 | nxdomain | this | dkim-adsp | section 2.4.2 | 1186 | | document | | | 1187 +-----------+----------+----------------+------------------------------+ 1188 | signed | this | dkim-adsp | section 2.4.2 | 1189 | | document | | | 1190 +-----------+----------+----------------+------------------------------+ 1191 | unknown | this | dkim-adsp | section 2.4.2 | 1192 | | document | | | 1193 +-----------+----------+----------------+------------------------------+ 1194 | discard | this | dkim-adsp | section 2.4.2 | 1195 | | document | | | 1196 +-----------+----------+----------------+------------------------------+ 1197 | hardfail | this | spf | section 2.4.3 | 1198 | | document | sender-id | | 1199 | | +----------------+------------------------------+ 1200 | | | iprev | section 2.4.4 | 1201 +-----------+----------+----------------+------------------------------+ 1202 | softfail | this | spf | section 2.4.3 | 1203 | | document | sender-id | | 1204 | | +----------------+------------------------------+ 1205 | | | iprev | section 2.4.4 | 1206 +-----------+----------+----------------+------------------------------+ 1207 7. Security Considerations 1209 The following security considerations apply when adding or processing 1210 the "Authentication-Results" header field: 1212 7.1. Forged Header Fields 1214 An MUA or filter that accesses a mailbox whose mail is handled by a 1215 non-conformant MTA, and understands Authentication-Results header 1216 fields, could potentially make false conclusions based on forged 1217 header fields. A malicious user or agent could forge a header field 1218 using the DNS domain of a receiving ADMD as the authserv-id token in 1219 the value of the header field, and with the rest of the value claim 1220 that the message was properly authenticated. The non-conformant MTA 1221 would fail to strip the forged header field, and the MUA could 1222 inappropriately trust it. 1224 It is for this reason an MUA should not have processing of the 1225 "Authentication-Results" header field enabled by default; instead it 1226 should be ignored, at least for the purposes of enacting filtering 1227 decisions, unless specifically enabled by the user or administrator 1228 after verifying that the border MTA is compliant. It is acceptable 1229 to have an MUA aware of this specification, but have an explicit list 1230 of hostnames whose "Authentication-Results" header fields are 1231 trustworthy; however, this list should initially be empty. 1233 Proposed alternate solutions to this problem are nascent: 1235 1. Possibly the simplest is a digital signature protecting the 1236 header field, such as using [DKIM], that can be verified by an 1237 MUA using by a posted public key. Although one of the main 1238 purposes of this memo is to relieve the burden of doing message 1239 authentication work at the MUA, this only requires that the MUA 1240 learn a single authentication scheme even if a number of them are 1241 in use at the border MTA. Note that [DKIM] requires that the 1242 From header field be signed, although in this application the 1243 signing agent (a trusted MTA) likely cannot authenticate that 1244 value, so the fact that it is signed should be ignored. 1245 Moreover, DKIM's adjunct [I-D.DRAFT-IETF-DKIM-SSP] proposal 1246 should not be applied as it may result in an incorrect assertion. 1248 2. Another would be a means to interrogate the MTA that added the 1249 header field to see if it is actually providing any message 1250 authentication services and saw the message in question, but this 1251 isn't especially palatable given the work required to craft and 1252 implement such a scheme. 1254 3. Yet another might be a method to interrogate the internal MTAs 1255 which apparently handled the message (based on Received: header 1256 fields) to determine whether any of them conform to Section 5 of 1257 this memo. This, too, has potentially high barriers-to-entry. 1259 4. Extensions to [IMAP], [SMTP] and [POP3] could be defined which 1260 allow an MUA or filtering agent to acquire the "authserv-id" in 1261 use within an ADMD, thus allowing it to identify which 1262 Authentication-Results header fields it can trust. 1264 5. On the presumption that internal MTAs are fully compliant with 1265 section 3.6 of [MAIL], and the compliant internal MTAs are using 1266 their own host names or the ADMD's DNS domain name as the 1267 "authserv-id" token, the header field proposed here should always 1268 appear above a Received: header added by a trusted MTA. This can 1269 be used as a test for header field validity. 1271 Support for some of these is planned for future work. 1273 In any case, a mechanism needs to exist for an MUA or filter to 1274 verify that the host that appears to have added the header field (a) 1275 actually did so, and (b) is legitimately adding that header field for 1276 this delivery. Given the variety of messaging environments deployed 1277 today, consensus appears to be that specifying a particular mechanism 1278 for doing so is not appropriate for this memo. 1280 Mitigation of the forged header field attack can also be accomplished 1281 by moving the authentication results data into meta-data associated 1282 with the message. In particular, an [SMTP] extension could be 1283 established which is used to communicate authentication results from 1284 the border MTA to intermediate and delivery MTAs; the latter of these 1285 could arrange to store the authentication results as meta-data 1286 retrieved and rendered along with the message by an [IMAP] client 1287 aware of a similar extension in that protocol. The delivery MTA 1288 would be told to trust data via this extension only from MTAs it 1289 trusts, and border MTAs would not accept data via this extension from 1290 any source. There is no vector in such an arrangement for forgery of 1291 authentication data by an outside agent. 1293 7.2. Misleading Results 1295 Until some form of service for querying the reputation of a sending 1296 agent is widely deployed, the existence of this header field 1297 indicating a "pass" does not render the message trustworthy. It is 1298 possible for an arriving piece of spam or other undesirable mail to 1299 pass checks by several of the methods enumerated above (e.g. a piece 1300 of spam signed using [DKIM] by the originator of the spam, which 1301 might be a spammer or a compromised system). In particular, this 1302 issue is not resolved by forged header field removal discussed above. 1304 Hence, MUAs and downstream filters must take some care with use of 1305 this header even after possibly malicious headers are scrubbed. 1307 7.3. Header Field Position 1309 Despite the requirements of [MAIL], header fields can sometimes be 1310 reordered enroute by intermediate MTAs. The goal of requiring header 1311 field addition only at the top of a message is an acknowledgement 1312 that some MTAs do reorder header fields, but most do not. Thus, in 1313 the general case, there will be some indication of which MTAs (if 1314 any) handled the message after the addition of the header field 1315 defined here. 1317 7.4. Reverse IP Query Denial-Of-Service Attacks 1319 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 1320 for verifiers that attempt DNS-based identity verification of 1321 arriving client connections. A verifier wishing to do this check and 1322 report this information SHOULD take care not to go to unbounded 1323 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1324 making use of an "iprev" result specified by this memo SHOULD be 1325 aware of the algorithm used by the verifier reporting the result and 1326 thus be aware of its limitations. 1328 7.5. Mitigation of Backscatter 1330 Failing to follow the instructions of Section 4.2 can result in a 1331 denial-of-service attack caused by the generation of [DSN] messages 1332 (or equivalent) to addresses which did not send the messages being 1333 rejected. 1335 7.6. Internal MTA Lists 1337 Section 5 describes a procedure for scrubbing headers which may 1338 contain forged authentication results about a message. A compliant 1339 installation will have to include at each MTA a list of other MTAs 1340 known to be compliant and trustworthy. Failing to keep this list 1341 current as internal infrastructure changes may expose an ADMD to 1342 attack. 1344 7.7. Attacks Against Authentication Methods 1346 If an attack becomes known against an authentication method, clearly 1347 then the agent verifying that method can be fooled into thinking an 1348 inauthentic message is authentic, and thus the value of this header 1349 field can be misleading. It follows that any attack against the 1350 authentication methods supported by this document (and later 1351 amendments to it) is also a security consideration here. 1353 7.8. Intentionally Malformed Header Fields 1355 It is possible for an attacker to add an Authentication-Results 1356 header field which is extraordinarily large or otherwise malformed in 1357 an attempt to discover or exploit weaknesses in header field parsing 1358 code. Implementors must thoroughly verify all such header fields 1359 received from MTAs and be robust against intentionally as well as 1360 unintentionally malformed header fields. 1362 7.9. Compromised Internal Hosts 1364 An internal MUA or MTA which has been compromised could generate mail 1365 with a forged From header field and a forged Authentication-Results 1366 header field which endorses it. Although it is clearly a larger 1367 concern to have compromised internal machines than it is to prove the 1368 value of this header field, this risk can be mitigated by arranging 1369 that internal MTAs will remove this header field if it claims to have 1370 been added by a trusted border MTA (as described above) yet the 1371 [SMTP] connection is not coming from an internal machine known to be 1372 running an authorized MTA. However, in such a configuration, 1373 legitimate MTAs will have to add this header field when legitimate 1374 internal-only messages are generated. This is also covered in 1375 Section 5. 1377 7.10. Encapsulated Instances 1379 [MIME] messages may contain attachments of type "message/rfc822", 1380 which contain other [MAIL] messages. Such an encapsulated message 1381 may also contain an Authentication-Results header field. Although 1382 the processing of these is outside of the intended scope of this 1383 document (see Section 1.3), some early guidance to MUA developers is 1384 appropriate here. 1386 Since MTAs are unlikely to strip Authentication-Results header fields 1387 after mailbox delivery, MUAs are advised in Section 4.1 to ignore 1388 such instances within [MIME] attachments. Moreover, when extracting 1389 a message digest to separate mail store messages or other media, such 1390 header fields should be removed so that they will never be 1391 interpreted improperly by MUAs that might later consume them. 1393 7.11. Reverse Mapping 1395 Although Section 3 of this memo includes explicit support for the 1396 "iprev" method, its value as an authentication mechanism is limited. 1397 Implementors of both this proposal and agents which use the data it 1398 relays are encouraged to become familiar with the issues raised by 1399 [I-D.DRAFT-IETF-DNSOP-REVERSE] when deciding whether or not to 1400 include support for "iprev". 1402 8. References 1404 8.1. Normative References 1406 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1407 Specifications: ABNF", RFC 5234, January 2008. 1409 [IANA-HEADERS] 1410 Klyne, G., Nottingham, M., and J. Mogul, "Registration 1411 Procedures for Message Header Fields", RFC 3864, 1412 September 2004. 1414 [KEYWORDS] 1415 Bradner, S., "Key words for use in RFCs to Indicate 1416 Requirement Levels", RFC 2119, March 1997. 1418 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 1419 October 2008. 1421 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1422 Extensions (MIME) Part One: Format of Internet Message 1423 Bodies", RFC 2045, November 1996. 1425 8.2. Informative References 1427 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1428 for Authentication", RFC 4954, July 2007. 1430 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1431 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1432 Signatures", RFC 4871, May 2007. 1434 [DNS] Mockapetris, P., "Domain Names -- Implementation and 1435 Specification", RFC 1035, November 1987. 1437 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1438 "DNS Extensions to Support IP Version 6", RFC 3596, 1439 October 2003. 1441 [DOMAINKEYS] 1442 Delany, M., "Domain-based Email Authentication Using 1443 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1444 May 2007. 1446 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1447 for Delivery Status Notifications", RFC 3464, 1448 January 2003. 1450 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 1451 Crocker, D., "Internet Mail Architecture", 1452 draft-crocker-email-arch (work in progress), May 2007. 1454 [I-D.DRAFT-IETF-DKIM-SSP] 1455 Allman, E., Delany, M., and J. Fenton, "DKIM Author 1456 Signing Practices", draft-ietf-dkim-ssp (work in 1457 progress), November 2008. 1459 [I-D.DRAFT-IETF-DNSOP-REVERSE] 1460 Senie, D. and A. Sullivan, "Considerations for the use of 1461 DNS Reverse Mapping", 1462 draft-ietf-dnsop-reverse-mapping-considerations (work in 1463 progress), March 2008. 1465 [IANA-CONSIDERATIONS] 1466 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1467 IANA Considerations Section in RFCs", RFC 5226, May 2008. 1469 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 1470 4rev1", RFC 3501, March 2003. 1472 [POP3] Meyers, J. and M. Rose, "Post Office Protocol - Version 1473 3", RFC 1939, May 1996. 1475 [SECURITY] 1476 Rescorla, E., Korver, B., and IAB, "Guidelines for Writing 1477 RFC Text on Security Considerations", RFC 3552, July 2003. 1479 [SENDERID] 1480 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 1481 RFC 4406, April 2006. 1483 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1484 October 2008. 1486 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 1487 for Authorizing Use of Domains in E-Mail, Version 1", 1488 RFC 4408, April 2006. 1490 Appendix A. Acknowledgements 1492 The author wishes to acknowledge the following for their review and 1493 constructive criticism of this proposal: Eric Allman, Mark Delany, 1494 Victor Duchovni, Frank Ellermann, Jim Fenton, Philip Guenther, Tony 1495 Hansen, Paul Hoffman, Scott Kitterman, Eliot Lear, John Levine, Miles 1496 Libbey, Charles Lindsey, Alexey Melnikov, Douglas Otis, Juan Altmayer 1497 Pizzorno, Michael Thomas. 1499 Special thanks to Dave Crocker and S. Moonesamy for their logistical 1500 support, and feedback on and contributions to the numerous proposed 1501 edits throughout the lifetime of this work. 1503 Appendix B. Legacy MUAs 1505 Implementors of this proposal should be aware that many MUAs are 1506 unlikely to be retrofitted to support the new header field and its 1507 semantics. In the interests of convenience and quicker adoption, a 1508 delivery MTA might want to consider adding things that are processed 1509 by existing MUAs in addition to the Authentication-Results header 1510 field. One suggestion is to include a Priority header field, on 1511 messages that don't already have such a header field, containing a 1512 value that reflects the strength of the authentication that was 1513 accomplished, e.g. "low" for weak or no authentication, "normal" or 1514 "high" for good or strong authentication. 1516 Some modern MUAs can already filter based on the content of this 1517 header field. However, there is keen interest in having MUAs make 1518 some kind of graphical representation of this header field's meaning 1519 to end users. Until this capability is added, other interim means of 1520 conveying authentication results may be necessary while this proposal 1521 and its successors are adopted. 1523 Appendix C. Authentication-Results Examples 1525 This section presents some examples of the use of this header field 1526 to indicate authentication results. 1528 C.1. Trivial case; header field not present 1530 The trivial case: 1532 Received: from mail-router.example.com 1533 (mail-router.example.com [192.0.2.1]) 1534 by server.example.org (8.11.6/8.11.6) 1535 with ESMTP id g1G0r1kA003489; 1536 Fri, Feb 15 2002 17:19:07 -0800 1537 From: sender@example.com 1538 Date: Fri, Feb 15 2002 16:54:30 -0800 1539 To: receiver@example.org 1540 Message-Id: <12345.abc@example.com> 1541 Subject: here's a sample 1543 Hello! Goodbye! 1545 Example 1: Trivial case 1547 The "Authentication-Results" header field is completely absent. The 1548 MUA may make no conclusion about the validity of the message. This 1549 could be the case because the message authentication services were 1550 not available at the time of delivery, or no service is provided, or 1551 the MTA is not in compliance with this specification. 1553 C.2. Nearly-trivial case; service provided, but no authentication done 1555 A message that was delivered by an MTA that conforms to this 1556 specification but provides no actual message authentication service: 1558 Authentication-Results: example.org; none 1559 Received: from mail-router.example.com 1560 (mail-router.example.com [192.0.2.1]) 1561 by server.example.org (8.11.6/8.11.6) 1562 with ESMTP id g1G0r1kA003489; 1563 Fri, Feb 15 2002 17:19:07 -0800 1564 From: sender@example.com 1565 Date: Fri, Feb 15 2002 16:54:30 -0800 1566 To: receiver@example.org 1567 Message-Id: <12345.abc@example.com> 1568 Subject: here's a sample 1570 Hello! Goodbye! 1572 Example 2: Header present but no authentication done 1574 The "Authentication-Results" header field is present, showing that 1575 the delivering MTA conforms to this specification. It used its DNS 1576 domain name as the authserv-id. The presence of "none" (and the 1577 absence of any method and result tokens) indicates that no message 1578 authentication was done. 1580 C.3. Service provided, authentication done 1582 A message that was delivered by an MTA that conforms to this 1583 specification and applied some message authentication: 1585 Authentication-Results: example.com; 1586 spf=pass smtp.mailfrom=example.net 1587 Received: from dialup-1-2-3-4.example.net 1588 (dialup-1-2-3-4.example.net [192.0.2.200]) 1589 by mail-router.example.com (8.11.6/8.11.6) 1590 with ESMTP id g1G0r1kA003489; 1591 Fri, Feb 15 2002 17:19:07 -0800 1592 From: sender@example.net 1593 Date: Fri, Feb 15 2002 16:54:30 -0800 1594 To: receiver@example.com 1595 Message-Id: <12345.abc@example.net> 1596 Subject: here's a sample 1598 Hello! Goodbye! 1600 Example 3: Header reporting results 1601 The "Authentication-Results" header field is present, indicating that 1602 the border MTA conforms to this specification. The authserv-id is 1603 once again the DNS domain name. Furthermore, the message was 1604 authenticated by that MTA via the method specified in [SPF]. Note 1605 that since that method cannot authenticate the local-part, it has 1606 been omitted from the result's value. The MUA could extract and 1607 relay this extra information if desired. 1609 C.4. Service provided, several authentications done, single MTA 1611 A message that was relayed inbound via a single MTA that conforms to 1612 this specification and applied three different message authentication 1613 checks: 1615 Authentication-Results: example.com; 1616 auth=pass (cram-md5) smtp.auth=sender@example.com; 1617 spf=pass smtp.mailfrom=example.com 1618 Authentication-Results: example.com; 1619 sender-id=pass header.from=example.com 1620 Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1621 (dialup-1-2-3-4.example.net [192.0.2.200]) 1622 by mail-router.example.com (8.11.6/8.11.6) 1623 with ESMTP id g1G0r1kA003489; 1624 Fri, Feb 15 2002 17:19:07 -0800 1625 Date: Fri, Feb 15 2002 16:54:30 -0800 1626 To: receiver@example.net 1627 From: sender@example.com 1628 Message-Id: <12345.abc@example.com> 1629 Subject: here's a sample 1631 Hello! Goodbye! 1633 Example 4: Headers reporting results from one MTA 1635 The "Authentication-Results" header field is present, indicating the 1636 delivering MTA conforms to this specification. Once again, the 1637 receiving DNS domain name is used as the authserv-id. Furthermore, 1638 the sender authenticated herself/himself to the MTA via a method 1639 specified in [AUTH], and both [SPF] and [SENDERID] checks were done 1640 and passed. The MUA could extract and relay this extra information 1641 if desired. 1643 Two "Authentication-Results" header fields are not required since the 1644 same host did all of the checking. The authenticating agent could 1645 have consolidated all the results into one header field. 1647 This example illustrates a scenario in which a remote user on a 1648 dialup connection (example.net) sends mail to a border MTA 1649 (example.com) using SMTP authentication to prove identity. The 1650 dialup provider has been explicitly authorized to relay mail as 1651 "example.com" resulting in passes by the SPF and SenderID checks. 1653 C.5. Service provided, several authentications done, different MTAs 1655 A message that was relayed inbound by two different MTAs that conform 1656 to this specification and applied multiple message authentication 1657 checks: 1659 Authentication-Results: example.com; 1660 sender-id=hardfail header.from=example.com; 1661 dkim=pass (good signature) header.i=sender@example.com 1662 Received: from mail-router.example.com 1663 (mail-router.example.com [192.0.2.1]) 1664 by auth-checker.example.com (8.11.6/8.11.6) 1665 with ESMTP id i7PK0sH7021929; 1666 Fri, Feb 15 2002 17:19:22 -0800 1667 Authentication-Results: example.com; 1668 auth=pass (cram-md5) smtp.auth=sender@example.com; 1669 spf=hardfail smtp.mailfrom=example.com 1670 Received: from dialup-1-2-3-4.example.net 1671 (dialup-1-2-3-4.example.net [192.0.2.200]) 1672 by mail-router.example.com (8.11.6/8.11.6) 1673 with ESMTP id g1G0r1kA003489; 1674 Fri, Feb 15 2002 17:19:07 -0800 1675 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1676 t=1188964191; c=simple/simple; 1677 h=From:Date:To:Message-Id:Subject; 1678 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1679 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1680 From: sender@example.com 1681 Date: Fri, Feb 15 2002 16:54:30 -0800 1682 To: receiver@example.com 1683 Message-Id: <12345.abc@example.com> 1684 Subject: here's a sample 1686 Hello! Goodbye! 1688 Example 5: Headers reporting results from multiple MTAs 1690 The "Authentication-Results" header field is present, indicating 1691 conformance to this specification. Once again, the authserv-id used 1692 is the recipient's DNS domain name. The header field is present 1693 twice because two different MTAs in the chain of delivery did 1694 authentication tests. The first, "mail-router.example.com" reports 1695 that [AUTH] and [SPF] were both used, and [AUTH] passed but [SPF] 1696 failed. In the [AUTH] case, additional data is provided in the 1697 comment field, which the MUA can choose to render if desired. 1699 The second MTA, "auth-checker.example.com", reports that it did a 1700 [SENDERID] test (which failed) and a [DKIM] test (which passed). 1701 Again, additional data about one of the tests is provided as a 1702 comment, which the MUA may choose to render. 1704 Since different hosts did the two sets of authentication checks, the 1705 header fields cannot be consolidated in this example. 1707 This example illustrates more typical transmission of mail into 1708 "example.com" from a user on a dialup connection "example.net". The 1709 user appears to be legitimate as he/she had a valid password allowing 1710 authentication at the border MTA using [AUTH]. The [SPF] and 1711 [SENDERID] tests failed since "example.com" has not granted 1712 "example.net" authority to relay mail on its behalf. However, the 1713 [DKIM] test passed because the sending user had a private key 1714 matching one of "example.com"'s published public keys and used it to 1715 sign the message. 1717 C.6. Service provided, multi-tiered authentication done 1719 A message that had authentication done at various stages, one of 1720 which was outside the receiving ADMD: 1722 Authentication-Results: example.com; 1723 dkim=pass (good signature) header.i=@mail-router.example.net; 1724 dkim=fail (bad signature) header.i=@newyork.example.com 1725 Received: from mail-router.example.net 1726 (mail-router.example.net [192.0.2.250]) 1727 by chicago.example.com (8.11.6/8.11.6) 1728 for 1729 with ESMTP id i7PK0sH7021929; 1730 Fri, Feb 15 2002 17:19:22 -0800 1731 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1732 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1733 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1734 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1735 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1736 Authentication-Results: example.net; 1737 dkim=pass (good signature) header.i=@newyork.example.com 1738 Received: from smtp.newyork.example.com 1739 (smtp.newyork.example.com [192.0.2.220]) 1740 by mail-router.example.net (8.11.6/8.11.6) 1741 with ESMTP id g1G0r1kA003489; 1742 Fri, Feb 15 2002 17:19:07 -0800 1743 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; 1744 t=1188964191; c=simple/simple; 1745 h=From:Date:To:Message-Id:Subject; 1746 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1747 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1748 From: sender@newyork.example.com 1749 Date: Fri, Feb 15 2002 16:54:30 -0800 1750 To: meetings@example.net 1751 Message-Id: <12345.abc@newyork.example.com> 1752 Subject: here's a sample 1754 Example 6: Headers reporting results from multiple MTAs in different 1755 ADMDs 1757 In this example we see multi-tiered authentication with an extended 1758 trust boundary. 1760 The message was sent from someone at example.com's New York office 1761 (newyork.example.com) to a mailing list managed at an intermediary. 1762 The message was signed at the origin using [DKIM]. 1764 The message was sent to a mailing list service provider called 1765 example.net which is used by example.com. There, 1766 meetings@example.net is expanded to a long list of recipients, one of 1767 which is at the Chicago office. In this example, we will assume that 1768 the trust boundary for chicago.example.com includes the mailing list 1769 server at example.net. 1771 The mailing list server there first authenticated the message and 1772 affixed an Authentication-Results header field indicating such using 1773 its DNS domain name for the authserv-id. It then altered the message 1774 by affixing some footer text to the body including some administrivia 1775 such as unsubscription instructions. Finally, the mailing list 1776 server affixes a second [DKIM] signature and begins distribution of 1777 the message. 1779 The border MTA for chicago.example.com explicitly trusts results from 1780 mail-router.example.net so that header field is not removed. It 1781 performs evaluation of both signatures and determines that the first 1782 (most recent) is a "pass" but, because of the aforementioned 1783 modifications, the second is a "fail". However, the first signature 1784 included the Authentication-Results header added at mail- 1785 router.example.net which validated the second signature. Thus, 1786 indirectly, it can be determined that the authentications claimed by 1787 both signatures are indeed valid. 1789 Appendix D. Operational Considerations About Message Authentication 1791 This proposal is predicated on the idea that authentication (and 1792 presumably in the future, reputation) work is typically done by 1793 border MTAs rather than MUAs or intermediate MTAs; the latter merely 1794 make use of the results determined by the former. Certainly this is 1795 not mandatory for participation in electronic mail or message 1796 authentication, but the work of this proposal and its deployment to 1797 date is based on that model. The assumption satisfies several common 1798 ADMD requirements: 1800 1. Service operators prefer to resolve the handling of problem 1801 messages as close to the border of the ADMD as possible. This 1802 enables, for example, rejections of messages at the SMTP level 1803 rather than generating a DSN internally. Thus, doing any of the 1804 authentication or reputation work exclusively at the MUA or 1805 intermediate MTA renders this desire unattainable. 1807 2. Border MTAs are more likely to have direct access to external 1808 sources of authentication or reputation information since modern 1809 MUAs are more likely to be heavily firewalled. Thus, some MUAs 1810 might not even be able to complete the task of performing 1811 authentication or reputation evaluations without complex proxy 1812 configurations or similar burdens. 1814 3. MUAs rely upon the upstream MTAs within their trust boundaries to 1815 make correct (as much as that is possible) evaluations about the 1816 message's envelope, header and content. Thus, MUAs don't need to 1817 know how to do the work that upstream MTAs do; they only need the 1818 results of that work. 1820 4. Evaluations about the quality of a message, from simple token 1821 matching (e.g. a list of preferred DNS domains) to cryptanalysis 1822 (e.g. public/private key work), are at least a little bit 1823 expensive and thus should be minimized. To that end, performing 1824 those tests at the border MTA is far preferred to doing that work 1825 at each MUA that handles a message. If an ADMD's environment 1826 adheres to common messaging protocols, a reputation query or an 1827 authentication check performed by a border MTA would return the 1828 same result as the same query performed by an MUA. By contrast, 1829 in an environment where the MUA does the work, a message arriving 1830 for multiple recipients would thus cause authentication or 1831 reputation evaluation to be done more than once for the same 1832 message (i.e. at each MUA) causing needless amplification of 1833 resource use and creating a possible denial-of-service attack 1834 vector. 1836 5. Minimizing change is good. As new authentication and reputation 1837 methods emerge, the list of methods supported by this header 1838 field would presumably be extended. If MUAs simply consume the 1839 contents of this header field rather than actually attempting to 1840 do authentication and/or reputation work, then MUAs only need to 1841 learn to parse this header field once; emergence of new methods 1842 requires only a configuration change at the MUAs and software 1843 changes at the MTAs (which are presumably fewer in number). When 1844 choosing to implement these functions in MTAs vs MUAs, the issues 1845 of individual flexibility, infrastructure inertia and scale of 1846 effort must be considered. It is typically easier to change a 1847 single MUA than an MTA because the modification affects fewer 1848 users and can be pursued with less care. However, changing many 1849 MUAs is more effort than changing a smaller number of MTAs. 1851 6. For decisions affecting message delivery and display, assessment 1852 based on authentication and reputation is best performed close to 1853 the time of message transit, as a message makes its journey 1854 toward a user's inbox, not afterwards. DKIM keys and IP address 1855 reputations, etc., can change over time or even become invalid, 1856 and users can take a long time to read a message once delivered. 1857 The value of this work thus degrades, perhaps quickly, once the 1858 delivery process has completed. This seriously diminishes the 1859 value of this work when done other than at MTAs. 1861 Many operational choices are possible within an ADMD, including the 1862 venue for performing authentication and/or reputation assessment. 1863 The current specification does not dictate any of those choices. 1864 Rather, it facilitates those cases in which information produced by 1865 one stage of analysis needs to be transported with the message to the 1866 next stage. 1868 Appendix E. Public Discussion, History and Support 1870 [REMOVE BEFORE PUBLICATION] 1872 Public discussion of this proposed specification is handled via the 1873 mail-vet-discuss@mipassoc.org mailing list. The list is open. 1874 Access to subscription forms and to list archives can be found at 1875 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. Active 1876 participation has included such sectors as messaging software 1877 vendors, messaging service providers, messaging consultants, 1878 messaging reputation data providers, financial institutions, etc. 1880 A representative of the SPF Council is a member of the discussion 1881 list named above and has been an active participant in the vetting of 1882 this draft from the SPF perspective. Other participants have 1883 contributed from the perspectives of DKIM, DomainKeys and Sender-ID, 1884 and even as-yet-undefined reputation systems. 1886 The concept of this header field was introduced in 2004 during the 1887 development of DomainKeys and SPF, each of which proposed distinct 1888 header fields for relaying the results of verifier attempts to use 1889 each of those schemes. With more proposals for message sender 1890 authentication on the horizon, it was obvious that the header block 1891 of messages could become very cluttered without some unification 1892 work. 1894 Interest in the advancement of this work toward proposed standard 1895 status has also been expressed at the Messaging Anti-Abuse Working 1896 Group (MAAWG) where it has been discussed at several of their 1897 meetings. The work is further referenced by the Abuse Reporting 1898 Format (ARF) draft (draft-shafranovich-feedback-report) which thus 1899 relies on this work to assist in the relay to an ARF recipient the 1900 authentication work done on a message, with the intent of explaining 1901 such an abuse report. There is some interest in advancing that draft 1902 toward IETF publication in the not-too-distant future. Several MAAWG 1903 participants (mainly including large ISPs) already use ARF, and thus 1904 this draft (indirectly), in their message processing feedback loops. 1906 The DKIM working group considered adopting this draft as a working 1907 group document more than once, but it was determined to be outside of 1908 its charter and thus not appropriate to recharter to cover its 1909 advancement. Moreover, the original DKIM base spec ([DKIM]) at one 1910 point recommended the use of this header field proposal, but that 1911 reference was removed as it would have delayed publication of that 1912 RFC. 1914 Several companies have already adopted use of this proposal, 1915 including large-scale e-mail hosting providers and software vendors. 1917 For a list of these, see the PROTO document supporting this draft. 1919 This work will likely give rise to similar mechanisms which employ 1920 more "closed-circuit" methods for dealing with message authentication 1921 work, such as extensions to SMTP and IMAP. 1923 Author's Address 1925 Murray S. Kucherawy 1926 Sendmail, Inc. 1927 6475 Christie Ave., Suite 350 1928 Emeryville, CA 94608 1929 US 1931 Phone: +1 510 594 5400 1932 Email: msk+ietf@sendmail.com