One document matched: draft-gellens-pop3ext-00.txt
POP3 Extension Mechanism
Status of this Memo:
This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet Draft, please check the
"1id-abstracts.txt" listing contained in the Internet Drafts shadow
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
This document will expire before the end of August 1998.
Distribution of this draft is unlimited.
Copyright Notice
Copyright (C) The Internet Society 1998. All Rights Reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . . . 2
3. General Command Grammar . . . . . . . . . . . . . . . . . . . . . 2
4. Parameter and Response Lengths. . . . . . . . . . . . . . . . . . 3
5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Initial Set of Capabilities . . . . . . . . . . . . . . . . . . . 4
6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.2. USER capability . . . . . . . . . . . . . . . . . . . . . . . . 5
6.3. SASL capability . . . . . . . . . . . . . . . . . . . . . . . . 5
6.4. LOGIN-DELAY capability. . . . . . . . . . . . . . . . . . . . . 5
6.5. PIPELINING capability . . . . . . . . . . . . . . . . . . . . . 6
6.6. LMOS capabilities . . . . . . . . . . . . . . . . . . . . . . . 7
Gellens, Newman, Lundblade [Page 1] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
6.7. UIDL capability . . . . . . . . . . . . . . . . . . . . . . . . 8
6.8. IMPLEMENTATION capability . . . . . . . . . . . . . . . . . . . 8
7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . . . . 9
8. Extended POP3 Response Codes. . . . . . . . . . . . . . . . . . . 9
8.1. Initial POP3 response codes . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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 features of POP3 is its
simplicity, it is not desirable to have a lot of extensions.
However, some extensions are necessary (such as ones that provide
improved security [POP-AUTH]), some are very desirable in certain
situations, and a means for discovering server behavior is needed.
This specification defines a mechanism to detect support for
optional commands, extensions, and unconditional server behavior.
Included is an initial set of currently implemented capabilities
which vary between server implementations. This also extends POP3
error messages so that machine parsable codes can be provided to
the client.
2. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
3. General Command Grammar
Gellens, Newman, Lundblade [Page 2] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
The general form of a POP3 command (described using [ABNF]):
command ::= keyword *(SP param) CRLF ;255 octets maximum
keyword ::= 3*4tchar
param ::= 1*tchar
tchar ::= %x30-39 / %x3C-7E ;"0"-"9" / "<"-"~"
4. Parameter and Response Lengths
This specification increases the length restrictions on command
parameters imposed by RFC 1939.
The maximum length of a command is increased from 45 characters (4
character command, single space, 40 character argument) to 255
octets.
The maximum length of a command response is 512 octets (including
the terminating CRLF).
5. The CAPA Command
The POP3 CAPA command returns a list of capabilities supported by
the POP3 server. It is available in both the AUTHORIZATION and
TRANSACTION states. Additional capabilities MAY become available
in the TRANSACTION state, but all capabilities listed in
AUTHORIZATION state MUST also be available.
Each capability may enable additional protocol commands, additional
parameters and responses for existing commands, or describe an
aspect of server behavior. These details are specified in the
description of the capability.
CAPA
Arguments:
none
Restrictions:
none
Discussion:
An -ERR response indicates the capability command is not
implemented and the client will have to probe for
capabilities as before.
An +OK response is followed by a list of capabilities, one
per line. Each capability name MAY be followed by an "="
sign and arguments. The capability list is terminated by a
line containing a termination octet (".") and a CRLF pair.
Gellens, Newman, Lundblade [Page 3] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
Possible Responses:
+OK -ERR
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL=CRAM-MD5 KERBEROS_V4
S: LOGIN-DELAY=900
S: PIPELINING
S: LMOS-NEW=60
S: LMOS-RETR=7
S: LMOS-TOP=20
S: UIDL
S: IMPLEMENTATION="Shlemazle Plotz v302"
S: .
6. Initial Set of Capabilities
This section defines an initial set of POP3 capabilities. These
include the optional POP3 commands, already published POP3
extensions, and behavior variations between POP3 servers which can
impact clients.
Note that there is no APOP capability, even though APOP is an
optional command in [POP3]. Clients discover server support of
APOP by the presence in the greeting banner of an initial challenge
enclosed in angle brackets ("<>"). Therefore, an APOP capability
would introduce two ways for a server to announce the same thing.
6.1. TOP capability
CAPA tag:
TOP
Arguments:
none
Added commands:
TOP
Standard commands affected:
none
Discussion:
The TOP capability indicates the optional TOP command is
available.
Gellens, Newman, Lundblade [Page 4] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
6.2. USER capability
CAPA tag:
USER
Arguments:
none
Added commands:
USER PASS
Standard commands affected:
none
Discussion:
The USER capability indicates that the USER and PASS commands
are supported, although they may not be available to all users.
6.3. SASL capability
CAPA tag:
SASL
Arguments:
Supported SASL mechanisms
Added commands:
AUTH
Standard commands affected:
none
Discussion:
The POP3 AUTHentication command [POP-AUTH] permits the use of
[SASL] authentication mechanisms with POP3. The SASL
capability indicates that the AUTH command is available and
that it supports an optional base64 encoded second argument for
an initial client response as described in the SASL
specification. The argument to the SASL capability is a space
separated list of SASL mechanisms which are supported.
6.4. LOGIN-DELAY capability
CAPA tag:
LOGIN-DELAY
Arguments:
minimum seconds between logins
Added commands:
Gellens, Newman, Lundblade [Page 5] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
none
Standard commands affected:
none
Discussion:
POP3 clients often login frequently to check for new mail.
Unfortunately, the process of creating a connection,
authenticating the user, and opening the user's maildrop can be
very resource intensive on the server. A number of deployed
POP3 servers try to reduce server load by requiring a delay
between logins. The LOGIN-DELAY capability includes an integer
argument which indicates the number of seconds after an "+OK"
response to a PASS, APOP, or AUTH command before another
authentication will be accepted. Clients which permit the user
to configure a mail check interval can use this capability to
determine the minimum permissible interval. Servers which
advertise LOGIN-DELAY SHOULD enforce it.
6.5. PIPELINING capability
CAPA tag:
PIPELINING
Arguments:
none
Added commands:
none
Standard commands affected:
none
Discussion:
The PIPELINING capability indicates the server is capable of
accepting multiple commands at a time; the client does not have
to wait for the response to a command before issuing a
subsequent command. If a server supports PIPELINING, it MUST
process each command in turn. If a client uses PIPELINING, it
MUST keep track of which commands it has outstanding, and match
server responses to commands in order. If either the client or
server uses blocking writes, it MUST not exceed the window size
of the underlying transport layer.
Some POP3 clients have an option to indicate the server
supports "Overlapped POP3 commands." This capability removes
the need to configure this at the client.
This is roughly synonymous with the ESMTP PIPELINING extension
[PIPELINING].
Gellens, Newman, Lundblade [Page 6] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
6.6. LMOS capabilities
CAPA tags:
LMOS-RETR LMOS-TOP LMOS-NEW
Arguments:
Retention period, in days, for a message category
Added commands:
none
Standard commands affected:
none
Discussion:
While POP3 allows clients to leave messages on the server, RFC
1939 warns about the problems that may arise from this, and
allows servers to delete messages based on site policy.
To quote from RFC 1939:
Sites are free to establish local policy regarding the
storage and retention of messages on the server, both
read and unread. For example, a site might delete
unread messages from the server after 60 days and
delete read messages after 7 days. Such message
deletions are outside the scope of the POP3 protocol
and are not considered a protocol violation. ...
It should be noted that enforcing site message deletion
policies may be confusing to the user community, since
their POP3 client may contain configuration options to
leave mail on the server which will not in fact be
supported by the server.
One special case of a site policy is that messages may
only be downloaded once from the server, and are
deleted after this has been accomplished. This could
be implemented in POP3 server software by the following
mechanism: "following a POP3 login by a client which
was ended by a QUIT, delete all messages downloaded
during the session with the RETR command". ... Servers
implementing a download-and-delete policy may also wish
to disable or limit the optional TOP command, since it
could be used as an alternate mechanism to download
entire messages.
The LMOS capabilities avoid the problems mentioned in RFC 1939,
by allowing the server to inform the client as to the policy in
effect. The argument to the LMOS capabilities indicate the
server retention period, in days, for messages in a specific
category. Zero indicates messages in that category are
Gellens, Newman, Lundblade [Page 7] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
immediately deleted. Each LMOS capability tag corresponds to a
message category, that is, messages which have been the targets
of a RETR or TOP command, or are new. The absence of a
particular LMOS capability tag (in the presence of other LMOS
capability tags) indicates no automatic deletion for messages
in that category.
Examples:
LMOS-NEW=30
LMOS-RETR=5
LMOS-TOP=10
LMOS-NEW=60
LMOS-RETR=60
LMOS-TOP=60
LMOS-RETR=45
The first example set indicates the server deletes new (unseen)
messages after 30 days, messages which have been downloaded
using RETR after 5 days, and messages which have been examined
using TOP after 10 days. The second example set specifies that
the server deletes all messages after 60 days. The third
example set indicates that messages downloaded using RETR are
automatically deleted after 45 days, but messages in other
categories are not automatically deleted.
6.7. UIDL capability
CAPA tag:
UIDL
Arguments:
none
Added commands:
UIDL
Standard commands affected:
none
Discussion:
The UIDL capability indicates that the UIDL command is
supported.
6.8. IMPLEMENTATION capability
CAPA tag:
Gellens, Newman, Lundblade [Page 8] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
IMPLEMENTATION
Arguments:
string giving server implementation information
Added commands:
none
Standard commands affected:
none
Discussion:
It is often useful to identify an implementation of a
particular server (for example, when logging). This is
commonly done in the welcome banner, but one must guess if a
string is an implementation ID or not.
The argument to the IMPLEMENTATION capability is a string,
enclosed in double-quote marks, identifying the server.
A server MAY include the implementation identification both in
the welcome banner and in the IMPLEMENTATION capability.
Clients MUST NOT modify their behavior based on the server
implementation. Instead the server and client should agree on
a private extension.
7. Future Extensions to POP3
Future extensions to POP3 are in general discouraged, as POP3's
usefulness lies in its simplicity. Extensions which offer
capabilities supplied by IMAP [IMAP4] or SMTP [SMTP] are strongly
discouraged and unlikely to be permitted on the IETF standards
track.
Clients MUST NOT require the presence of any extension for basic
functionality.
Capabilities beginning with the letter "X" are reserved for
experimental non-standard extensions and their use is discouraged.
All other capabilities MUST be defined in a standards track or IESG
approved experimental RFC.
8. Extended POP3 Response Codes
POP3 is currently only capable of indicating success or failure to
most commands. Unfortunately, clients often need to know more
information about the cause of a failure in order to gracefully
recover. This is especially important in response to a failed
login (there are widely-deployed clients which attempt to decode
Gellens, Newman, Lundblade [Page 9] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
the error text of a PASS command result, to try and distinguish
between "unable to get maildrop lock" and "bad login").
This specification amends the POP3 standard to permit an optional
response code, enclosed in square brackets, at the beginning of the
human readable text portion of a "+OK" or "-ERR" response. Clients
supporting this extension MAY remove any information enclosed in
square brackets prior to displaying human readable text to the
user. Immediately following the open square bracket "[" character
is a response code which is interpreted in a case-insensitive
fashion by the client.
The response code is hierarchical, with a "/" separating levels of
detail about the error. Clients MUST ignore unknown hierarchical
detail about the response code. This is important, as it could be
necessary to provide further detail for response codes in the
future. For example, ENCRYPT-NEEDED/TLS and ENCRYPT-NEEDED/SSH
might indicate a suggestion to use the TLS or SSH protocols
respectively for encryption.
Examples:
C: USER mrose
S: -ERR [ENCRYPT-NEEDED] You need to activate encryption
before logging in.
8.1. Initial POP3 response codes
This specification defines some POP3 response codes which can be
used to determine the reason for a failed login. Additional
response codes MAY be defined by publication in an RFC (standards
track or IESG approved experimental RFCs are preferred).
LOGIN-DELAY
This occurs on a -ERR response to an AUTH, USER, PASS or APOP
command and indicates that the user has logged in recently and
will not be allowed to login again until the login delay period
has expired.
PASS-EXPIRED
This occurs on a -ERR response to an AUTH, USER, PASS or APOP
command and indicates the user will not be allowed to login
until his password/passphrase is changed.
ENCRYPT-NEEDED
This occurs on an -ERR response to an AUTH, USER or APOP
command and indicates that the requested authentication
mechanism is only permitted underneath a security layer. The
client MAY take action to activate a security layer and repeat
the same AUTH, USER or APOP command or try an AUTH command with
a stronger mechanism. The client SHOULD record the fact that
Gellens, Newman, Lundblade [Page 10] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
encryption is needed for that user, server and mechanism
combination.
AUTH-TOO-WEAK
This occurs on an -ERR response to an AUTH, USER or APOP
command and indicates that the mechanism is too weak and is no
longer permitted for that user by site policy. This allows a
mechanism to be disabled on a per-user rather than a per-server
level which is useful if different users have different
security requirements or for transitioning from plaintext
USER/PASS to a more secure mechanism. The client SHOULD record
the fact that the user, server and mechanism combination is no
longer permitted.
TRANSITION-NEEDED
This occurs on an -ERR response to an AUTH or APOP command. It
indicates that the server has an entry for the specified user
in a legacy authentication database but does not yet have
credentials to offer the requested mechanism. A client which
receives this error code MAY do a one-time login using the
USER/PASS commands or another plaintext mechanism, which SHOULD
be protected by a privacy layer, to initialize credentials for
the requested mechanism.
IN-USE
This occurs on an -ERR response to an AUTH, APOP, or PASS
command. It indicates the authentication was successful, but
the user's maildrop is currently in use (probably by another
POP3 client).
9. IANA Considerations
This document requests that IANA maintain two new registries: POP3
capabilities and POP3 response codes.
New POP3 capabilities MUST be defined in a standards track or IESG
approved experimental RFC, and MUST NOT begin with the letter "X".
New POP3 capabilities MUST include the following information: CAPA
tag, arguments, added commands, standard commands affected, and
discussion. In addition, new limits for POP3 command and response
lengths may need to be included.
New POP3 response codes MUST be defined in an IESG-approved RFC.
Standards-track or experimental are preferred, but BCP or
informational are permitted.
New POP3 response codes MUST include the following information: the
complete response code, for which responses (+OK or -ERR) and
commands it is valid, and a definition of its meaning.
Gellens, Newman, Lundblade [Page 11] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
10. Security Considerations
A capability list can reveal information about the server's
authentication capabilities which can be used to determine if
certain attacks will be successful. However, allowing clients to
automatically detect availability of stronger mechanisms and alter
their configurations to use them can improve overall security at a
site.
The TRANSITION-NEEDED error code can be inserted by an active
attacker in an attempt to get the client to send the user's
password unencrypted. Clients SHOULD prompt the user to get
permission prior to transition. The additional error codes will
allow gradual upgrading of security services on a per-user basis so
they can improve overall security at a site.
11. References
[ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon
Internet Ltd., November 1997.
<ftp://ds.internic.net/rfc/rfc2234.txt>
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
<ftp://ds.internic.net/rfc/rfc2060.txt>
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt>
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", RFC 2197, Innosoft, September 1997.
<ftp://ds.internic.net/rfc/rfc2197.txt>
[POP3] Myers, J., Rose, M., "Post Office Protocol -- Version 3",
RFC 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
<ftp://ds.internic.net/rfc/rfc1939.txt>
[POP-AUTH] Myers, J., "POP3 AUTHentication command", work in
progress, Netscape Communications, November, 1997.
<ftp://ftp.isi.edu/internet-drafts/draft-myers-sasl-pop3-02.txt>
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, Netscape Communications, October 1997.
<ftp://ds.internic.net/rfc/rfc2222.txt>
[SMTP] Postel, J, "Simple Mail Transfer Protocol", RFC 821, STD 10,
Information Sciences Institute, August 1982.
<ftp://ds.internic.net/rfc/rfc821.txt>
Gellens, Newman, Lundblade [Page 12] Expires August 1998
Internet Draft POP3 Extension Mechanism February 1998
12. Full Copyright Statement
Copyright (C) The Internet Society 1998. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Authors' Addresses
Randall Gellens +1 619 651 5115
QUALCOMM, Incorporated +1 619 651 5334 (fax)
6455 Lusk Blvd. randy@qualcomm.com
San Diego, CA 92121-2779
USA
Chris Newman chris.newman@innosoft.com
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA
Laurence Lundblade +1 619 658 3584
QUALCOMM, Incorporated lgl@qualcomm.com
6455 Lusk Blvd.
San Diego, Ca, 92121-2779
USA
Gellens, Newman, Lundblade [Page 13] Expires August 1998
| PAFTECH AB 2003-2026 | 2026-04-24 07:31:55 |