POP3 Extension Mechanism
RFC 2449
Document | Type |
RFC - Proposed Standard
(November 1998; No errata)
Updated by RFC 5034
Updates RFC 1939
Was draft-gellens-pop3ext (individual)
|
|
---|---|---|---|
Authors | Randall Gellens , Laurence Lundblade , Chris Newman | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2449 (Proposed Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group R. Gellens Request for Comments: 2449 Qualcomm Updates: 1939 C. Newman Category: Standards Track Innosoft L. Lundblade Qualcomm November 1998 POP3 Extension Mechanism Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. IESG Note This extension to the POP3 protocol is to be used by a server to express policy descisions taken by the server administrator. It is not an endorsement of implementations of further POP3 extensions generally. It is the general view that the POP3 protocol should stay simple, and for the simple purpose of downloading email from a mail server. If more complicated operations are needed, the IMAP protocol [RFC 2060] should be used. The first paragraph of section 7 should be read very carefully. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . 3 3. General Command and Response Grammar . . . . . . . . . . . . 3 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9 Gellens, et. al. Standards Track [Page 1] RFC 2449 POP3 Extension Mechanism November 1998 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 1. Introduction The Post Office Protocol version 3 [POP3] is very widely used. However, while it includes some optional commands (and some useful protocol extensions have been published), it lacks a mechanism for advertising support for these extensions or for behavior variations. Currently these optional features and extensions can only be detected by probing, if at all. This is at best inefficient, and possibly worse. As a result, some clients have manual configuration options for POP3 server capabilities. Because one of the most important characteristics of POP3 is its simplicity, it is desirable that extensions be few in number (see section 7). However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In addition, a means for discovering server behavior is needed. This memo updates RFC 1939 [POP3] to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. Included is an initial set of currently deployed capabilities which vary between server implementations, and several new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION). This document also extends POP3 error messages so that machine parsable codes can be provided to the client. AnShow full document text