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 <fred@" (which
   eliminates false positives but may or may not match a field such as
   "From: fred@example.com") or with "FROM fred@" (which gives false
   positives for messages "From: alfred@example.com.uy").

   Matching a domain (without subdomains) can be done either with "FROM
   @example.com>" (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: <fred@example.com>" 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]