| Network Working Group | S. Lehmann |
| Internet-Draft | Strato AG |
| Updates: 1939 (if approved) | February 03, 2011 |
| Intended status: Standards Track | |
| Expires: August 07, 2011 |
The Post Office Protocol (POP3) LIST+ Extension
draft-lehmann-morg-pop3listplus-00
The Post Office Protocol - Version 3 (POP3) LIST+ Extension allows a POP3 client to instruct a POP3 server to send additional information with the LIST command response. This will help save message round trips and bandwidth overhead, especially on mailboxes containing several messages. On public POP3 servers, serving thousands of mailboxes, and being polled frequently, LIST+ will help reduce server load.
This document defines an extension to POP3, and updates RFC 1939.
Technical comments are solicited and should be addressed to Message Organizations Working Group's mailing list at morg@ietf.org and/or to the author. You can subscribe to that list at https://www.ietf.org/mailman/listinfo/morg.
Editorial comments should be addressed directly to the author.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 07, 2011.
Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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].
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance.
In this document, the term "client" refers to a host making use of the POP3 service, while the term "server" refers to a host which offers the POP3 service.
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
Although POP3 is intended as a download-and-delete protocol, clients can decide to leave messages on the server, resulting in mailboxes containing several messages. Observations on a public POP3 server have shown several POP3 clients using the LIST command, and, immediately followed, the UIDL command to get the Message Number, Message Size and Unique-ID, of all messages of a mailbox, to see if new messages have arrived. On large mailboxes, holding hundreds or thousands of mails, this causes serious resource consumption on the server, and will prolong the duration a mailbox is hold in locked state. This situation is even stressed by the fact that POP3 clients will usually poll a mailbox for new messages periodically in short intervals.
The LIST command has to scan through all messages of a mailbox to support the Message Number and the Message Size. The following UIDL command also has to scan through all messages of a mailbox to support the Message Number and the Unique-ID. The Message Number sent with the UIDL command, in this scenario, is already known to the client, and therefore, is a redundant information (as in example shown in Appendix Appendix A.1).
Using the LIST+ Extension, a server has to scan through the mailbox only for a single time, and can send the Message Number, Message Size and Unique-ID in a more compact form to the client (as shown in Appendix Appendix A.2.1).
The LIST+ Extension also offers the possibility to fetch other useful information with the LIST command quasi "on the fly", like the age of a message, or the number of days a message is unread. This may be helpful for clients to decide if a message has to be deleted automatically due to clients' message deleting policies. There is no need to read the mail headers to make this decision in this case.
This section defines the LIST+ Capability according to Section 9 of [RFC2449].
This section updates the syntax of the LIST command as well as the definition of the scan listing, both as defined in Section 5 of [RFC1939].
Formal syntax: LIST [msg] [flaglist]
The flaglist is a list of LIST+ Flags, separated by a single space. A LIST+ Flag always starts with "+" (it means "add the following information"), followed by the name of the flag. A flag name MUST start with a letter ("A-Z" or "a-z"). It is RECOMMENDED to keep flag names as short as possible.
A server, supporting LIST+, has to decide whether the first argument of the LIST command (if any) is a message number or a LIST+ Flag. If an argument starts with "+", and its second character is a letter, this parameter is to be considered as a LIST+ flag.
If the server receives a LIST+ flag which is not supported, the server MUST issue a "-ERR" response.
After the server has accepted a flaglist, it sends an extended scan listing for each requested message back to the client. The extended scan listing consists of: Appendix Appendix B for a formal syntax using ABNF.
See
The +UIDL Flag requests to add the Unique-ID of a message to the extended scan listing. The Unique-ID for a message is the same value as it would be sent by the UIDL command for this message. See [RFC1939], Section 7, "UIDL Command".
Servers not supporting the UIDL command MUST NOT advertise the +UIDL Flag in the LIST+ capability list.
The +AGE Flag requests to add the age of a message to the extended scan listing. The age is expressed in units of whole days since the message was delivered into the mailbox.
A message delivered yesterday (regardless of the time) has an age of one. A message delivered today has an age of zero. The value is presented as a decimal integer.
Servers unable to determine the age of a message in this way MUST NOT advertise the +AGE Flag in the LIST+ capability list.
The +UNREAD Flag requests to add the number of whole days, since the message was read for last time, to the extended scan listing.
A message read yesterday (regardless of the time) for last time has a value of one. A message read today has a value of zero. The value is presented as a decimal integer.
Servers unable to determine the number of whole days, since a message was read for last time, MUST NOT advertise the +UNREAD Flag in the LIST+ capability list.
The Parameter and Response Lengths, as defined in Section 4 of [RFC2449], are not affected by the LIST+ Extension Flags as defined in this document.
The already defined Parameter and Response Lengths are sufficient to hold complete LIST+ command and response lines as defined in this document, even if all possible flags are given together.
The LIST+ Extension itself is expandable. New LIST+ flags may be defined by future documents. If such a document defines a LIST+ flag whose value contains characters outside the range as defined in Section 3, it MUST declare how to encode the value, so it fulfills the requirements of this document.
Future documents defining new LIST+ flags MUST contain a statement whether the Parameter and Response Length, as defined in Section 4 of [RFC2449], are sufficient to hold lines with all possible flags/values, or not. If not, new values for parameter and response length MUST be defined.
The LIST+ Extension does not influence any security issues.
This document requests that IANA maintain a new keyword "LIST+" in the "POP3 Capabilities" registry.
This document requests that IANA maintain a new registry "POP3 LIST+ Flags".
This document requests that IANA maintain three new keywords, "+UIDL", "+AGE" and "+UNREAD", in the "POP3 LIST+ Flags" registry.
All mail program/server developers are encouraged to implement LIST+.
All carriers of POP3 servers holding mailboxes of many, frequently polling clients are encouraged to support LIST+.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC1939] | Myers, J.G. and M.T. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. |
| [RFC2449] | Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| [RFC4648] | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. |
S: +OK POP3 server ready C: CAPA S: +OK Capability list follows: S: EXPIRE 60 S: TOP S: UIDL S: . C: LIST S: +OK 3 messages, listing follows: S: 1 4536 S: 2 4422 S: 3 3828 S: . C: UIDL S: +OK 3 messages, listing follows: S: 1 7abcb6f4da22080e121f2824aef2be9a S: 2 577151e65ea4e62bb9b1c5830a818fe7 S: 3 2fe542ac6d1c29bb6a5161558f527e2e S: . C: QUIT S: +OK Closing connection
S: +OK POP3 server ready C: CAPA S: +OK Capability list follows: S: EXPIRE 60 S: TOP S: UIDL S: LIST+ +UIDL +AGE +UNREAD S: . C: LIST +UIDL S: +OK 3 messages, listing follows: S: 1 4536 7abcb6f4da22080e121f2824aef2be9a S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e S: . C: QUIT S: +OK Closing connection
S: +OK POP3 server ready C: CAPA S: +OK Capability list follows: S: EXPIRE 60 S: TOP S: UIDL S: LIST+ +UIDL +AGE +UNREAD S: . C: LIST 2 +UIDL S: +OK 2 4422 577151e65ea4e62bb9b1c5830a818fe7 C: QUIT S: +OK Closing connection
S: +OK POP3 server ready C: CAPA S: +OK Capability list follows: S: EXPIRE 60 S: TOP S: UIDL S: LIST+ +UIDL +AGE +UNREAD S: . C: LIST +UNREAD +UIDL +AGE S: +OK 3 messages, listing follows: S: 1 4536 9 7abcb6f4da22080e121f2824aef2be9a 32 S: 2 4422 1 577151e65ea4e62bb9b1c5830a818fe7 30 S: 3 3828 0 2fe542ac6d1c29bb6a5161558f527e2e 0 S: . C: QUIT S: +OK Closing connection
This section defines the LIST+ syntax using Augmented BNF (see [RFC5234] for details). The following rules are for clarification only, and are not intended to supersede the definition of the LIST command, as defined in [RFC1939].
listplus-req = "LIST" [SP msg-num] [SP listplus-flaglist] listplus-rsp = msg-num SP msg-size [*(SP listplus-value)] listplus-flaglist = listplus-flag [*(SP listplus-flag)] listplus-flag = "+" ALPHA [*listplus-char] listplus-value = 1*listplus-char listplus-char = %x21-7E msg-num = 1*DIGIT msg-size = 1*DIGIT