[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-gellens-pop3ext-02.txt

Thanks for your comments, Tom.

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

Thanks for the wording suggestions.

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

I don't think so; if a server supports CAPA it must also support
commands up to 255 octets; if it doesn't support CAPA, it can be
limited to 45.  SMTP extensions routinely increase the maximum length
of various commands.

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

The draft says that a server can have capabilities which are not
visible unless the CAPA command is issued in TRANSACTION state, as long
as this is stated in the description of the capability, that is, in the
RFC which documents it.  This way clients which don't care about any
auth-invisible caps don't have to issue two CAPA commands.  Clients
pretty much have to issue a CAPA in auth, so they can learn which auth
mechanisms the server supports.

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

This is an old debate (putting implementation info in the banner
exposes holes) and I really don't want to get into it.  I think the
draft allows server writers to come down on either side, and client
writers have the tools to cope.

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

OK.  SHOULD it is.

>>             S: IMPLEMENTATION "Shlemazle Plotz v302"
>Have I seen this before, Laurence ? :-)

Just my attempt at being cute.  A shlemazle server probably will plotz.

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

APOP is really an outdated mechanism.  SASL is the way to go, and that
uses CAPA tags.  I think APOP interoperates OK now; there is a way to
announce it that works.  I can't see client writers changing their ACAP
code to look at CAPA tags instead.

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

OK, I'm happy with a SHOULD here.

>Given recent discussion on the GRIP WG list (grip-wg@xxxxxx) 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 ?

(Do you mean the discussion a few weeks ago, or has there been new
stuff that I missed?)

I really don't want to get into XTND XMIT.  I don't think any mention
of it belongs in this draft.  Some ISPs love it, lots of IETF people
hate it.  The "X" mechanism allows it without taking a stand.