headers
Tom Killalea | 12 Mar 1998 22:08

comments on draft-gellens-pop3ext-02.txt

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
(Continue reading)

Permalink | Reply | 880 comments |
headers
Laurence Lundblade | 13 Mar 1998 02:03

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

At 1:08 PM -0800 3/12/98, Tom Killalea wrote:
>
>>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.

There's nothing that requires advertisement in the AUTHORIZATION state. How
about listing this as a security concern?  In the interest of simplicity, I
was hoping only clients looking for particular TRANSACTION state extensions
would have to do the second look up.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 13 Mar 1998 02:40

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Laurence Lundblade | 13 Mar 1998 19:37

LMOS

I'm having trouble designing sensible UI for the three values for new,
top'd and retr'd.  While it's likely that new and top'd will have the same
value, you still have to design sensible UI for when they're not.  So about
about LMOS-fully-fetched, and LMOS-not-fully-fetched?  Then require new and
top'd messages to be considered as not-fully-fetched.

LL
Permalink | Reply | 1 comment |
headers
Randall Gellens | 13 Mar 1998 21:00

Re: LMOS

At 10:37 AM -0800 3/13/98, Laurence Lundblade wrote:

>I'm having trouble designing sensible UI for the three values for new,
>top'd and retr'd.  While it's likely that new and top'd will have the same
>value, you still have to design sensible UI for when they're not.  So about
>about LMOS-fully-fetched, and LMOS-not-fully-fetched?  Then require new and
>top'd messages to be considered as not-fully-fetched.

But a TOPped message might really be fully-fetched.  At RFC 1939 warns,
if a server is implementing some form of message expiration, users
might start using TOP in lieu of of RETR as a way around the policy.
As a result, some sites might have a policy that treats TOP and RETR as
"seen".

The current draft recommends that there be only two categories of
messages, and allows TOP to be placed in either.  We could make this a
SHOULD.
Permalink | Reply | 0 comments |
headers
Chris Newman | 19 Mar 1998 22:54

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

On Thu, 12 Mar 1998, Tom Killalea wrote:
> >    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.

I disagree.  Having two ways to announce a capability introduces a "Silly
State" (see draft-newman-protocol-design-01.txt).  What does an APOP
client do if APOP is in the capability list, but there's no challenge in
the greeting banner?  The fact is it can't do anything because APOP isn't
supported.  That means looking for "APOP" in the capability list is
meaningless even if we did add it.  Human readability comes second to
correct design, and while human readability would dictate a complete list
of capabilities, correct design dictates otherwise.

> Given recent discussion on the GRIP WG list (grip-wg <at> uu.net) 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 ?

The draft says enough about this in the "Future Extensions to POP3"
section.  It makes it quite clear that extensions which duplicate
capabilities supplied by IMAP or SMTP are strongly discouraged.  Since
"XTND XMIT" duplicates SMTP functionality (defectively to bat), it
is therefore strongly discouraged and there's no way it could ever be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Atkins | 20 Mar 1998 00:48

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

Chris newman wrote:
>On Thu, 12 Mar 1998, Tom Killalea wrote:
>
>> Given recent discussion on the GRIP WG list (grip-wg <at> uu.net) 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 ?
>
>The draft says enough about this in the "Future Extensions to POP3"
>section.  It makes it quite clear that extensions which duplicate
>capabilities supplied by IMAP or SMTP are strongly discouraged.  Since
>"XTND XMIT" duplicates SMTP functionality (defectively to bat), it
>is therefore strongly discouraged and there's no way it could ever be
>standardized.

That's exactly why I'm lurking here...

It's quite clear (to me, anyway) that XTND XMIT doesn't duplicate
SMTP functionality (SMTP doesn't usually have sender authentication).

Whilst fixing SMTP to require authentication would be ideal that's
a lot less likely to happen than standardising a POP3 or IMAP send
extension. (Not neccesarily using XTND XMIT type protocol - as you say,
it's broken).

I get the impression that this has been 'discussed' at length somewhere
before - if someone could point me at an archive, or give me the gist
of the argument I'd appreciate it.

Cheers,
(Continue reading)

Permalink | Reply | 877 comments |
headers
Randall Gellens | 20 Mar 1998 01:08

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

At 6:48 PM -0500 3/19/98, Steve Atkins wrote:

>Whilst fixing SMTP to require authentication would be ideal that's
>a lot less likely to happen than standardising a POP3 or IMAP send
>extension. (Not neccesarily using XTND XMIT type protocol - as you say,
>it's broken).

I disagree; there is a proposal for an AUTH command in SMTP (using
SASL) and I haven't heard any objections to it.
Permalink | Reply | 0 comments |
headers
Laurence Lundblade | 20 Mar 1998 19:19

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

Not sure where this was discussed but you're right it was :-)

Whatever anyone thinks about XTND XMIT, I think discussion about it should
be decoupled from the POP extension mechanism.  The current draft
certainly does not absolutey preclude it or anything like it even though
it discourages it. Given that the language is only a suggestion that it
will be hard to get such a thing through the IESG I would hope this isn't
a problem.

LL

On Thu, 19 Mar 1998, Steve Atkins wrote:

> Chris newman wrote:
> >On Thu, 12 Mar 1998, Tom Killalea wrote:
> >
> >> Given recent discussion on the GRIP WG list (grip-wg <at> uu.net) 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 ?
> >
> >The draft says enough about this in the "Future Extensions to POP3"
> >section.  It makes it quite clear that extensions which duplicate
> >capabilities supplied by IMAP or SMTP are strongly discouraged.  Since
> >"XTND XMIT" duplicates SMTP functionality (defectively to bat), it
> >is therefore strongly discouraged and there's no way it could ever be
> >standardized.
> 
> That's exactly why I'm lurking here...
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane