comments on draft-gellens-pop3ext-02.txt

[Tom Killalea <[e-mail]>]

Congratulations on a very welcome draft.  Suggestions below.

>1.  Introduction
>
>    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.

    Because one of the most important features of POP3 is its
    simplicity, it is desirable that extensions be few in number.
    However, some extensions are necessary (such as ones that provide
    improved security [POP-AUTH]), while others are very desirable in 
    certain situations.  In either case a means for discovering server 
    behavior is needed.

>4.  Parameter and Response Lengths
>
>    This specification increases the length restrictions on commands
>    and 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.

I think such a fundamental change, if it's really needed, would belong in 
a revision of 1939 rather than in the extension mechanism document.

>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 the
>    AUTHORIZATION state MUST also be available.  If a capability
>    available in the TRANSACTION state is not available in the
>    AUTHORIZATION state, this MUST be stated in the capabilities
>    description.

I'm uncomfortable with the advertisement of TRANSACTION state-only 
capabilities while still in the AUTHORIZATION state.

My concern is that potential attackers could use the information gleaned
(including but not limited to IMPLEMENTATION information) to zone in on
servers running vulnerable implementations, servers that implement XTND 
XMIT and are potential UBE injection points, etc.

Maybe I'm paranoid (okay, I am), but I think it would be worthwhile to
have two distinct commands, say CAPA and CAPT, for advertising supported
capabilities available in the AUTHORIZATION and TRANSACTION states 
respectively.

>    Section 3 describes the CAPA response using [ABNF].  When a
>    capability response describes an optional command, the <capa-tag>
>    is usually, but is not required to be, identical to the command
>    keyword.  CAPA response tags are case-insensitive.

the <capa-tag> SHOULD be identical to the command 
keyword.

>             S: IMPLEMENTATION "Shlemazle Plotz v302"

Have I seen this before, Laurence ? :-)

>6.  Initial Set of Capabilities

>    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.

I think that having two ways to announce the same thing is a lesser sin
than returning an incomplete list with a dependence on another 
mechanism to complete the list.

>6.4.  LOGIN-DELAY capability
>
>    CAPA tag:
>        LOGIN-DELAY
>
>    Arguments:
>        minimum seconds between logins
>

>        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

to configure a mail check interval SHOULD use this capability to
determine the minimum permissible interval.  Servers which

>7.  Future Extensions to POP3
>
>    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.

Given recent discussion on the GRIP WG list ([e-mail]) arising
from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not*
a draft sanctioned by that group) does it make sense to explicitly 
discourage/deprecate XTND XMIT and indicate why it's a bad idea ?

>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
>    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 an "+OK" or "-ERR" response.

This is very welcome.

>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.

As I said above, full capabilities disclosure should be restricted until 
the TRANSACTION state is entered.

>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,

implementation

Cheers,
Tom.
--
Tom Killalea   [phone]    Verio Northwest
              [e-mail]