idnits 2.17.00 (12 Aug 2021) /tmp/idnits38656/draft-kucherawy-sender-auth-esmtp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (April 17, 2009) is 4775 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) ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- 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 -- 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: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Sendmail, Inc. 4 Intended status: Standards Track April 17, 2009 5 Expires: October 19, 2009 7 SMTP Service Extension for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-esmtp-02 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 October 19, 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo defines an extension to the Simple Mail Transfer protocol 47 (SMTP) service whereby a server can indicate its ability to accept 48 and apply information regarding the efforts of upstream SMTP servers 49 to establish authenticity of the message via various authentication 50 methods. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Framework for the Authentication Results Extension . . . . . . 6 58 3. The Authentication-Results Service Extension . . . . . . . . . 7 59 3.1. Client Implementation . . . . . . . . . . . . . . . . . . 7 60 3.2. Server Implementation . . . . . . . . . . . . . . . . . . 7 61 3.3. MAIL Command Extension . . . . . . . . . . . . . . . . . . 8 62 3.4. Local Policy Enforcement . . . . . . . . . . . . . . . . . 8 63 4. Conformance and Usage Requirements . . . . . . . . . . . . . . 9 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 6.1. Trusting SMTP Clients . . . . . . . . . . . . . . . . . . 11 67 6.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 11 68 6.3. Reverse IP Query Denial-Of-Service Attacks . . . . . . . . 11 69 6.4. Mitigation of Backscatter . . . . . . . . . . . . . . . . 11 70 6.5. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 12 71 6.6. Attacks Against Authentication Methods . . . . . . . . . . 12 72 6.7. Intentionally Malformed Extension Parameters . . . . . . . 12 73 6.8. Compromised Internal Hosts . . . . . . . . . . . . . . . . 12 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 78 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 16 79 B.1. Single authentication result . . . . . . . . . . . . . . . 16 80 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 17 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 Electronic mail, though ubiquitous and highly useful, is also prone 86 to increasing abuse by parties that choose to exploit its lenient 87 design for nefarious purposes such as "spam" and "phishing." Abuse 88 of this leniency has become so widespread as to become an economic 89 problem. Several nascent methods of mitigating this problem such as 90 [DKIM] appear to make strides in this direction but are themselves 91 not sufficient. In many cases the results of attempts to 92 authenticate messages must be relayed to the user for final 93 disposition. 95 This memo defines a new SMTP extension which is used to relay message 96 authentication results from upstream (e.g. "border") mail servers to 97 internal mail servers which ultimately do message delivery. This 98 information can then be used by delivery agents or even the users 99 themselves when determining whether or not the content of such 100 messages is trustworthy. 102 The extension is defined using the methods specified in [SMTP] to 103 enable a server to announce that it is willing to accept this 104 information from upstream mail servers. Clients observing this 105 announcement can then elect to send that information with the message 106 when the latter is relayed. 108 The message header defined in [AUTH-RESULTS] serves a similar purpose 109 and is simple to implement but has some moderate security 110 implications, so a more secure channel is required. In particular, 111 the header block of a message is generally unauthenticated and is 112 also typically relayed intact, meaning it is an obvious vector for 113 data forgery. Thus, trusting part of a message header to be secure 114 is a difficult problem. This method establishes a much better trust 115 boundary and removes that obvious attack vector. 117 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 118 draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the 119 published e-mail authentication methods in common use. As various 120 methods emerge, it is necessary to prepare for their appearance and 121 encourage convergence in the area of interfacing these filters to 122 electroic mail servers. 124 1.1. Purpose 126 The SMTP extension defined in this memo is expected to serve several 127 purposes: 129 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the 130 results of various message authentication checks being applied; 132 2. Provide a common location for the presentation of this data; 134 3. Create an extensible framework for specifying results from new 135 authentication methods as such emerge; 137 4. Convey the results of message authentication tests to later 138 filtering agents within the same "trust domain", as such agents 139 might apply more or less stringent checks based on message 140 authentication results; 142 5. Do all of this in a way not prone to forgery or 143 misinterpretation. 145 1.2. Definitions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC2119. 151 An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or 152 its extensions to format and transport a message. 154 An "MDA" is a Mail Delivery Agent (also sometimes referred to as 155 "LDA" or Local Delivery Agent), or any agent which has access to 156 receive a message from an MTA and write it into the receiving user's 157 "inbox". 159 An "MUA" is a Mail User Agent, or any software which retrieves and 160 displays messages on behalf of a user. 162 A "border MTA" is an MTA which acts as a gateway between the general 163 Internet and the users within an organizational boundary. 165 A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which 166 actually enacts delivery of a message to a user's inbox or other 167 final delivery. 169 An "intermediate MTA" is an MTA which handles messages after a border 170 MTAs and before a delivery MTA. 172 +-----+ +-----+ +------------+ 173 | MUA |-->| MSA |-->| Border MTA | 174 +-----+ +-----+ +------------+ 175 | 176 | 177 V 178 +----------+ 179 | Internet | 180 +----------+ 181 | 182 | 183 V 184 +-----+ +-----+ +------------------+ +------------+ 185 | MUA |<--| MDA |<==| Intermediate MTA |<==| Border MTA | 186 +-----+ +-----+ +------------------+ +------------+ 188 Generally it is assumed that the work of applying message 189 authentication schemes takes place at a border MTA or a delivery MTA. 190 This specification is written with that assumption in mind. However, 191 there are some sites at which the entire mail infrastructure consists 192 of a single host. In such cases, such terms as "border MTA" and 193 "delivery MTA" may well apply to the same machine or even the very 194 same agent. It is also possible that message authentication could 195 take place on an intermediate MTA. Although this document doesn't 196 specifically include such cases, they are not meant to be excluded 197 from this specification. 199 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 200 system architecture. 202 In the figure shown above, the double-lines indicate the portions of 203 the transport of a message where this protocol would be applied. 204 Note also that the Local Mail Transfer Protocol [LMTP] could benefit 205 from a similar extension. 207 2. Framework for the Authentication Results Extension 209 The framework for the Authentication Results Extension is as follows: 211 1. The name of the SMTP service extension is "Authentication- 212 Results"; 214 2. The SMTP buffer length is extended by 256 bytes on servers 215 offering this service extension; 217 3. The EHLO keyword value associated with the extension is AUTHRES; 219 4. No parameter is used with the AUTHRES EHLO keyword; 221 5. An additional, optional parameter called AUTHRES is added to the 222 MAIL command; 224 6. No additional parameters are added to the RCPT command; 226 7. No additional SMTP verbs are defined by this extension; and 228 8. The next section specifies how support for the extension affects 229 the behaviour of a server and client SMTP session. 231 3. The Authentication-Results Service Extension 233 When a client wishes to relay message authentication information to a 234 downstream server, it first issues the EHLO command to the SMTP 235 server. If the SMTP server responds with code 250 to the EHLO 236 command and the response includes the EHLO keyword AUTHRES, then the 237 SMTP server has indicated that it can accept message authentication 238 information from the client. 240 3.1. Client Implementation 242 Once the client has confirmed that support exists for this extension 243 in the server to which it has connected, it may then elect to relay 244 its collected message authentication results as part of an extended 245 MAIL command. The format of the extended command is defined below. 247 More than one such result may be relayed in a single extended MAIL 248 command. 250 The authentication results relayed by this method need not have been 251 established by the agent acting as SMTP client. A client may elect 252 to forward, by way of this extension, authentication results relayed 253 to it about a message by previous clients. 255 3.2. Server Implementation 257 The SMTP server, upon receiving the EHLO command from the new client, 258 may decide to advertise its support of this extension by including 259 the AUTHRES keyword in its reply to the EHLO command. 261 Although software support for the extension may be present, the 262 server is not required to advertise such support if, for example, the 263 client making the connection is not one from which the server wishes 264 to trust such data. 266 Upon receipt of authentication results from the upstream MTA, the 267 receiving MTA may analyze the results and, if it decides the results 268 are not favourable, may elect to return an SMTP result code other 269 than the typical 250 success result to the extended MAIL command in 270 order to reject the message. 272 The authentication results ultimately received by an MDA may elect to 273 store that information for ultimate consumption by the end user, 274 either graphically or by way of filtering. This can be accomplished 275 using the message header field defined in [AUTH-RESULTS] or by means 276 of a new and as-yet-unspecified [IMAP] annotation via [ANNOTATE]. 278 3.3. MAIL Command Extension 280 The MAIL command is extended by this specification to allow the 281 relaying of authentication results. As there are several message 282 authentication schemes in common and growing use, the extension must 283 permit multiple results to be relayed for a given message. 285 The extension adds an AUTHRES parameter to the MAIL command. The 286 formal definition, using [ABNF]: 288 authres = 1*( "AUTHRES" "=" version ":" 289 authserv-id ":" 290 methodspec ":" 291 propspec ) 292 ; relays a single unit of authentication results 293 ; information 295 The "version", "authserv-id", "methodspec" and "propspec" are defined 296 in Section 2.2 of [AUTH-RESULTS]. The "version" refers to the 297 version of this memo in use, not the version of [AUTH-RESULTS] 298 referenced. 300 3.4. Local Policy Enforcement 302 If a site's local policy is to consider a non-recoverable failure 303 result (e.g. "fail" for DKIM, "hardfail" for SPF) for any particular 304 authentication method as justification to reject the message 305 completely, the border MTA SHOULD issue an [SMTP] rejection response 306 to the message rather than using this extension with the failure 307 result and allowing it to proceed toward delivery. This is more 308 desirable than allowing the message to reach an internal host's MTA 309 or spam filter, thus possibly generating a local rejection such as a 310 [DSN] to a forged originator. 312 The same MAY also be done for local policy decisions overriding the 313 results of the authentication methods (e.g. the "policy" result codes 314 described in Section 2.4 of [AUTH-RESULTS]. 316 Such rejections at the SMTP protocol level are not possible if local 317 policy is enforced at the MUA and not the MTA. Unfortunately, this 318 may be a common scenario. 320 4. Conformance and Usage Requirements 322 An agent acting as an SMTP server conforms to this specification if 323 it offers the AUTHRES extension to upstream MTAs from which it would 324 trust such data. Servers that advertise AUTHRES in their EHLOs MUST 325 expect the additional envelope information described in this draft. 327 A client wishing to use this extension MUST first see AUTHRES as part 328 of the EHLO response from a server. 330 5. IANA Considerations 332 Per [IANA-CONSIDERATIONS], IANA is requested to register this new 333 SMTP extension as described in Section 2. 335 6. Security Considerations 337 The following security considerations apply when applying or 338 processing the Authentication-Results SMTP service extension: 340 6.1. Trusting SMTP Clients 342 As described in Section 3.2, an MTA server implementing this 343 extension need not offer the AUTHRES service to an SMTP client if 344 it's sure it won't care what that client has to say about the 345 authenticity of the message. This establishes a "trust boundary" 346 within which SMTP clients are offered the extension; clients outside 347 that boundary are not offered the extension. 349 A client that tries to use the extension when it was not offered may 350 be deemed a security risk. 352 Although an obvious location of this boundary would be a published MX 353 for the recipient's domain, this is not always the case. Thus, 354 implementors are advised to default to a "trust no-one" posture and 355 have the trust boundary established explicitly by the user. 357 6.2. Misleading Results 359 Until some form of service for querying the reputation of a sending 360 agent is widely deployed, the existence of the AUTHRES extension 361 indicating a "pass" does not render the message trustworthy. It is 362 possible for an arriving piece of spam or other undesirable mail to 363 pass checks by several of the methods enumerated above (e.g. a piece 364 of spam signed using [DKIM] by the originator of the spam, which 365 might be a spammer or a compromised system). 367 6.3. Reverse IP Query Denial-Of-Service Attacks 369 Section 5.5 of [SPF] describes a DNS-based denial-of-service attack 370 for verifiers that attempt to DNS-based identity verification of 371 arriving client connections. A verifier wishing to do this check and 372 report this information SHOULD take care not to go to unbounded 373 lengths to resolve "A" and "PTR" queries. MUAs or other filters 374 making use of an "iprev" result specified by this memo SHOULD be 375 aware of the algorithm used by the verifier reporting the result and 376 thus be aware of its limitations. 378 6.4. Mitigation of Backscatter 380 Failing to follow the instructions of Section 3.4 can result in a 381 denial-of-service attack caused by the generation of [DSN] messages 382 (or equivalent) to addresses which did not send the messages being 383 rejected. 385 6.5. Internal MTA Lists 387 Section 3.2 mentions that the participating server need not offer 388 this extension to untrusted clients. A compliant installation will 389 have to include at each MTA a list of other MTAs known to be 390 compliant and trustworthy. Failing to keep this list current as 391 internal infrastructure changes may expose a domain to attack. 393 6.6. Attacks Against Authentication Methods 395 If an attack becomes known against an authentication method, clearly 396 then the agent verifying that method can be fooled into thinking an 397 inauthentic message is authentic, and thus the value of the AUTHRES 398 extension can be misleading. It follows that any attack against the 399 authentication methods supported by this document (and later 400 amendments to it) is also a security consideration here. 402 6.7. Intentionally Malformed Extension Parameters 404 It is possible for an attacker to add AUTHRES parameter which is 405 extraordinarily large or otherwise malformed in an attempt to 406 discover or exploit weaknesses in parsing code. Implementors must 407 thoroughly verify all such data received from MTAs and be robust 408 against intentionally as well as unintentionally malformed data. 410 6.8. Compromised Internal Hosts 412 An internal MUA or MTA which has been compromised could generate mail 413 with forged data, eventually generating an AUTHRES parameter which 414 endorses it. Although it is clearly a larger concern to have 415 compromised internal machines than it is to prove the value of this 416 extension, this risk can be mitigated by arranging that internal MTAs 417 not relay this data if it claims to have been added by a trusted 418 border MTA (as described above) yet the [SMTP] connection is not 419 coming from an internal machine known to be running an authorized 420 MTA. However, in such a configuration, legitimate MTAs will have to 421 add this data when legitimate internal-only messages are generated. 423 7. References 425 7.1. Normative References 427 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 428 Specifications: ABNF", RFC 5234, January 2008. 430 [AUTH-RESULTS] 431 Kucherawy, M., "Message Header Field for Indicating 432 Message Authentication Status", RFC 5451, April 2009. 434 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 435 April 2001. 437 7.2. Informative References 439 [ANNOTATE] 440 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", 441 RFC 5257, June 2008. 443 [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension 444 for Authentication", RFC 4954, July 2007. 446 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 447 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 448 Signatures", RFC 4871, May 2007. 450 [DOMAINKEYS] 451 Delany, M., "Domain-based Email Authentication Using 452 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 453 May 2007. 455 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format 456 for Delivery Status Notifications", RFC 3464, 457 January 2003. 459 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 460 Crocker, D., "Internet Mail Architecture", 461 I-D draft-crocker-email-arch, May 2007. 463 [IANA-CONSIDERATIONS] 464 Narten, T. and H. Alvestrand, "Guidelines for Writing an 465 IANA Considerations Section in RFCs", RFC 5226, 466 October 1998. 468 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 469 4rev1", RFC 3501, March 2003. 471 [LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033, 472 October 1996. 474 [SENDERID] 475 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 476 RFC 4406, April 2006. 478 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 479 for Authorizing Use of Domains in E-Mail, Version 1", 480 RFC 4408, April 2006. 482 Appendix A. Acknowledgements 484 The author wishes to acknowledge the following for their review and 485 constructive criticism of this proposal: (add names here) 487 Appendix B. Examples 489 This section presents some examples of the use of this protocol 490 extension to relay message authentication results. In these 491 examples, "C" indicates data sent by the SMTP client and "S" 492 indicates data sent by the SMTP server, and other annotations are 493 enclosed in square brackets. 495 B.1. Single authentication result 497 Relaying a single authentication result: 499 [connection established] 500 S: 220 inbox.example.com SMTP server ready 501 C: EHLO border.example.com 502 S: 250-inbox.example.com Hello root@foobar.example.net 503 S: 250-ENHANCEDSTATUSCODES 504 S: 250-SIZE 505 S: 250-DSN 506 S: 250-AUTHRES 507 S: 250 HELP 508 C: MAIL FROM: AUTHRES=dkim=pass:header.i=@example.net 509 S: 250 Sender OK 510 C: RCPT TO: 511 S: 250 Recipient OK 512 C: DATA 513 S: 354 Enter mail, end with "." on a line by itself 514 C: [message body] 515 C: . 516 S: 250 l9NE6WYF026506 Message received 517 C: QUIT 518 S: 221 Bye! 519 [connection closed] 521 Example 1: Relaying a single authentication result 523 In this example we see a border SMTP server relaying a message to an 524 internal SMTP server which will do local delivery for example.com's 525 users. The SMTP extension is advertised by the server (it trusts 526 this source as one likely to relay valid authentication data) and 527 used by the client. In this instance, the server validated the 528 message's authenticity using [DKIM] and determined that the 529 verification test passed. Also relayed is information about what 530 agent was responsible for affixing the signature. 532 Appendix C. Public Discussion 534 [REMOVE BEFORE PUBLICATION] 536 Public discussion of this proposed specification is handled via the 537 mail-vet-discuss@mipassoc.org mailing list. The list is open. 538 Access to subscription forms and to list archives can be found at 539 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 541 Author's Address 543 Murray S. Kucherawy 544 Sendmail, Inc. 545 6475 Christie Ave., Suite 350 546 Emeryville, CA 94608 547 US 549 Phone: +1 510 594 5400 550 Email: msk+ietf@sendmail.com