idnits 2.17.1 draft-ietf-morg-address-search-00.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.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2009) is 5567 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 3501 (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard January 28, 2009 6 The IMAP SEARCH=ADDRESS Extension 7 draft-ietf-morg-address-search-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Copyright (c) 2009 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with respect 22 to this document. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft expires in July 2009. 41 Internet-draft January 2009 43 Abstract 45 The SEARCH=ADDRESS extension extends IMAP search to operate on exact 46 addresses and domains. Without this extension, one has to search on 47 substrings and/or do the searching clientside. 49 1. Conventions Used in This Document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Formal syntax is defined by [RFC5234]. 57 Example lines prefaced by "C:" are sent by the client and ones 58 prefaced by "S:" by the server. The five characters [...] means that 59 something has been elided. 61 2. Overview 63 This document defines a few extra search keys to search on email 64 addresses qua addresses. 66 Base IMAP allows only searching on substrings, so searching on 67 addresses involves relying on server-specific behaviour, accepting 68 false positives, accepting false negatives, or all three. This works 69 acceptably when a human wants to find one or a few messages, but less 70 well e.g. when the result set is too large for human inspection. 72 Substantive comments regarding this draft may be sent to the 73 morg@ietf.org list. Send nits to the author only, please. 75 3. New Search Keys 77 This document defines three new search keys that operate on addresses 78 in address fields. 80 3.1. Address Considerations 82 In this document, an address is only localpart@domain. Display-name 83 and route information is disregarded, so the address in this example 84 is "nirmala@example.com": 86 From: Nirmala Devi <@exemplo.com.br:nirmala@example.com> 88 Internet-draft January 2009 90 Some email address parsers accept additional syntax, for example the 91 so-called percent hack to support legacy systems. Such syntax should 92 be treated similarly. Addresses without a domain (usually sent from 93 the local system) are particularly common. These should be provided 94 with an appropriate domain. 96 Syntactically speaking, any string is valid as argument to these 97 search keys. If the server can determine that the argument cannot 98 match any messages (e.g. ADDRESS "@"), then... open issue. Two 99 alternatives I think: 1. tagged NO with a BADADDRESS response code. 100 2. Carrying out the search, probably returning an empty search 101 result, and returning a tagged OK with a BADADDRESS response code. 103 (Open issue: I think the localpart ought to be considered case 104 insensitive. All agree?_) 106 Open issue: EAI addresses. 108 3.2. Address Fields 110 The following fourteen address fields MUST be supported: From, To, 111 Cc, Bcc, Reply-To, Return-Path, Sender, Resent-Bcc, Resent-Cc, 112 Resent-From, Resent-Sender and Resent-To. 114 The server MAY also support other fields. If it does, then it MUST 115 parse them using the correct syntax for those fields. It is not 116 permissible to parse unknown fields using the syntax for e.g. To, 117 From, or Return-Path. 119 All three search keys use either a client-specified list of address 120 fields, or all supported fields. 122 Open issue. What's better? 124 1. The client MUST NOT specify fields other than those specified 125 above. The only way to test other address fields than the mandatory 126 fourteen is to search all fields. 128 2. If the client specifies an unsupported field, the server MUST 129 respond with NO. 131 The server MUST check address fields in the top-level message, and 132 MAY also check header fields in subsidiary message/rfc822 objects. 133 (Open issue: SHOULD also? Or even MUST?) 135 Internet-draft January 2009 137 3.3. The ADDRESS Search Key 139 The ADDRESS search key matches a messages if one of its address 140 fields refer to the specified address. This command finds all 141 messages to/from/... fred@example.com, without matching messages 142 to/from/... alfred@example.com or fred@example.com.au: 144 C: a UID SEARCH ADDRESS ANY fred@example.com 146 3.4. The DOMAIN Search Key 148 The DOMAIN search key matches a messages if one of its address fields 149 refer to the specified domain. 151 This command finds all messages sent by any example.com address, but 152 does not match messages sent by asdf@example.com.au or 153 hostmaster@ns1.example.com. 155 C: a UID SEARCH DOMAIN ("From" "Sender" "Reply-To") example.com 157 3.5. The SUBDOMAIN Search Key 159 The SUBDOMAIN search key matches a messages if one of its address 160 fields refer to the specified domain, or a subdomain of it the 161 specified domain. 163 This command finds all messages sent by any example.com or 164 *.example.com address, but not example.com.au: 166 C: a UID SEARCH SUBDOMAIN (From Sender Reply-To) example.com 168 3.5. Client Fallbacks 170 If an IMAP server does not support ADDRESS, the client may fall back 171 to the FROM, TO, HEADER etc. search keys. The rest of this section 172 uses only FROM, for simplicity. 174 Matching a localpart can be done either with "FROM " (may miss some results) or "FROM @example.com" (may 181 include false positives such as example.com.uy). 183 Internet-draft January 2009 185 Matching a domain including subdomains has to be done using either 186 "FROM example.com>" (which may miss results and may include false 187 positives such as notexample.com) or "FROM example.com" (which may 188 include false positives such as foo-return- 189 x432y69-example.com@beispiel.de and leon@example.comintern.int). 191 An IMAP client can achieve exact search results by choosing the 192 overly inclusive search keys, downloading the search results and 193 filtering out false positives. (This will however not find forwarded 194 messages, since FROM and friends only look at the top-level header.) 196 Note that some widely-used servers process address fields as part of 197 parsing, so that e.g. "From: " may be rewritten as 198 "From: fred@example.com" or the other way around. Some of these 199 fallback searches may yield different results on different servers. 201 4. Formal Syntax 203 The following syntax specification uses the Augmented Backus-Naur 204 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the 205 non-terminals "capability", "search-key", and "astring". [RFC5322] 206 defines "field-name". 208 Except as noted otherwise, all alphabetic characters are case- 209 insensitive. The use of upper or lower case characters to define 210 token strings is for editorial clarity only. Implementations MUST 211 accept these strings in a case-insensitive fashion. 213 capability =/ "SEARCH=ADDRESS" 215 search-key =/ ("ADDRESS" / "DOMAIN" / "SUBDOMAIN" ) 216 [ SP "(" address-field *(SP address-field) ")" ] 217 SP astring 219 address-field = "From" / "To" / "Cc" / "Bcc" / "Reply-To" / 220 "Return-Path" / "Sender" / "Resent-Bcc" / 221 "Resent-Cc" / "Resent-From" / "Resent-Sender" / 222 "Resent-To" / optional-address-field 224 optional-address-field = field-name 226 Open issue: field-name includes '')'. It is rather too inclusive. My 227 preferred solution is to do away with optional-address-field. I can't 228 think of any use cases that need it anyway. 230 5. Security Considerations 231 Internet-draft January 2009 233 This document is believed not to have any security implications. 235 6. IANA Considerations 237 The IANA is requested to add SEARCH=ADDRESS to the list of IMAP 238 extensions, http://www.iana.org/assignments/imap4-capabilities. 240 7. Acknowledgements 242 Go ahead, make me add you. 244 8. Normative References 246 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 247 Requirement Levels", RFC 2119, Harvard University, March 248 1997. 250 [RFC3501] Crispin, "Internet Message Access Protocol - Version 251 4rev1", RFC 3501, University of Washington, June 2003. 253 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 254 Specifications: ABNF", RFC 5234, January 2008. 256 [RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm, 257 October 2008. 259 9. Author's Address 261 Arnt Gulbrandsen 262 Oryx Mail Systems GmbH 263 Schweppermannstr. 8 264 D-81671 Muenchen 265 Germany 267 Fax: +49 89 4502 9758 269 Email: arnt@oryx.com 271 Internet-draft January 2009 273 (RFC Editor: Please delete everything after this point) 275 Changes since -00 277 - ...