idnits 2.17.00 (12 Aug 2021) /tmp/idnits33030/draft-kucherawy-sender-auth-imap-01.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) == Missing Reference: 'X' is mentioned on line 274, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 5257 (ref. 'ANNOTATE') ** Obsolete normative reference: RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'AUTH') (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 4870 (ref. 'DOMAINKEYS') (Obsoleted by RFC 4871) == Outdated reference: draft-crocker-email-arch has been published as RFC 5598 == Outdated reference: A later version (-02) exists of draft-kucherawy-sender-auth-esmtp-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 4 errors (**), 0 flaws (~~), 4 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 IMAP Annotation for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-imap-01 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 application of the IMAP (Internet Message Access 47 Protocol) Annotations facility whereby a server can store and 48 retrieve meta-data about a message relating to message authentication 49 tests performed on the message and the corresponding results. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. SMTP Server or MDA Implementation . . . . . . . . . . . . . . 6 57 3. IMAP Server Implementation . . . . . . . . . . . . . . . . . . 7 58 4. IMAP Client Implementation . . . . . . . . . . . . . . . . . . 8 59 5. IMAP Annotation Format . . . . . . . . . . . . . . . . . . . . 9 60 6. Conformance and Usage Requirements . . . . . . . . . . . . . . 10 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 7.1. Annotation Registration . . . . . . . . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 8.1. Misleading Results . . . . . . . . . . . . . . . . . . . . 12 65 8.2. Attacks Against Authentication Methods . . . . . . . . . . 12 66 8.3. Intentionally Malformed Data . . . . . . . . . . . . . . . 12 67 8.4. Compromised Internal Hosts . . . . . . . . . . . . . . . . 12 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 72 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 16 73 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 17 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 1. Introduction 78 Electronic mail, though ubiquitous and highly useful, is also prone 79 to increasing abuse by parties that choose to exploit its lenient 80 design for nefarious purposes such as "spam" and "phishing." Abuse 81 of this leniency has become so widespread as to become an economic 82 problem. Several nascent methods of mitigating this problem such as 83 [SPF] and [DKIM] appear to make strides in this direction but are 84 themselves not sufficient. In many cases the results of attempts to 85 authenticate messages must be relayed to the user for final 86 disposition. 88 This memo defines a new annotation for [IMAP] using the IANA 89 Considerations found in [ANNOTATE] which is used to store and relay 90 message authentication results from upstream (e.g. "border") mail 91 servers to internal mail servers which ultimately do message 92 delivery. This information can then be used by delivery agents or 93 even the users themselves when determining whether or not the content 94 of such messages is trustworthy. 96 The message header defined in [AUTH-RESULTS] serves a similar purpose 97 and is simple to implement but has some moderate security 98 implications, so a more secure channel is required. In particular, 99 the header block of a message is generally unauthenticated and is 100 also typically relayed intact, meaning it is an obvious vector for 101 data forgery. Thus, trusting part of a message header to be secure 102 is a difficult problem. This method and that of 103 [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] establishes a much better 104 trust boundary and removes that obvious attack vector. 106 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 107 draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the 108 published e-mail authentication methods in common use. As various 109 methods emerge, it is necessary to prepare for their appearance and 110 encourage convergence in the area of interfacing these filters to 111 electroic mail servers. 113 1.1. Purpose 115 The IMAP annotation defined in this memo is expected to serve several 116 purposes: 118 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the 119 results of various message authentication checks being applied; 121 2. Provide a common location for the presentation of this data; 122 3. Create an extensible framework for specifying results from new 123 authentication methods as such emerge; 125 4. Convey the results of message authentication tests to later 126 filtering agents within the same "trust domain", as such agents 127 might apply more or less stringent checks based on message 128 authentication results; 130 5. Do all of this in a way not prone to forgery or 131 misinterpretation. 133 1.2. Definitions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC2119. 139 An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or 140 its extensions to format and transport a message. 142 An "MDA" is a Mail Delivery Agent (also sometimes referred to as 143 "LDA" or Local Delivery Agent), or any agent which has access to 144 receive a message from an MTA and write it into the receiving user's 145 "inbox". 147 An "MUA" is a Mail User Agent, or any software which retrieves and 148 displays messages on behalf of a user. 150 A "border MTA" is an MTA which acts as a gateway between the general 151 Internet and the users within an organizational boundary. 153 An "intermediate MTA" is an MTA which handles messages after a border 154 MTAs and before a delivery MTA. 156 +-----+ +-----+ +------------+ 157 | MUA |-->| MSA |-->| Border MTA | 158 +-----+ +-----+ +------------+ 159 | 160 | 161 V 162 +----------+ 163 | Internet | 164 +----------+ 165 | 166 | 167 V 168 +-----+ +-----+ +------------------+ +------------+ 169 | MUA |<==| MDA |<==| Intermediate MTA |<--| Border MTA | 170 +-----+ +-----+ +------------------+ +------------+ 172 Generally it is assumed that the work of applying message 173 authentication schemes takes place at a border MTA or a delivery MTA. 174 This specification is written with that assumption in mind. However, 175 there are some sites at which the entire mail infrastructure consists 176 of a single host. In such cases, such terms as "border MTA" and 177 "delivery MTA" may well apply to the same machine or even the very 178 same agent. It is also possible that message authentication could 179 take place on an intermediate MTA. Although this document doesn't 180 specifically include such cases, they are not meant to be excluded 181 from this specification. 183 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 184 system architecture. 186 In the figure shown above, the double-lines indicate the portions of 187 the transport of a message where this protocol would be applied. 188 Note also that the Local Mail Transfer Protocol [LMTP] could benefit 189 from a similar extension. 191 2. SMTP Server or MDA Implementation 193 Within the message flow depicted in Section 1.2, message 194 authentication methods can be applied in a variety of places, most 195 commonly the Border MTA, an Intermediate MTA, or the MDA. 197 Where the MDA does the message authentication, its results can be 198 attached, using the annotation defined defined by this memo, to the 199 message for later retrieval by an [IMAP] client. Where the message 200 authentication takes place at one of the earlier MTAs, some method of 201 carrying those results along each hop until mailbox injection at the 202 MDA must be applied. One such proposal can be found in 203 [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] and another in 204 [AUTH-RESULTS], but no specific method is required by this memo. 206 If [AUTH-RESULTS] is used, the header field MAY be deleted on 207 delivery as the data relayed there will be reported via the 208 annotation defined by this memo. 210 An MDA MAY choose to file messages other than in a recipient's 211 message inbox, or discard it altogether, when certain criteria, such 212 as failed authentications, are met. 214 3. IMAP Server Implementation 216 An [IMAP] server conforming to this specification MUST implement 217 [ANNOTATE] and MUST report these annotations to the client if they 218 are attached to the message(s) being requested. 220 The name and format of the annotation can be found in Section 5 and 221 Section 7. 223 The [IMAP] server itself may do the message authentication prior to 224 serving the message to the client, or the MDA or one of the upstream 225 MTAs may do so. In the former case, the authentication is being done 226 after delivery and the results could be different (e.g. signatures 227 could expire, sender policies could change, etc.). It is important 228 to be aware that the results of authentication methods evaluated by 229 this server could be notably different from those results returned 230 during the original transit of the message. At the time this memo 231 was prepared, all known methods were intended for evaluation at time 232 of delivery, not at the time the message is served to the end user. 234 4. IMAP Client Implementation 236 An [IMAP] client conforming to this specification will request the 237 "authresults" annotation when retrieving a message, and render those 238 results to users in some meaningful way. 240 The name and format of the annotation can be found in Section 5 and 241 Section 7. 243 5. IMAP Annotation Format 245 The content of the annotation, as defined using [ABNF], MUST be 246 formatted as follows: 248 authres = version ":" authserv-id ":" 1*resinfo 249 ; relays a single unit of authentication results 250 ; information 252 The "version", "authserv-id" and "resinfo" are as defined in Section 253 2.2 of [AUTH-RESULTS]. The "version" refers to the version of this 254 memo, not the version of [AUTH-RESULTS] referenced here. 256 6. Conformance and Usage Requirements 258 Section 2, Section 3 and Section 4 specify the only requirements for 259 conformance to this specification. 261 7. IANA Considerations 263 7.1. Annotation Registration 265 Per [IANA-CONSIDERATIONS], IANA is requested to register this new 266 IMAP annotation as per [ANNOTATE]. The template to be registered is 267 as follows: 269 To: iana@iana.org 270 Subject: IMAP Annotate Registration 272 Please register the following IMAP Annotate item: 274 [X] Entry [ ] Attribute 276 Name: /authresults 278 Description: Results of message authentication tests, as 279 specified in [AUTH-RESULTS] 281 Content-Type: text-plain; charset=us-ascii 283 Contact person: Murray S. Kucherawy 285 Contact email: msk@sendmail.com 287 8. Security Considerations 289 The following security considerations apply when applying or 290 processing the authresults IMAP annotation: 292 8.1. Misleading Results 294 Until some form of service for querying the reputation of a sending 295 agent is widely deployed, the existence of this annotation indicating 296 a "pass" does not render the message trustworthy. It is possible for 297 an arriving piece of spam or other undesirable mail to pass checks by 298 several of the methods enumerated above (e.g. a piece of spam signed 299 using [DKIM] by the originator of the spam, which might be a spammer 300 or a compromised system). 302 8.2. Attacks Against Authentication Methods 304 If an attack becomes known against an authentication method, clearly 305 then the agent verifying that method can be fooled into thinking an 306 inauthentic message is authentic, and thus the value of this 307 annotation can be misleading. It follows that any attack against the 308 authentication methods supported by this document (and later 309 amendments to it) is also a security consideration here. 311 8.3. Intentionally Malformed Data 313 It is possible for an attacker to include data in a message which is 314 extraordinarily large or otherwise malformed in an attempt to 315 discover or exploit weaknesses in parsing code. Implementors must 316 thoroughly verify all such data received from [IMAP] servers and be 317 robust against intentionally as well as unintentionally malformed 318 data. 320 8.4. Compromised Internal Hosts 322 An internal MUA or MTA which has been compromised could generate mail 323 with forged data, eventually generating an annotation which endorses 324 it. Although it is clearly a larger concern to have compromised 325 internal machines than it is to prove the value of this proposal, 326 this risk can be mitigated by arranging that internal MDAs not attach 327 this data if it claims to have been added by a trusted border MTA (as 328 described above) yet the [SMTP] connection is not coming from an 329 internal machine known to be running an authorized MTA. However, in 330 such a configuration, legitimate MDAs will have to add this data when 331 legitimate internal-only messages are generated. 333 9. References 335 9.1. Normative References 337 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 338 Specifications: ABNF", RFC 5234, January 2008. 340 [ANNOTATE] 341 Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", 342 RFC 5257, June 2008. 344 [AUTH-RESULTS] 345 Kucherawy, M., "Message Header Field for Indicating 346 Message Authentication Status", RFC 5451, April 2009. 348 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 349 4rev1", RFC 3501, March 2003. 351 9.2. Informative References 353 [AUTH] Myers, J., "SMTP Service Extension for Authentication", 354 RFC 2554, March 1999. 356 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 357 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 358 Signatures", RFC 4817, May 2007. 360 [DOMAINKEYS] 361 Delany, M., "Domain-based Email Authentication Using 362 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 363 May 2007. 365 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 366 Crocker, D., "Internet Mail Architecture", 367 I-D draft-crocker-email-arch, May 2007. 369 [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] 370 Kucherawy, M., "SMTP Service Extension for Indicating 371 Message Authentication Status", 372 I-D draft-kucherawy-sender-auth-esmtp-01, September 2008. 374 [IANA-CONSIDERATIONS] 375 Alvestrand, H. and T. Narten, "Guidelines for Writing an 376 IANA Considerations Section in RFCs", RFC 2434, 377 October 1998. 379 [LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033, 380 October 1996. 382 [SENDERID] 383 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 384 RFC 4406, April 2006. 386 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 387 April 2001. 389 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 390 for Authorizing Use of Domains in E-Mail, Version 1", 391 RFC 4408, April 2006. 393 Appendix A. Acknowledgements 395 The author wishes to acknowledge the following for their review and 396 constructive criticism of this proposal: (add names here) 398 Appendix B. Examples 400 This section presents some examples of the use of this IMAP 401 annotation. 403 (add examples here) 405 Appendix C. Public Discussion 407 [REMOVE BEFORE PUBLICATION] 409 Public discussion of this proposed specification is handled via the 410 mail-vet-discuss@mipassoc.org mailing list. The list is open. 411 Access to subscription forms and to list archives can be found at 412 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 414 Author's Address 416 Murray S. Kucherawy 417 Sendmail, Inc. 418 6475 Christie Ave., Suite 350 419 Emeryville, CA 94608 420 US 422 Phone: +1 510 594 5400 423 Email: msk+ietf@sendmail.com