Network Working Group Arnt Gulbrandsen Internet-Draft Oryx Mail Systems GmbH Intended Status: Proposed Standard January 28, 2009 The IMAP SEARCH=ADDRESS Extension draft-ietf-morg-address-search-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires in July 2009. Gulbrandsen Expires July 2009 [Page 1] Internet-draft January 2009 Abstract The SEARCH=ADDRESS extension extends IMAP search to operate on exact addresses and domains. Without this extension, one has to search on substrings and/or do the searching clientside. 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC5234]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. The five characters [...] means that something has been elided. 2. Overview This document defines a few extra search keys to search on email addresses qua addresses. Base IMAP allows only searching on substrings, so searching on addresses involves relying on server-specific behaviour, accepting false positives, accepting false negatives, or all three. This works acceptably when a human wants to find one or a few messages, but less well e.g. when the result set is too large for human inspection. Substantive comments regarding this draft may be sent to the morg@ietf.org list. Send nits to the author only, please. 3. New Search Keys This document defines three new search keys that operate on addresses in address fields. 3.1. Address Considerations In this document, an address is only localpart@domain. Display-name and route information is disregarded, so the address in this example is "nirmala@example.com": From: Nirmala Devi <@exemplo.com.br:nirmala@example.com> Gulbrandsen Expires July 2009 [Page 2] Internet-draft January 2009 Some email address parsers accept additional syntax, for example the so-called percent hack to support legacy systems. Such syntax should be treated similarly. Addresses without a domain (usually sent from the local system) are particularly common. These should be provided with an appropriate domain. Syntactically speaking, any string is valid as argument to these search keys. If the server can determine that the argument cannot match any messages (e.g. ADDRESS "@"), then... open issue. Two alternatives I think: 1. tagged NO with a BADADDRESS response code. 2. Carrying out the search, probably returning an empty search result, and returning a tagged OK with a BADADDRESS response code. (Open issue: I think the localpart ought to be considered case insensitive. All agree?_) Open issue: EAI addresses. 3.2. Address Fields The following fourteen address fields MUST be supported: From, To, Cc, Bcc, Reply-To, Return-Path, Sender, Resent-Bcc, Resent-Cc, Resent-From, Resent-Sender and Resent-To. The server MAY also support other fields. If it does, then it MUST parse them using the correct syntax for those fields. It is not permissible to parse unknown fields using the syntax for e.g. To, From, or Return-Path. All three search keys use either a client-specified list of address fields, or all supported fields. Open issue. What's better? 1. The client MUST NOT specify fields other than those specified above. The only way to test other address fields than the mandatory fourteen is to search all fields. 2. If the client specifies an unsupported field, the server MUST respond with NO. The server MUST check address fields in the top-level message, and MAY also check header fields in subsidiary message/rfc822 objects. (Open issue: SHOULD also? Or even MUST?) Gulbrandsen Expires July 2009 [Page 3] Internet-draft January 2009 3.3. The ADDRESS Search Key The ADDRESS search key matches a messages if one of its address fields refer to the specified address. This command finds all messages to/from/... fred@example.com, without matching messages to/from/... alfred@example.com or fred@example.com.au: C: a UID SEARCH ADDRESS ANY fred@example.com 3.4. The DOMAIN Search Key The DOMAIN search key matches a messages if one of its address fields refer to the specified domain. This command finds all messages sent by any example.com address, but does not match messages sent by asdf@example.com.au or hostmaster@ns1.example.com. C: a UID SEARCH DOMAIN ("From" "Sender" "Reply-To") example.com 3.5. The SUBDOMAIN Search Key The SUBDOMAIN search key matches a messages if one of its address fields refer to the specified domain, or a subdomain of it the specified domain. This command finds all messages sent by any example.com or *.example.com address, but not example.com.au: C: a UID SEARCH SUBDOMAIN (From Sender Reply-To) example.com 3.5. Client Fallbacks If an IMAP server does not support ADDRESS, the client may fall back to the FROM, TO, HEADER etc. search keys. The rest of this section uses only FROM, for simplicity. Matching a localpart can be done either with "FROM " (may miss some results) or "FROM @example.com" (may include false positives such as example.com.uy). Gulbrandsen Expires July 2009 [Page 4] Internet-draft January 2009 Matching a domain including subdomains has to be done using either "FROM example.com>" (which may miss results and may include false positives such as notexample.com) or "FROM example.com" (which may include false positives such as foo-return- x432y69-example.com@beispiel.de and leon@example.comintern.int). An IMAP client can achieve exact search results by choosing the overly inclusive search keys, downloading the search results and filtering out false positives. (This will however not find forwarded messages, since FROM and friends only look at the top-level header.) Note that some widely-used servers process address fields as part of parsing, so that e.g. "From: " may be rewritten as "From: fred@example.com" or the other way around. Some of these fallback searches may yield different results on different servers. 4. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "search-key", and "astring". [RFC5322] defines "field-name". Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "SEARCH=ADDRESS" search-key =/ ("ADDRESS" / "DOMAIN" / "SUBDOMAIN" ) [ SP "(" address-field *(SP address-field) ")" ] SP astring address-field = "From" / "To" / "Cc" / "Bcc" / "Reply-To" / "Return-Path" / "Sender" / "Resent-Bcc" / "Resent-Cc" / "Resent-From" / "Resent-Sender" / "Resent-To" / optional-address-field optional-address-field = field-name Open issue: field-name includes '')'. It is rather too inclusive. My preferred solution is to do away with optional-address-field. I can't think of any use cases that need it anyway. 5. Security Considerations Gulbrandsen Expires July 2009 [Page 5] Internet-draft January 2009 This document is believed not to have any security implications. 6. IANA Considerations The IANA is requested to add SEARCH=ADDRESS to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 7. Acknowledgements Go ahead, make me add you. 8. Normative References [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [RFC5322] Resnick, "Internet Message Format", RFC 5322, Qualcomm, October 2008. 9. Author's Address Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany Fax: +49 89 4502 9758 Email: arnt@oryx.com Gulbrandsen Expires July 2009 [Page 6] Internet-draft January 2009 (RFC Editor: Please delete everything after this point) Changes since -00 - ... Gulbrandsen Expires July 2009 [Page 7]