idnits 2.17.1 draft-kucherawy-sender-auth-header-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1622. 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 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 (October 23, 2008) is 5663 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 320, but not defined == Missing Reference: 'TBD' is mentioned on line 908, 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 12 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 October 23, 2008 5 Expires: April 26, 2009 7 Message Header Field for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-header-17 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This memo defines a new message header field for use with electronic 42 mail messages to indicate the results of message authentication 43 efforts. Mail user agents (MUAs) may use this message header field 44 to relay that information in a convenient way to users or to make 45 sorting and filtering decisions. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 53 1.4. Trust Environment . . . . . . . . . . . . . . . . . . . . 6 54 2. Definition and Format of the Header . . . . . . . . . . . . . 7 55 2.1. General Description . . . . . . . . . . . . . . . . . . . 7 56 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 7 57 2.3. Authentication Identifier Fields . . . . . . . . . . . . . 10 58 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 10 59 2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 10 60 2.4.2. DKIM ADSP Results . . . . . . . . . . . . . . . . . . 11 61 2.4.3. SPF and Sender-ID Results . . . . . . . . . . . . . . 12 62 2.4.4. iprev Results . . . . . . . . . . . . . . . . . . . . 13 63 2.4.5. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 13 64 2.4.6. Extension Result Codes . . . . . . . . . . . . . . . . 14 65 2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15 66 2.5.1. Definition Of Initial Methods . . . . . . . . . . . . 15 67 2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 15 68 3. The 'iprev' Authentication Method . . . . . . . . . . . . . . 17 69 4. Adding The Header Field To A Message . . . . . . . . . . . . . 18 70 4.1. Header Position and Interpretation . . . . . . . . . . . . 18 71 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 19 72 5. Removing The Header Field . . . . . . . . . . . . . . . . . . 21 73 6. Conformance and Usage Requirements . . . . . . . . . . . . . . 22 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 75 7.1. The Authentication-Results: header . . . . . . . . . . . . 23 76 7.2. Email Authentication Method Name Registry . . . . . . . . 23 77 7.3. Email Authentication Result Name Registry . . . . . . . . 24 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 79 8.1. Forged Headers . . . . . . . . . . . . . . . . . . . . . . 27 80 8.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 28 81 8.3. Other Protocols . . . . . . . . . . . . . . . . . . . . . 28 82 8.4. Header Position . . . . . . . . . . . . . . . . . . . . . 29 83 8.5. Reverse IP Query Denial-Of-Service Attacks . . . . . . . . 29 84 8.6. Mitigation of Backscatter . . . . . . . . . . . . . . . . 29 85 8.7. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 29 86 8.8. Attacks Against Authentication Methods . . . . . . . . . . 29 87 8.9. Intentionally Malformed Header Fields . . . . . . . . . . 30 88 8.10. Compromised Internal Hosts . . . . . . . . . . . . . . . . 30 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 92 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 33 93 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 34 94 Appendix C. Authentication-Results Examples . . . . . . . . . . . 35 95 C.1. Trivial case; header field not present . . . . . . . . . . 35 96 C.2. Nearly-trivial case; service provided, but no 97 authentication done . . . . . . . . . . . . . . . . . . . 36 98 C.3. Service provided, authentication done . . . . . . . . . . 36 99 C.4. Service provided, several authentications done, single 100 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 101 C.5. Service provided, several authentications done, 102 different MTAs . . . . . . . . . . . . . . . . . . . . . . 38 103 C.6. Service provided, multi-tiered authentication done . . . . 40 104 Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 42 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 106 Intellectual Property and Copyright Statements . . . . . . . . . . 44 108 1. Introduction 110 This memo defines a new message header field for electronic mail 111 messages which presents the results of a message authentication 112 effort in a machine-readable format. The intent is to create a place 113 to collect such data when message authentication mechanisms are in 114 use so that a Mail User Agent (MUA) can provide a recommendation to 115 the user as to the validity of the message's origin and possibly the 116 integrity of its content. 118 This memo defines both the format of this new header field, and 119 discusses the implications of its presence or absence. 121 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 122 draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the 123 published e-mail authentication methods in common use. As various 124 methods emerge, it is necessary to prepare for their appearance and 125 encourage convergence in the area of interfacing these filters to 126 MUAs. 128 Although [SPF] defined a header field called Received-SPF for this 129 purpose, that header field is specific to the conveyance of SPF and 130 similar results only and thus is insufficient to satisfy the 131 requirements enumerated below. 133 1.1. Purpose 135 The header field defined in this memo is expected to serve several 136 purposes: 138 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the 139 results of various message authentication checks being applied; 141 2. Provide a common location for the presentation of this data; 143 3. Create an extensible framework for reporting new authentication 144 methods as such emerge; 146 4. Convey the results of message authentication tests to later 147 filtering agents within the same "trust domain", as such agents 148 might apply more or less stringent checks based on message 149 authentication results. 151 1.2. Requirements 153 This memo establishes no new requirements on existing protocols or 154 servers, as there is currently no standard place for the described 155 data to be collected or presented. 157 In particular, this memo establishes no requirement on MTAs to reject 158 or filter arriving messages which do not pass authentication checks. 159 The data conveyed by the defined header field's contents are for the 160 information of MUAs and filters and should be used at their 161 discretion. 163 1.3. Definitions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [KEYWORDS]. 169 A "border MTA" is an MTA which acts as a gateway between the general 170 Internet and the users within an organizational boundary. 172 A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which 173 actually enacts delivery of a message to a user's inbox or other 174 final delivery. 176 An "intermediate MTA" is an MTA which handles messages after a border 177 MTAs and before a delivery MTA. 179 +-----+ +-----+ +------------+ 180 | MUA |-->| MSA |-->| Border MTA | 181 +-----+ +-----+ +------------+ 182 | 183 | 184 V 185 +----------+ 186 | Internet | 187 +----------+ 188 | 189 | 190 V 191 +-----+ +-----+ +------------------+ +------------+ 192 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 193 +-----+ +-----+ +------------------+ +------------+ 195 Generally it is assumed that the work of applying message 196 authentication schemes takes place at a border MTA or a delivery MTA. 197 This specification is written with that assumption in mind. However, 198 there are some sites at which the entire mail infrastructure consists 199 of a single host. In such cases, such terms as "border MTA" and 200 "delivery MTA" may well apply to the same machine or even the very 201 same agent. It is also possible that message authentication could 202 take place on an intermediate MTA. Although this document doesn't 203 specifically describe such cases, they are not meant to be excluded 204 from this specification. 206 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 207 system architecture. 209 1.4. Trust Environment 211 This new header field permits one or more message validation 212 mechanisms to communicate its output to one or more separate 213 assessment mechanisms. These mechanisms operate within a unified 214 trust boundary that defines an Administrative Management Domain 215 (ADMD). An ADMD contains one or more entities that perform 216 validation and generate the header field, and one or more that 217 consume it for some type of assessment. The field contains no 218 integrity or validation mechanism of its own, so its presence must be 219 trusted implicitly. Hence, use of the header field depends upon 220 ensuring that mail entering the ADMD has instances of the header 221 field claiming to be valid within this domain removed, so that 222 occurrences of such header fields can be trusted by consumers. 224 The "authserv-id" token defined in Section 2.2 can be used to label 225 an entire ADMD or a specific validation engine within an ADMD. 226 Although the labeling scheme is left as an operational choice, some 227 guidance for selecting a token is provided within this proposal. 229 2. Definition and Format of the Header 231 This section gives a general overview of the format of the header 232 field being defined, and then provides more formal specification. 234 2.1. General Description 236 The new header field being defined here is called "Authentication- 237 Results". It is a Structured Header Field as defined in [MAIL] and 238 thus all of the related definitions in that document apply. 240 This new header field MUST be added at the top of the message as it 241 transits MTAs which do authentication checks so some idea of how far 242 away the checks were done can be inferred. It therefore should be 243 treated as a Trace Field as defined in [MAIL] and thus all of the 244 related definitions in that document apply. 246 The value of the header field (after removing [MAIL] comments) 247 consists of an authentication identifier, an optional version and 248 then a series of "method=result" statements indicating which 249 authentication method(s) were applied and their respective results, 250 and then, for each applied method, an optional "reason" string plus 251 optional "property=value" statements indicating which message 252 properties were evaluated to reach that conclusion. 254 The header field MAY appear more than once in a single message, or 255 more than one result MAY be represented in a single header field, or 256 a combination of these MAY be applied. 258 2.2. Formal Definition 260 Formally, the header field is specified as follows using [ABNF]: 262 header = "Authentication-Results:" [CFWS] authserv-id 263 [ CFWS version ] 264 ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF 265 ; the special case of "none" is used to indicate that no 266 ; message authentication is performed 268 authserv-id = dot-atom-text 269 ; see below for a description of this element; 270 ; "dot-atom-text" is defined in section 3.2.4 of [MAIL] 272 version = 1*DIGIT [CFWS] 273 ; indicates which version of this specification is in use; 274 ; this specification is version "1"; the absence of a version 275 ; implies this version of the specification 277 resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ] 278 *( CFWS propspec ) 280 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 281 ; indicates which authentication method was evaluated 283 reasonspec = "reason" [CFWS] "=" [CFWS] value 284 ; a free-form comment on the reason the given result 285 ; was returned 287 propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue 288 ; an indication of which properties of the message 289 ; were evaluated by the authentication scheme being 290 ; applied to yield the reported result 292 method = token [ [CFWS] "/" [CFWS] version ] 293 ; a method indicates which method's result is 294 ; represented by "result", and is one of the methods 295 ; explicitly defined as valid in this document 296 ; or is an extension method as defined below 298 result = token 299 ; indicates the results of the attempt to authenticate 300 ; the message; see below for details 302 ptype = "smtp" / "header" / "body" / "policy" 303 ; indicates whether the property being evaluated was 304 ; a parameter to an [SMTP] command, or was a value taken 305 ; from a message header field, or was some property of 306 ; the message body, or some other property evaluated by 307 ; the receiving MTA 309 property = token 310 ; if "ptype" is "smtp", this indicates which [SMTP] 311 ; command provided the value which was evaluated by the 312 ; authentication scheme being applied; if "ptype" is 313 ; "header", this indicates from which header field the 314 ; value being evaluated was extracted; if "ptype" is 315 ; "body", this indicates the offset into the body at which 316 ; content of interest was detected; if "ptype" is "policy" 317 ; then this indicates the name of the policy which caused 318 ; this header field to be added (see below) 320 pvalue = [CFWS] ( token / addr-spec ) [CFWS] 321 ; the value extracted from the message property defined 322 ; by the "ptype.property" construction; if the value 323 ; identifies an address, then it is an "addr-spec" 324 ; as defined in section 3.4 of [MAIL] 326 The "token" and "value" are as defined in section 5.1 of [MIME]. 328 The "token" used in a "result" above is further constrained by the 329 necessity of being enumerated in Section 2.4 or an amendment to it. 331 See Section 2.3 for a description of the "authserv-id" element. 333 The list of commands eligible for use with the "smtp" ptype can be 334 found in [SMTP] and subsequent amendments. 336 "CFWS" is as defined in section 3.2.3 of [MAIL]. 338 The "propspec" may be omitted if for example the method was unable to 339 extract any properties to do its evaluation yet has a result to 340 report. 342 The "ptype" and "property" values used by each authentication method 343 should be defined in the specification for that method (or its 344 amendments). 346 The "ptype" and "property" are case-insensitive. 348 A "ptype" value of "policy" indicates a policy decision about the 349 message not specific to a property of the message that could be 350 extracted. For example, if a method would normally report a 351 "ptype.property" of "header.From" and no From: header field was 352 present, the method can use "policy" to indicate that no conclusion 353 about the authenticity of the message could be reached. 355 If the parsed "ptype.property" construction clearly identifies a 356 mailbox (in particular, smtp.mailfrom, smtp.rcpt, header.from, 357 header.sender), then the "pvalue" MUST be an "addr-spec". Other 358 properties (e.g. smtp.helo) may be evaluated, but the property MUST 359 still be expressed as a "token" for simplified parsing. 361 2.3. Authentication Identifier Fields 363 Every Authentication-Results header field has an authentication 364 identifier field ("authserv-id" above). This is similar in syntax to 365 a fully-qualified domain name. 367 The authentication identifier field provides a unique identifier that 368 refers to the authenticating service within a given mail 369 administrative domain. The uniqueness of the identifier MUST be 370 guaranteed by the mail administrative domain that generates it and 371 must pertain to exactly that one mail administrative domain. This 372 identifier is intended to be machine-readable and not necessarily 373 meaningful to users. MUAs may use this identifier to determine 374 whether or not the data contained in an Authentication-Results header 375 field can be trusted. 377 For tracing and debugging purposes, the authentication identifier 378 SHOULD be the hostname of the MTA performing the authentication check 379 whose result is being reported. This is also useful for another 380 purpose, as described in Section 4. 382 Examples of valid authentication identifiers are mail.example.org, 383 engineering.example.net and ms1.newyork.example.com. 385 2.4. Result Values 387 Each individual authentication method returns one of a set of 388 specific result values. The subsections below define these results 389 for the authentication methods specifically supported by this memo. 390 New methods not specified in this document intended to be supported 391 by the header field defined in this memo MUST include a similar 392 result table either in its defining memo or in a supplementary one. 394 2.4.1. DKIM and DomainKeys Results 396 The result values used by [DKIM] and [DOMAINKEYS] are as follows: 398 none: The message was not signed. 400 pass: The message was signed, the signature(s) is (were) acceptable 401 to the verifier, and the signature(s) passed verification tests. 403 fail: The message was signed and the signature(s) is (were) 404 acceptable to the verifier, but it (they) failed the verification 405 test(s). 407 policy: The message was signed but the signature(s) is (were) not 408 acceptable to the verifier. 410 neutral: The message was signed but the signature(s) contained 411 syntax errors or were not otherwise able to be processed. This 412 result SHOULD also be used for other failures not covered 413 elsewhere in this list. 415 temperror: The message could not be verified due to some error which 416 is likely transient in nature, such as a temporary inability to 417 retrieve a public key. A later attempt may produce a final 418 result. 420 permerror: The message could not be verified due to some error which 421 is unrecoverable, such as a required header field being absent. A 422 later attempt is unlikley to produce a final result. 424 A signature is "acceptable to the verifier" if it passes local policy 425 checks (or there are no specific local policy checks). For example, 426 a verifier might require that the signature(s) on the message be 427 added by the domain identified in the From: header field of the 428 message, thus making third-party signatures unacceptable. 430 2.4.2. DKIM ADSP Results 432 The result values are used by [I-D.DRAFT-IETF-DKIM-SSP] as follows: 434 none: No DKIM author domain signing practises (ADSP) record was 435 published. 437 pass: A DKIM ADSP record was published which indicated the mail 438 should be signed with an author signature, and this message had 439 such a signature that validated. 441 unknown: No valid author signature was found on the message and 442 either the published ADSP was "unknown", or no policy was 443 published. 445 signed: A valid author signature was found on the message and the 446 published ADSP was "unknown". 448 fail: No valid author signature was found on the message and the 449 published ASDP record indicated an "all" policy. 451 discard: No valid author signature was found on the message and the 452 published ADSP record indicated a "discardable" policy. 454 nxdomain: Evaluating the ADSP for the author's domain indicated that 455 the author's domain does not exist. 457 temperror: A DKIM policy could not be retrieved due to some error 458 which is likely transient in nature, such as a temporary DNS 459 error. A later attempt may produce a final result. 461 permerror: A DKIM policy could not be retrieved due to some error 462 which is likely not transient in nature, such as a permanent DNS 463 error. A later attempt is unlikely to produce a final result. 465 2.4.3. SPF and Sender-ID Results 467 The result values are used by [SPF] and [SENDERID] as follows: 469 none: No policy records were published by the sender's domain. 471 neutral: The sender's domain has asserted that it cannot or does not 472 want to assert whether or not the sending IP address is authorized 473 to send mail on behalf of the sender's domain. 475 pass: The client is authorized to inject or relay mail on behalf of 476 the sender's domain. 478 policy: The client is authorized to inject or relay mail on behalf 479 of the sender's domain according to the authentication method's 480 algorithm, but local policy dictates that the result is 481 unacceptable. 483 hardfail: This client is explicitly not authorized to inject or 484 relay mail on behalf of the sender's domain. 486 softfail: The sender's domain believes the client was not authorized 487 to inject or relay mail on its behalf but is unwilling to make a 488 strong assertion to that effect. 490 temperror: The message could not be verified due to some error which 491 is likely transient in nature, such as a temporary inability to 492 retrieve a policy record from DNS. A later attempt may produce a 493 final result. 495 permerror: The message could not be verified due to some error which 496 is unrecoverable, such as a required header field being absent. A 497 later attempt is unlikley to produce a final result. 499 The distinction between and interpretation of "none" and "neutral" 500 under these methods is discussed further in [SPF]. 502 The "policy" result would be returned if, for example, [SPF] returned 503 as "pass" result, but a local policy check matches the sending domain 504 to one found in an explicit list of unacceptable domains (e.g. 505 spammers). 507 2.4.4. iprev Results 509 The result values are used by the "iprev" method, defined in 510 Section 3, are as follows: 512 pass: The reverse DNS evaluation succeeded, i.e. the "reverse" and 513 "forward" lookup results were in agreement. 515 hardfail: The reverse DNS evaluation failed. In particular, the 516 "reverse" and "forward" lookups each produced results but they 517 were not in agreement. 519 softfail: The reverse DNS evaluation failed. In particular, one or 520 both of the "reverse" and forward lookups returned no data (i.e. a 521 DNS reply code of NODATA). 523 temperror: The reverse DNS evaluation could not be completed due to 524 some error which is likely transient in nature, such as a 525 temporary DNS error. A later attempt may produce a final result. 527 permerror: The reverse DNS evaluation could not be completed due to 528 some error which is unrecoverable (e.g. a DNS reply code of NODATA 529 or NXDOMAIN). A later attempt is unlikely to produce a final 530 result. 532 There is no "none" for this method since any TCP connection 533 delivering e-mail has an IP address associated with it, so some kind 534 of evaluation will always be possible. 536 2.4.5. SMTP AUTH Results 538 The result values are used by the [AUTH] method are as follows: 540 none: SMTP authentication was not attempted. 542 pass: The SMTP client had authenicated to the server reporting the 543 result using the protocol described in [AUTH]. 545 fail: The SMTP client had attempted to authenticate to the server 546 using the protocol described in [AUTH] but was not successful, yet 547 continued to send the message about which a result is being 548 reported. 550 temperror: The SMTP client attempted to authenticate using the 551 protocol described in [AUTH] but was not able to complete the 552 attempt due to some error which is likely transient in nature, 553 such as a temporary LDAP lookup error. A later attempt may 554 produce a final result. 556 permerror: The SMTP client attempted to authenticate using the 557 protocol described in [AUTH] but was not able to complete the 558 attempt due to some error which is likely not transient in nature, 559 such as a permanent LDAP lookup error. A later attempt is not 560 likely produce a final result. 562 Note that an agent making use of the data provided by this header 563 field SHOULD consider "fail" and "temperror" to be the synonymous in 564 terms of message authentication, i.e. the client did not 565 authenticate. 567 2.4.6. Extension Result Codes 569 Additional result codes (extension results) might be defined in the 570 future by later revisions or extensions to this specification. 571 Extension results beginning with "x-" will never be defined as 572 standard fields; such names are reserved for experimental use. 573 Result codes not beginning with "x-" MUST be registered with the 574 Internet Assigned Numbers Authority (IANA) and published in an RFC. 575 See Section 7 for further details. 577 Implementations reporting new result codes MUST use the "x-" prefix 578 until such time as the new method is registered by IANA. 580 Extension results MUST only be used within trust domains that have 581 explicitly consented to use them. These results and the parameters 582 associated with them are not documented in RFCs. Therefore, they are 583 subject to change at any time and not suitable for production use. 584 Any MTA or MUA intended for production use SHOULD ignore or delete 585 any Authentication-Results header field that includes an extension 586 result. 588 2.5. Authentication Methods 590 This section defines the supported authentication methods and 591 discusses the proper means for applying experimental and other 592 extension methods. 594 2.5.1. Definition Of Initial Methods 596 As they are currently existing specifications for message 597 authentication, it is appropriate to define an authentication method 598 identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and 599 [SPF]. Therefore, the authentication method identifiers "auth", 600 "dkim", "domainkeys", "senderid" and "spf" respectively are hereby 601 defined for MTAs applying those specifications for e-mail message 602 authentication. 604 Furthermore, method "iprev" is defined in Section 3. 606 Finally, as its publication is imminent, this document also defines 607 "dkim-adsp" per [I-D.DRAFT-IETF-DKIM-SSP]. 609 See Section 7 for details. 611 2.5.2. Extension Methods 613 Additional authentication method identifiers (extension methods) may 614 be defined in the future by later revisions or extensions to this 615 specification. Extension methods beginning with "x-" will never be 616 defined as standard fields; such names are reserved for experimental 617 use. Method identifiers not beginning with "x-" MUST be registered 618 with the Internet Assigned Numbers Authority (IANA) and published in 619 an RFC. See Section 7 for further details. 621 Extension methods may be defined for the following reasons: 623 1. To allow additional information from new authentication systems 624 to be communicated to MUAs. The names of such identifiers should 625 reflect the name of the method being defined, but should not be 626 needlessly long. 628 2. To allow the creation of "sub-identifiers" which indicate 629 different levels of authentication and differentiate between 630 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 632 Implementations of new methods MUST use the "x-" prefix until such 633 time as the new method is registered by IANA. 635 Authentication method implementors are encouraged to provide adequate 636 information, via [MAIL] comments if necessary, to allow an MUA 637 developer to understand or relay ancilliary details of authentication 638 results. For example, if it might be of interest to relay what data 639 was used to perform an evaluation, such information could be relayed 640 as a comment in the header field, such as: 642 Authentication-Results: mx.example.com; 643 foo=pass bar.baz=blob (2 of 3 tests OK) 645 Experimental method identifiers MUST only be used within trust 646 domains that have explicitly consented to use them. These method 647 identifiers and the parameters associated with them are not 648 documented in RFCs. Therefore, they are subject to change at any 649 time and not suitable for production use. Any MTA or MUA intended 650 for production use SHOULD ignore or delete any Authentication-Results 651 header field that includes an experimental method identifier. 653 3. The 'iprev' Authentication Method 655 This section defines an additional authentication method called 656 "iprev". 658 In general, "iprev" is an attempt to verify that a client appears to 659 be valid based on some DNS queries. Upon receiving a session 660 initiation of some kind from a client, the IP address of the client 661 peer is queried for matching names (i.e. a number-to-name 662 translation, also known as a "reverse lookup" or a "PTR" record 663 query). Once that result is acquired, a lookup of each of the names 664 (i.e. a name-to-number translation, or an "A" record query) thus 665 retrieved is done. The response to this second check should result 666 in at least one mapping back to the client's IP address. 668 More algorithmically: If the client peer's IP address is A, the list 669 of names to which A maps (after a "PTR" query) is the set N, and the 670 union of IP addresses to which each member of N maps (after an "A" 671 query) is L, then this test is successful if A is an element of L. 673 Section 5.5 of [SPF] contains more detail about this process as well 674 as some discussion of possible denial-of-service attacks. [DNS-IP6] 675 discusses the format of this query for the IPv6 case. 677 A successful test using this algorithm constitutes a result of "pass" 678 since the domain in which the client's PTR claims it belongs has 679 confirmed that claim. A failure to match constitutes a "hardfail". 680 There is no case in which "softfail" or "neutral" can be returned. 681 The remaining "temperror" and "permerror" cases refer respectively to 682 temporary and permanent DNS query errors. 684 There is some contention regarding the wisdom and reliability of this 685 test. For example, in some regions it can be difficult for this test 686 ever to pass because the practise of arranging to match the forward 687 and reverse DNS is infrequently observed. Therefore, the actual 688 implementation details of how a verifier performs an "iprev" test are 689 not specified here. The verifier MAY report a successful or failed 690 "iprev" test at its discretion having done some kind of check of the 691 validity of the connection's identity using DNS. It is incumbent 692 upon an agent making use of the reported "iprev" result to understand 693 what exactly that particular verifier is attempting to report. 695 4. Adding The Header Field To A Message 697 This specification makes no attempt to evaluate the relative 698 strengths of various message authentication methods that may become 699 available. As such, the order of the presented authentication 700 methods and results MUST NOT be used either to imply or infer the 701 importance or strength of any given method over another. Instead, 702 the MUA must interpret the result of each method based on its 703 knowledge of what that method evaluates. 705 Each "method" MUST refer to an authentication method declared in the 706 IANA registry, or an extension method as defined in Section 2.5.2, 707 and each "result" MUST refer to a result code declared in the IANA 708 registry, or an extension result code as defined in Section 2.4.6. 709 See Section 7 for further information about the registered methods 710 and result codes. 712 An MTA compliant with this specification MUST add this header field 713 (after performing one or more message authentication tests) to 714 indicate at which host which the test was done, which test got 715 applied and what the result was. If an MTA applies more than one 716 such test, it MUST either add this header field once per test, or one 717 header field indicating all of the results. An MTA MUST NOT add a 718 result to an existing header. 720 An MTA MAY add this header field containing only the authentication 721 identifier portion to indicate explicitly that no message 722 authentication schemes were applied prior to delivery of this 723 message. 725 An MTA adding this header field must take steps to identify it as 726 legitimate to the MUAs that will ultimately consume its content. One 727 required process to do so is described in Section 5. Further 728 measures may be required in some environments. Some possible 729 solutions are enumerated in Section 8.1. This memo does not mandate 730 any specific solution to this issue as each environment has its own 731 facilities and limitations. 733 For MTAs that add this header field, adding header fields in order 734 (at the top) per [MAIL] section 3.6.7 is particularly important. 735 Furthermore, MTAs SHOULD use their own hostnames as the authserv-id 736 token as well as the same value in Received header fields. This 737 allows easy detection of header fields that can be trusted. 739 4.1. Header Position and Interpretation 741 In order to ensure non-ambiguous results and avoid the impact of 742 false header fields, an MUA SHOULD NOT interpret this header field 743 unless specifically instructed to do so by the user or administrator. 744 That is, this interpretation should not be "on by default". 745 Naturally then, users or administrators should not activate such a 746 feature unless they are certain the header field will be added by the 747 border MTA that accepts the mail that is ultimately read by the MUA, 748 and instances of the header field appearing to be from within the 749 trust domain but actually added by foreign MTAs will be removed 750 before delivery. 752 Furthermore, an MUA SHOULD NOT interpret this header field unless the 753 authentication identifier it bears appears to be one within its own 754 trust domain as configured by the user or administrator. 756 An MUA MUST ignore any result reported using a "result" not specified 757 in the result code registry, or a "ptype" not listed in the 758 corresponding registry for such values as defined in Section 7. 759 Moreover, an MUA MUST ignore a result indicated for any "method" it 760 does not support. 762 An MUA SHOULD NOT reveal these results to end users unless the 763 results are accompanied by, at a minimum, some associated reputation 764 data about the message that was authenticated. For example, an 765 attacker could register examp1e.com (note the digit "one") and send 766 signed mail to intended victims; a verifier would detect that the 767 signature was valid and report a "pass" even though it's clear the 768 domain name was intended to mislead. See Section 8.2 for further 769 discussion. 771 As stated in Section 2.1, this header field SHOULD be treated as 772 though it were a trace header field as defined in section 3.6.7 of 773 [MAIL], and hence MUST NOT be reordered and MUST be prepended to the 774 message, so that there is generally some indication upon delivery of 775 where in the chain of handling MTAs the message authentication was 776 done. 778 Further discussion of this can be found in Section 8 below. 780 4.2. Local Policy Enforcement 782 If a site's local policy is to consider a non-recoverable failure 783 result (e.g. "fail" for DKIM, "hardfail" for SPF or "discard" for 784 DKIM-ADSP) for any particular authentication method as justification 785 to reject the message completely, the border MTA SHOULD issue an 786 [SMTP] rejection response to the message rather than adding this 787 header with the failure result and allowing it to proceed toward 788 delivery. This is more desirable than allowing the message to reach 789 an internal host's MTA or spam filter, thus possibly generating a 790 local rejection such as a [DSN] to a forged originator. 792 The same MAY also be done for local policy decisions overriding the 793 results of the authentication methods (e.g. the "policy" result codes 794 described in Section 2.4. 796 Such rejections at the SMTP protocol level are not possible if local 797 policy is enforced at the MUA and not the MTA. Unfortunately, this 798 may be a common scenario. 800 5. Removing The Header Field 802 For security reasons, any MTA conforming to this specification MUST 803 delete any discovered instance of this header field which claims to 804 have been added within its trust boundary and did not come from 805 another trusted MTA. For example, an MTA (border or otherwise) for 806 example.com receiving a message MUST delete any instance of this 807 header field bearing an authentication identifier indicating the 808 header field was added within example.com prior to adding its own 809 header fields. This may mean each MTA will have to be equipped with 810 a list of internal MTAs known to be compliant (and hence 811 trustworthy). 813 Furthermore, a border MTA MAY elect simply to remove all instances of 814 this header field on mail crossing into its trust boundary. 816 A formal definition of "trust boundary" is deliberately not made 817 here. It is entirely possible that a border MTA for example.com 818 might explicitly trust authentication results asserted by upstream 819 host example.net even though they exist in completely disjoint 820 administrative boundaries. In that case the border MTA MAY elect not 821 to delete those results; moreover, the upstream host doing some 822 authentication work could apply a signing technology such as [DKIM] 823 on its own results to assure downstream hosts of their authenticity. 824 An example of this is provided in Appendix C. 826 Similarly, in the case of messages signed using [DKIM] or other 827 message signing methods that sign headers, this may invalidate one or 828 more signature on the message if they included the header field to be 829 removed at the time of signing. This behaviour can be desirable 830 since there's little value in validating the signature on a message 831 with forged headers. However, signing agents MAY therefore elect to 832 omit these header fields from signing to avoid this situation. 834 An MTA SHOULD remove any instance of this header bearing a version 835 (express or implied) that it does not support. However, an MTA MUST 836 remove such a header if the [SMTP] connection relaying the message is 837 from not a trusted internal MTA. 839 6. Conformance and Usage Requirements 841 An MTA or gateway conforms to this specification if it applies one or 842 more message authentication mechanisms and inserts a header field 843 corresponding to this specification after doing so and prior to 844 delivery (per Section 4) and removes apparently improper headers (per 845 Section 5). 847 MTAs that are relaying mail rather than delivering it, i.e. are not 848 part of an intended recipient's trust boundary, MAY perform message 849 authentication or even take actions based on the results found, but 850 SHOULD NOT add an "Authentication-Results" header field if relaying 851 (rather than rejecting or discarding at the gateway). Conversely, an 852 MTA doing local delivery and some form of message authentication MUST 853 add this header field prior to delivering the message in order to be 854 compliant. An exception to the former case is described in 855 Section 5. 857 A minimal implementation that does at least one message 858 authentication check will add the header field defined by this memo 859 prior to invoking local delivery procedures. 861 7. IANA Considerations 863 IANA is requested to register a new header field and to create a new 864 table as described below. 866 7.1. The Authentication-Results: header 868 Per [IANA-HEADERS], the "Authentication-Results:" header field is 869 added to the IANA Permanent Message Header Field Registry. The 870 following is the registration template: 872 Header field name: Authentication-Results 873 Applicable protocol: mail ([MAIL]) 874 Status: Standard 875 Author/Change controller: IETF 876 Specification document(s): [TBD] 877 Related information: 878 Requesting review of any proposed changes and additions to 879 this field is recommended. 881 7.2. Email Authentication Method Name Registry 883 Names of message authentication methods supported by this 884 specification must be registered with IANA, with the exception of 885 experimental names as described in Section 2.5.2. 887 New entries are assigned only for values that have been documented in 888 a published RFC that has IETF Review, per [IANA-CONSIDERATIONS]. 889 Each method must register a name, the specification that defines it, 890 one or more "ptype" values appropriate for use with that method, and 891 which "property" value(s) should be reported by that method. 893 The initial set of entries in this registry is as follows: 895 +------------+----------+--------+----------------+--------------------+ 896 | Method | Defined | ptype | property | value | 897 +------------+----------+--------+----------------+--------------------+ 898 | auth | RFC4954 | smtp | auth | AUTH parameter of | 899 | | | | | the SMTP MAIL | 900 | | | | | command | 901 +------------+----------+--------+----------------+--------------------+ 902 | dkim | RFC4871 | header | d | value of | 903 | | | | | signature "d" tag | 904 | | | +----------------+--------------------+ 905 | | | | i | value of | 906 | | | | | signature "i" tag | 907 +------------+----------+--------+----------------+--------------------+ 908 | dkim-adsp | [TBD] | header | from | value of From | 909 | | | | | header field | 910 | | | | | w/comments removed | 911 +------------+----------+--------+----------------+--------------------+ 912 | domainkeys | RFC4870 | header | from | value of From | 913 | | | | | header field | 914 | | | | | w/comments removed | 915 | | | +----------------+--------------------+ 916 | | | | sender | value of Sender | 917 | | | | | header field | 918 | | | | | w/comments removed | 919 +------------+----------+--------+----------------+--------------------+ 920 | iprev | this | policy | iprev | client IP address | 921 | | document | | | | 922 +------------+----------+--------+----------------+--------------------+ 923 | senderid | RFC4406 | header | name of header | value of header | 924 | | | | field used by | field used by PRA | 925 | | | | PRA | w/comments removed | 926 +------------+----------+--------+----------------+--------------------+ 927 | spf | RFC4408 | smtp | mailfrom | envelope sender | 928 | | +--------+----------------+--------------------+ 929 | | | smtp | helo | HELO/EHLO value | 930 +------------+----------+--------+----------------+--------------------+ 932 7.3. Email Authentication Result Name Registry 934 Names of message authentication result codes supported by this 935 specification must be registered with IANA, with the exception of 936 experimental codes as described in Section 2.4.6. 938 New entries are assigned only for result codes that have been 939 documented in a published RFC that has IETF Review, per 940 [IANA-CONSIDERATIONS]. Each code must register a name, the document 941 which establishes the registration, the authentication method(s) 942 which uses it, and either a definition of the semantics of its use or 943 a reference to the place where those semantics are defined. 945 The initial set of entries in this registry is as follows: 947 +-----------+----------+----------------+------------------------------+ 948 | Code | Defined | Auth Method(s) | Meaning | 949 +-----------+----------+----------------+------------------------------+ 950 | none | this | dkim | section 2.4.1 | 951 | | document | domainkeys | | 952 | | +----------------+------------------------------+ 953 | | | dkim-adsp | section 2.4.2 | 954 | | +----------------+------------------------------+ 955 | | | spf | section 2.4.3 | 956 | | | sender-id | | 957 | | +----------------+------------------------------+ 958 | | | auth | section 2.4.5 | 959 +-----------+----------+----------------+------------------------------+ 960 | pass | this | dkim | section 2.4.1 | 961 | | document | domainkeys | | 962 | | +----------------+------------------------------+ 963 | | | dkim-adsp | section 2.4.2 | 964 | | +----------------+------------------------------+ 965 | | | spf | section 2.4.3 | 966 | | | sender-id | | 967 | | +----------------+------------------------------+ 968 | | | iprev | section 2.4.4 | 969 | | +----------------+------------------------------+ 970 | | | auth | section 2.4.5 | 971 +-----------+----------+----------------+------------------------------+ 972 | fail | this | dkim | section 2.4.1 | 973 | | document | domainkeys | | 974 | | +----------------+------------------------------+ 975 | | | dkim-adsp | section 2.4.2 | 976 | | +----------------+------------------------------+ 977 | | | auth | section 2.4.5 | 978 +-----------+----------+----------------+------------------------------+ 979 | policy | this | dkim | section 2.4.1 | 980 | | document | domainkeys | | 981 +-----------+----------+----------------+------------------------------+ 982 | neutral | this | dkim | section 2.4.1 | 983 | | document | domainkeys | | 984 | | +----------------+------------------------------+ 985 | | | spf | section 2.4.3 | 986 | | | sender-id | | 987 +-----------+----------+----------------+------------------------------+ 988 | temperror | this | dkim | section 2.4.1 | 989 | | document | domainkeys | | 990 | | +----------------+------------------------------+ 991 | | | dkim-adsp | section 2.4.2 | 992 | | +----------------+------------------------------+ 993 | | | spf | section 2.4.3 | 994 | | | sender-id | | 995 | | +----------------+------------------------------+ 996 | | | iprev | section 2.4.4 | 997 | | +----------------+------------------------------+ 998 | | | auth | section 2.4.5 | 999 +-----------+----------+----------------+------------------------------+ 1000 | permerror | this | dkim | section 2.4.1 | 1001 | | document | domainkeys | | 1002 | | +----------------+------------------------------+ 1003 | | | dkim-adsp | section 2.4.2 | 1004 | | +----------------+------------------------------+ 1005 | | | spf | section 2.4.3 | 1006 | | | sender-id | | 1007 | | +----------------+------------------------------+ 1008 | | | iprev | section 2.4.4 | 1009 | | +----------------+------------------------------+ 1010 | | | auth | section 2.4.5 | 1011 +-----------+----------+----------------+------------------------------+ 1012 | nxdomain | this | dkim-adsp | section 2.4.2 | 1013 | | document | | | 1014 +-----------+----------+----------------+------------------------------+ 1015 | signed | this | dkim-adsp | section 2.4.2 | 1016 | | document | | | 1017 +-----------+----------+----------------+------------------------------+ 1018 | unknown | this | dkim-adsp | section 2.4.2 | 1019 | | document | | | 1020 +-----------+----------+----------------+------------------------------+ 1021 | discard | this | dkim-adsp | section 2.4.2 | 1022 | | document | | | 1023 +-----------+----------+----------------+------------------------------+ 1024 | hardfail | this | spf | section 2.4.3 | 1025 | | document | sender-id | | 1026 | | +----------------+------------------------------+ 1027 | | | iprev | section 2.4.4 | 1028 +-----------+----------+----------------+------------------------------+ 1029 | softfail | this | spf | section 2.4.3 | 1030 | | document | sender-id | | 1031 | | +----------------+------------------------------+ 1032 | | | iprev | section 2.4.4 | 1033 +-----------+----------+----------------+------------------------------+ 1034 8. Security Considerations 1036 The following security considerations apply when applying or 1037 processing the "Authentication-Results" header field: 1039 8.1. Forged Headers 1041 An MUA or filter that accesses a mailbox whose mail is handled by a 1042 non-conformant MTA, and understands Authentication-Results header 1043 fields, could potentially make false conclusions based on forged 1044 header fields. A malicious user or agent could forge a header field 1045 using the destination MX for a receiving domain as the authserv-id 1046 token in the value of the header field, and with the rest of the 1047 value claim that the message was properly authenticated. The non- 1048 conformant MTA would fail to strip the forged header field, and the 1049 MUA could inappropriately trust it. 1051 It is for this reason an MUA should not have processing of the 1052 "Authentication-Results" header field enabled by default; instead it 1053 should be ignored, at least for the purposes of enacting filtering 1054 decisions, unless specifically enabled by the user or administrator 1055 after verifying that the border MTA is compliant. It is acceptable 1056 to have an MUA aware of this specification, but have an explicit list 1057 of hostnames whose "Authentication-Results" header fields are 1058 trustworthy; however, this list should initially be empty. 1060 Proposed alternate solutions to this problem are nascent: 1062 1. Possibly the simplest is a digital signature protecting the 1063 header field, such as using [DKIM], that can be verified by an 1064 MUA using by a posted public key. Although one of the main 1065 purposes of this memo is to relieve the burden of doing message 1066 authentication work at the MUA, this only requires that the MUA 1067 learn a single authentication scheme even if a number of them are 1068 in use at the border MTA. 1070 2. Another would be a means to interrogate the MTA that added the 1071 header field to see if it is actually providing any message 1072 authentication services and saw the message in question, but this 1073 isn't especially palatable given the work required to craft and 1074 implement such a scheme. 1076 3. Yet another might be a method to interrogate the internal MTAs 1077 which apparently handled the message (based on Received: header 1078 fields) to determine whether any of them conform to Section 5 of 1079 this memo. This, too, has potentially high barriers-to-entry. 1081 4. Extensions to [IMAP], [SMTP] and [POP3] could be defined which 1082 allow an MUA or filtering agent to acquire the "authserv-id" in 1083 use within an administrative domain, thus allowing it to identify 1084 which Authentication-Results header fields it can trust. 1086 5. On the presumption that internal MTAs are fully compilant with 1087 section 4.4 of [MAIL], and the compliant internal MTAs are using 1088 their own hostnames as the "authserv-id" token, the header field 1089 proposed here will always appear adjacent to a Received: header 1090 bearing the same name. This can be used as a test for header 1091 field validity. 1093 Support for some of these is planned for future work. 1095 In any case, a mechanism needs to exist for an MUA or filter to 1096 verify that the host that appears to have added the header field (a) 1097 actually did so, and (b) is legitimately adding that header field for 1098 this delivery. Given the variety of messaging environments deployed 1099 today, consensus appears to be that specifying a particular mechanism 1100 for doing so is not appropriate for this memo. 1102 8.2. Misleading Results 1104 Until some form of service for querying the reputation of a sending 1105 agent is widely deployed, the existence of this header field 1106 indicating a "pass" does not render the message trustworthy. It is 1107 possible for an arriving piece of spam or other undesirable mail to 1108 pass checks by several of the methods enumerated above (e.g. a piece 1109 of spam signed using [DKIM] by the originator of the spam, which 1110 might be a spammer or a compromised system). In particular, this 1111 issue is not resolved by forged header removal discussed above. 1113 Hence, MUAs must take some care with use of this header even after 1114 possibly malicious headers are scrubbed. 1116 8.3. Other Protocols 1118 Mitigation of the forged header attack can also be accomplished by 1119 moving the authentication results data into meta-data associated with 1120 the message. In particular, an [SMTP] extension could be established 1121 which is used to communicate authentication results from the border 1122 MTA to intermediate and delivery MTAs; the latter of these could 1123 arrange to store the authentication results as meta-data retrieved 1124 and rendered along with the message by an [IMAP] client aware of a 1125 similar extension in that protocol. The delivery MTA would be told 1126 to trust data via this extension only from MTAs it trusts, and border 1127 MTAs would not accept data via this extension from any source. There 1128 is no vector in such an arrangement for forgery of authentication 1129 data by an outside agent. 1131 8.4. Header Position 1133 Despite the requirements of [MAIL], header fields can sometimes be 1134 reordered enroute by intermediate MTAs. The goal of requiring header 1135 field addition only at the top of a message is an acknowledgement 1136 that some MTAs do reorder header fields, but most do not. Thus, in 1137 the general case, there will be some indication of which MTAs (if 1138 any) handled the message after the addition of the header field 1139 defined here. 1141 8.5. Reverse IP Query Denial-Of-Service Attacks 1143 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 1144 for verifiers that attempt to DNS-based identity verification of 1145 arriving client connections. A verifier wishing to do this check and 1146 report this information SHOULD take care not to go to unbounded 1147 lengths to resolve "A" and "PTR" queries. MUAs or other filters 1148 making use of an "iprev" result specified by this memo SHOULD be 1149 aware of the algorithm used by the verifier reporting the result and 1150 thus be aware of its limitations. 1152 8.6. Mitigation of Backscatter 1154 Failing to follow the instructions of Section 4.2 can result in a 1155 denial-of-service attack caused by the generation of [DSN] messages 1156 (or equivalent) to addresses which did not send the messages being 1157 rejected. 1159 8.7. Internal MTA Lists 1161 Section 5 describes a procedure for scrubbing headers which may 1162 contain forged authentication results about a message. A compliant 1163 installation will have to include at each MTA a list of other MTAs 1164 known to be compliant and trustworthy. Failing to keep this list 1165 current as internal infrastructure changes may expose a domain to 1166 attack. 1168 8.8. Attacks Against Authentication Methods 1170 If an attack becomes known against an authentication method, clearly 1171 then the agent verifying that method can be fooled into thinking an 1172 inauthentic message is authentic, and thus the value of this header 1173 field can be misleading. It follows that any attack against the 1174 authentication methods supported by this document (and later 1175 amendments to it) is also a security consideration here. 1177 8.9. Intentionally Malformed Header Fields 1179 It is possible for an attacker to add an Authentication-Results: 1180 header field which is extraordinarily large or otherwise malformed in 1181 an attempt to discover or exploit weaknesses in header field parsing 1182 code. Implementors must thoroughly verify all such header fields 1183 received from MTAs and be robust against intentionally as well as 1184 unintentionally malformed header fields. 1186 8.10. Compromised Internal Hosts 1188 An internal MUA or MTA which has been compromised could generate mail 1189 with a forged From: header and a forged Authentication-Results: 1190 header which endorses it. Although it is clearly a larger concern to 1191 have compromised internal machines than it is to prove the value of 1192 this header, this risk can be mitigated by arranging that internal 1193 MTAs will remove this header field if it claims to have been added by 1194 a trusted border MTA (as described above) yet the [SMTP] connection 1195 is not coming from an internal machine known to be running an 1196 authorized MTA. However, in such a configuration, legitimate MTAs 1197 will have to add this header field when legitimate internal-only 1198 messages are generated. This is also covered in Section 5. 1200 9. References 1202 9.1. Normative References 1204 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1205 Specifications: ABNF", RFC 5234, January 2008. 1207 [IANA-HEADERS] 1208 Klyne, G., Nottingham, M., and J. Mogul, "Registration 1209 Procedures for Message Header Fields", RFC 3864, 1210 September 2004. 1212 [KEYWORDS] 1213 Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", RFC 2119, March 1997. 1216 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 1217 October 2008. 1219 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1220 Extensions (MIME) Part One: Format of Internet Message 1221 Bodies", RFC 2045, November 1996. 1223 9.2. Informative References 1225 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1226 for Authentication", RFC 4954, July 2007. 1228 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 1229 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 1230 Signatures", RFC 4871, May 2007. 1232 [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1233 "DNS Extensions to Support IP Version 6", RFC 3596, 1234 October 2003. 1236 [DOMAINKEYS] 1237 Delany, M., "Domain-based Email Authentication Using 1238 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 1239 May 2007. 1241 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1242 for Delivery Status Notifications", RFC 3464, 1243 January 2003. 1245 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 1246 Crocker, D., "Internet Mail Architecture", 1247 I-D draft-crocker-email-arch, May 2007. 1249 [I-D.DRAFT-IETF-DKIM-SSP] 1250 Allman, E., Delany, M., and J. Fenton, "DKIM Author 1251 Signing Practices", I-D draft-ietf-dkim-ssp, January 2008. 1253 [IANA-CONSIDERATIONS] 1254 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1255 IANA Considerations Section in RFCs", RFC 5226, May 2008. 1257 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 1258 4rev1", RFC 3501, March 2003. 1260 [POP3] Meyers, J. and M. Rose, "Post Office Protocol - Version 1261 3", RFC 1939, May 1996. 1263 [SENDERID] 1264 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 1265 RFC 4406, April 2006. 1267 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1268 October 2008. 1270 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 1271 for Authorizing Use of Domains in E-Mail, Version 1", 1272 RFC 4408, April 2006. 1274 Appendix A. Acknowledgements 1276 The author wishes to acknowledge the following for their review and 1277 constructive criticism of this proposal: Eric Allman, Dave Crocker, 1278 Mark Delany, Frank Ellermann, Jim Fenton, Philip Guenther, Tony 1279 Hansen, Paul Hoffman, Eliot Lear, John Levine, Miles Libbey, Charles 1280 Lindsey, Alexey Melnikov, S. Moonesamy, Juan Altmayer Pizzorno, 1281 Michael Thomas. 1283 Appendix B. Legacy MUAs 1285 Implementors of this proposal should be aware that many MUAs are 1286 unlikely to be retrofitted to support the new header field and its 1287 semantics. In the interests of convenience and quicker adaptation, a 1288 delivery MTA might want to consider adding things that are processed 1289 by existing MUAs in addition to the Authentication-Results header 1290 field. One suggestion is to include a Priority: header field, on 1291 messages that don't already have such a header field, containing a 1292 value that reflects the strength of the authentication that was 1293 accomplished, e.g. "low" for weak or no authentication, "normal" or 1294 "high" for good or strong authentication. 1296 Some modern MUAs can already filter based on the content of this 1297 header field. However, there is keen interest in having MUAs make 1298 some kind of graphical representation of this header field's meaning 1299 to end users. Until this capability is added, other interim means of 1300 conveying authentication results may be necessary while this proposal 1301 and its successors are adopted. 1303 Appendix C. Authentication-Results Examples 1305 This section presents some examples of the use of this header field 1306 to indicate authentication results. 1308 C.1. Trivial case; header field not present 1310 The trivial case: 1312 Received: from mail-router.example.com 1313 (mail-router.example.com [192.0.2.1]) 1314 by server.sendmail.com (8.11.6/8.11.6) 1315 with ESMTP id g1G0r1kA003489; 1316 Fri, Feb 15 2002 17:19:07 -0800 1317 From: sender@example.com 1318 Date: Fri, Feb 15 2002 16:54:30 -0800 1319 To: receiver@sendmail.com 1320 Message-Id: <12345.abc@example.com> 1321 Subject: here's a sample 1323 Hello! Goodbye! 1325 Example 1: Trivial case 1327 The "Authentication-Results" header field is completely absent. The 1328 MUA may make no conclusion about the validity of the message. This 1329 could be the case because the message authentication services were 1330 not available at the time of delivery, or no service is provided, or 1331 the MTA is not in compliance with this specification. 1333 C.2. Nearly-trivial case; service provided, but no authentication done 1335 A message that was delivered by an MTA that conforms to this 1336 specification but provides no actual message authentication service: 1338 Authentication-Results: mail-router.example.com; none 1339 Received: from mail-router.example.com 1340 (mail-router.example.com [192.0.2.1]) 1341 by server.sendmail.com (8.11.6/8.11.6) 1342 with ESMTP id g1G0r1kA003489; 1343 Fri, Feb 15 2002 17:19:07 -0800 1344 From: sender@example.com 1345 Date: Fri, Feb 15 2002 16:54:30 -0800 1346 To: receiver@sendmail.com 1347 Message-Id: <12345.abc@example.com> 1348 Subject: here's a sample 1350 Hello! Goodbye! 1352 Example 2: Header present but no authentication done 1354 The "Authentication-Results" header field is present, indicating that 1355 the delivering MTA (which is named in the value of the header field) 1356 conforms to this specification. The presence of "none" (and the 1357 absence of any method and result tokens) indicates that no message 1358 authentication was done. 1360 C.3. Service provided, authentication done 1362 A message that was delivered by an MTA that conforms to this 1363 specification and applied some message authentication: 1365 Authentication-Results: mail-router.example.com; 1366 spf=pass smtp.mailfrom=sender@example.net 1367 Received: from dialup-1-2-3-4.example.net 1368 (dialup-1-2-3-4.example.net [192.0.2.200]) 1369 by mail-router.example.com (8.11.6/8.11.6) 1370 with ESMTP id g1G0r1kA003489; 1371 Fri, Feb 15 2002 17:19:07 -0800 1372 From: sender@example.net 1373 Date: Fri, Feb 15 2002 16:54:30 -0800 1374 To: receiver@example.com 1375 Message-Id: <12345.abc@example.net> 1376 Subject: here's a sample 1378 Hello! Goodbye! 1380 Example 3: Header reporting results 1381 The "Authentication-Results" header field is present, indicating that 1382 the border MTA (which is identified in the value of the header field) 1383 conforms to this specification. Furthermore, the message was 1384 authenticated by that MTA via the method specified in [SPF]. The MUA 1385 could extract and relay this extra information if desired. 1387 C.4. Service provided, several authentications done, single MTA 1389 A message that was relayed inbound via a single MTA that conforms to 1390 this specification and applied three different message authentication 1391 checks: 1393 Authentication-Results: mail-router.example.com; 1394 auth=pass (cram-md5) smtp.auth=sender@example.com; 1395 spf=pass smtp.mailfrom=sender@example.com 1396 Authentication-Results: mail-router.example.com; 1397 sender-id=pass header.from=sender@example.com 1398 Received: from mail-router.example.com 1399 (mail-router.example.com [192.0.2.1]) 1400 by dialup-1-2-3-4.example.net (8.11.6/8.11.6) 1401 with ESMTP id g1G0r1kA003489; 1402 Fri, Feb 15 2002 17:19:07 -0800 1403 Date: Fri, Feb 15 2002 16:54:30 -0800 1404 To: receiver@example.net 1405 From: sender@example.com 1406 Message-Id: <12345.abc@example.com> 1407 Subject: here's a sample 1409 Hello! Goodbye! 1411 Example 4: Headers reporting results from one MTA 1413 The "Authentication-Results" header field is present, indicating the 1414 delivering MTA (which is identified in the value of the header field) 1415 conforms to this specification. Furthermore, the sender 1416 authenticated herself/himself to the MTA via a method specified in 1417 [AUTH], and both [SPF] and [SENDERID] checks were done and passed. 1418 The MUA could extract and relay this extra information if desired. 1420 Two "Authentication-Results" header fields are not required since the 1421 same host did all of the checking. The authenticating agent could 1422 have consolidated all the results into one header field. 1424 This example illustrates a scenario in which a remote user on a 1425 dialup connection (example.net) sends mail to a border MTA 1426 (example.com) using SMTP authentication to prove identity. The 1427 dialup provider has been explicitly authorized to relay mail as 1428 "example.com" resulting in passes by the SPF and SenderID checks. 1430 C.5. Service provided, several authentications done, different MTAs 1432 A message that was relayed inbound by two different MTAs that conform 1433 to this specification and applied multiple message authentication 1434 checks: 1436 Authentication-Results: auth-checker.example.com; 1437 sender-id=hardfail header.from=sender@example.com; 1438 dkim=pass (good signature) header.i=sender@example.com 1439 Received: from mail-router.example.com 1440 (mail-router.example.com [192.0.2.1]) 1441 by auth-checker.example.com (8.11.6/8.11.6) 1442 with ESMTP id i7PK0sH7021929; 1443 Fri, Feb 15 2002 17:19:22 -0800 1444 Authentication-Results: mail-router.example.com; 1445 auth=pass (cram-md5) smtp.auth=sender@example.com; 1446 spf=hardfail smtp.mailfrom=sender@example.com 1447 Received: from dialup-1-2-3-4.example.net 1448 (dialup-1-2-3-4.example.net [192.0.2.200]) 1449 by mail-router.example.com (8.11.6/8.11.6) 1450 with ESMTP id g1G0r1kA003489; 1451 Fri, Feb 15 2002 17:19:07 -0800 1452 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 1453 t=1188964191; c=simple/simple; 1454 h=From:Date:To:Message-Id:Subject; 1455 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 1456 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1457 From: sender@example.com 1458 Date: Fri, Feb 15 2002 16:54:30 -0800 1459 To: receiver@sendmail.com 1460 Message-Id: <12345.abc@example.com> 1461 Subject: here's a sample 1463 Hello! Goodbye! 1465 Example 5: Headers reporting results from multiple MTAs 1467 The "Authentication-Results" header field is present, indicating 1468 conformance to this specification. It is present twice because two 1469 different MTAs in the chain of delivery did authentication tests. 1470 The first, "mail-router.example.com" reports that [AUTH] and [SPF] 1471 were both used, and [AUTH] passed but [SPF] failed. In the [AUTH] 1472 case, additional data is provided in the comment field, which the MUA 1473 can choose to render if desired. 1475 The second MTA, identifying itself as "auth-checker.example.com", 1476 reports that it did a [SENDERID] test (which failed) and a [DKIM] 1477 test (which passed). Again, additional data about one of the tests 1478 is provided as a comment, which the MUA may choose to render. 1480 Since different hosts did the two sets of authentication checks, the 1481 header fields cannot be consolidated in this example. 1483 This example illustrates more typical transmission of mail into 1484 "example.com" from a user on a dialup connection "example.net". The 1485 user appears to be legitimate as he/she had a valid password allowing 1486 authentication at the border MTA using [AUTH]. The [SPF] and 1487 [SENDERID] tests failed since "example.com" has not granted 1488 "example.net" authority to relay mail on its behalf. However, the 1489 [DKIM] test passed because the sending user had a private key 1490 matching one of "example.com"'s published public keys and used it to 1491 sign the message. 1493 C.6. Service provided, multi-tiered authentication done 1495 A message that had authentication done at various stages, one of 1496 which was outside the receiving domain: 1498 Authentication-Results: chicago.example.com; 1499 dkim=pass (good signature) header.i=@mail-router.example.net; 1500 dkim=fail (bad signature) header.i=@newyork.example.com 1501 Received: from mail-router.example.net 1502 (mail-router.example.net [192.0.2.250]) 1503 by chicago.example.com (8.11.6/8.11.6) 1504 for 1505 with ESMTP id i7PK0sH7021929; 1506 Fri, Feb 15 2002 17:19:22 -0800 1507 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 1508 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 1509 h=From:Date:To:Message-Id:Subject:Authentication-Results; 1510 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 1511 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 1512 Authentication-Results: mail-router.example.net; 1513 dkim=pass (good signature) header.i=@newyork.example.com 1514 Received: from smtp.newyork.example.com 1515 (smtp.newyork.example.com [192.0.2.220]) 1516 by mail-router.example.net (8.11.6/8.11.6) 1517 with ESMTP id g1G0r1kA003489; 1518 Fri, Feb 15 2002 17:19:07 -0800 1519 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; 1520 t=1188964191; c=simple/simple; 1521 h=From:Date:To:Message-Id:Subject; 1522 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1523 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1524 From: sender@newyork.example.com 1525 Date: Fri, Feb 15 2002 16:54:30 -0800 1526 To: meetings@example.net 1527 Message-Id: <12345.abc@newyork.example.com> 1528 Subject: here's a sample 1530 Example 6: Headers reporting results from multiple MTAs in different 1531 domains 1533 In this example we see multi-tiered authentication with an extended 1534 trust boundary. 1536 The message was sent from someone at example.com's New York office 1537 (newyork.example.com) to a mailing list managed at an intermediary. 1538 The message was signed at the origin using [DKIM]. 1540 The message was sent to a mailing list service provider called 1541 example.net which is used by example.com. There meetings@example.net 1542 is expanded to a long list of recipients, one of which is at the 1543 Chicago office. In this example, we will assume that the trust 1544 boundary for chicago.example.com includes the mailing list server at 1545 example.net. 1547 The mailing list server there first authenticated the message and 1548 affixed an Authentication-Results: header field indicating such. It 1549 then altered the message by affixing some footer text to the body 1550 including some administrivia such as unsubscription instructions. 1551 Finally, the mailing list server affixes a second [DKIM] signature 1552 and begins distribution of the message. 1554 The border MTA for chicago.example.com explicitly trusts results from 1555 mail-router.example.net so that header is not removed. It performs 1556 evaluation of both signatures and determines that the first (most 1557 recent) is a "pass" but, because of the aforementioned modifications, 1558 the second is a "hardfail". However, the first signature included 1559 the Authentication-Results: header added at mail-router.example.net 1560 which validated the second signature. Thus, indirectly, it can be 1561 determined that the authentication claimed by both signatures are 1562 indeed valid. 1564 Appendix D. Public Discussion 1566 [REMOVE BEFORE PUBLICATION] 1568 Public discussion of this proposed specification is handled via the 1569 mail-vet-discuss@mipassoc.org mailing list. The list is open. 1570 Access to subscription forms and to list archives can be found at 1571 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 1573 Author's Address 1575 Murray S. Kucherawy 1576 Sendmail, Inc. 1577 6475 Christie Ave., Suite 350 1578 Emeryville, CA 94608 1579 US 1581 Phone: +1 510 594 5400 1582 Email: msk+ietf@sendmail.com 1584 Full Copyright Statement 1586 Copyright (C) The IETF Trust (2008). 1588 This document is subject to the rights, licenses and restrictions 1589 contained in BCP 78, and except as set forth therein, the authors 1590 retain all their rights. 1592 This document and the information contained herein are provided on an 1593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1600 Intellectual Property 1602 The IETF takes no position regarding the validity or scope of any 1603 Intellectual Property Rights or other rights that might be claimed to 1604 pertain to the implementation or use of the technology described in 1605 this document or the extent to which any license under such rights 1606 might or might not be available; nor does it represent that it has 1607 made any independent effort to identify any such rights. Information 1608 on the procedures with respect to rights in RFC documents can be 1609 found in BCP 78 and BCP 79. 1611 Copies of IPR disclosures made to the IETF Secretariat and any 1612 assurances of licenses to be made available, or the result of an 1613 attempt made to obtain a general license or permission for the use of 1614 such proprietary rights by implementers or users of this 1615 specification can be obtained from the IETF on-line IPR repository at 1616 http://www.ietf.org/ipr. 1618 The IETF invites any interested party to bring to its attention any 1619 copyrights, patents or patent applications, or other proprietary 1620 rights that may cover technology that may be required to implement 1621 this standard. Please address the information to the IETF at 1622 ietf-ipr@ietf.org. 1624 Acknowledgment 1626 Funding for the RFC Editor function is provided by the IETF 1627 Administrative Support Activity (IASA).