Subject: Re: comments on draft-gellens-pop3ext-02.txt
From: Laurence Lundblade <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: [email-masked]
Date: Fri, 20 Mar 1998 10:19:52 -0800 (PST)

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 ([email-masked]) 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,
>   Steve
> --
> -- Steve Atkins -- [email-masked]
> 
> 

Date: Thu, 19 Mar 1998 16:08:20 -0800
To: Steve Atkins <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Thu, 19 Mar 1998 18:48:57 -0500
To: [email-masked]
From: Steve Atkins <[email-masked]>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Sender: [email-masked]

Chris newman wrote:
>On Thu, 12 Mar 1998, Tom Killalea wrote:
>
>> Given recent discussion on the GRIP WG list ([email-masked]) 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,
  Steve
--
-- Steve Atkins -- [email-masked]

Date: Thu, 19 Mar 1998 13:54:20 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
To: Tom Killalea <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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 ([email-masked]) 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.

		- Chris

Date: Fri, 13 Mar 1998 12:00:56 -0800
To: Laurence Lundblade <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: LMOS
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Fri, 13 Mar 1998 10:37:07 -0800
To: [email-masked]
From: Laurence Lundblade <[email-masked]>
Subject: LMOS
Sender: [email-masked]

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

Date: Thu, 12 Mar 1998 17:40:28 -0800
To: Tom Killalea <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: [email-masked]
Sender: [email-masked]

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

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 ([email-masked]) 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.

Date: Thu, 12 Mar 1998 17:03:51 -0800
To: Tom Killalea <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: Randy Gellens <[email-masked]>, [email-masked]
Sender: [email-masked]

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.

>
>>    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 ? :-)

It wasn't me despite previous geographic associations :-)

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

Would be OK with me. I kind of agree with Chris who suggested taking it out
though. It's more code and complexity if the APOP options is advertised and
their's no cookie in the banner.  You have to parse the cookie before the
options anyway. I can't think of any reason to have the cookie without
advertising APOP.

LL

To: [email-masked]
cc: [email-masked]
From: Tom Killalea <[email-masked]>
Subject: comments on draft-gellens-pop3ext-02.txt
Date: Thu, 12 Mar 1998 13:08:56 -0800
Sender: [email-masked]

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 ([email-masked]) 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   (425) 649-7417    Verio Northwest
              [email-masked]