From owner-ietf-pop3ext  Thu Mar 12 13:10:45 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA22995 for ietf-pop3ext-bks; Thu, 12 Mar 1998 13:10:45 -0800 (PST)
Received: from cypress.nwnet.net (cypress.nwnet.net [192.80.13.56]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA22991 for <ietf-pop3ext@imc.org>; Thu, 12 Mar 1998 13:10:43 -0800 (PST)
Received: from cypress.nwnet.net (localhost [127.0.0.1])
	by cypress.nwnet.net (970819888) with ESMTP id NAA20701;
	Thu, 12 Mar 1998 13:08:56 -0800 (PST)
Message-Id: <199803122108.NAA20701@cypress.nwnet.net>
To: randy@Qualcomm.Com
cc: ietf-pop3ext@imc.org
From: Tom Killalea <tomk@nw.verio.net>
Subject: comments on draft-gellens-pop3ext-02.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20698.889736935.1@cypress.nwnet.net>
Date: Thu, 12 Mar 1998 13:08:56 -0800
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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 (grip-wg@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 ?

>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
              tomk@nw.verio.net

From owner-ietf-pop3ext  Thu Mar 12 17:21:24 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA24971 for ietf-pop3ext-bks; Thu, 12 Mar 1998 17:21:24 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA24967 for <ietf-pop3ext@imc.org>; Thu, 12 Mar 1998 17:21:23 -0800 (PST)
Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA12763; Thu, 12 Mar 1998 17:20:24 -0800 (PST)
X-Sender: llundbla@nala.qualcomm.com
Message-Id: <v04010c58b12e3476a0ba@[129.46.137.174]>
In-Reply-To: <199803122108.NAA20701@cypress.nwnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 12 Mar 1998 17:03:51 -0800
To: Tom Killalea <tomk@nw.verio.net>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: Randy Gellens <rgellens@Qualcomm.Com>, ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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

From owner-ietf-pop3ext  Thu Mar 12 17:42:16 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA25105 for ietf-pop3ext-bks; Thu, 12 Mar 1998 17:42:16 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA25101 for <ietf-pop3ext@imc.org>; Thu, 12 Mar 1998 17:42:15 -0800 (PST)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA15064; Thu, 12 Mar 1998 17:41:17 -0800 (PST)
Message-Id: <v04010b54b12e3c2c6503@[129.46.136.131]>
In-Reply-To: <199803122108.NAA20701@cypress.nwnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora Pro 4.0 for Macintosh
Date: Thu, 12 Mar 1998 17:40:28 -0800
To: Tom Killalea <tomk@nw.verio.net>
From: Randall Gellens <Randy@Qualcomm.Com>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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 (grip-wg@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 ?

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

From owner-ietf-pop3ext  Fri Mar 13 10:48:47 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA15795 for ietf-pop3ext-bks; Fri, 13 Mar 1998 10:48:47 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA15791 for <ietf-pop3ext@imc.org>; Fri, 13 Mar 1998 10:48:46 -0800 (PST)
Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA25650 for <ietf-pop3ext@imc.org>; Fri, 13 Mar 1998 10:47:53 -0800 (PST)
X-Sender: llundbla@nala.qualcomm.com
Message-Id: <v04010c7cb12f2bf3c43f@[129.46.137.174]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 13 Mar 1998 10:37:07 -0800
To: ietf-pop3ext@imc.org
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: LMOS
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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


From owner-ietf-pop3ext  Fri Mar 13 12:19:41 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA16777 for ietf-pop3ext-bks; Fri, 13 Mar 1998 12:19:41 -0800 (PST)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA16773 for <ietf-pop3ext@imc.org>; Fri, 13 Mar 1998 12:19:40 -0800 (PST)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA27186; Fri, 13 Mar 1998 12:18:23 -0800 (PST)
Message-Id: <v04010b60b12f3fb56025@[129.46.136.131]>
In-Reply-To: <v04010c7cb12f2bf3c43f@[129.46.137.174]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora Pro 4.0 for Macintosh
Date: Fri, 13 Mar 1998 12:00:56 -0800
To: Laurence Lundblade <lgl@Qualcomm.Com>
From: Randall Gellens <Randy@Qualcomm.Com>
Subject: Re: LMOS
Cc: ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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.


From owner-ietf-pop3ext  Thu Mar 19 13:54:52 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA03473 for ietf-pop3ext-bks; Thu, 19 Mar 1998 13:54:52 -0800 (PST)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA03469 for <ietf-pop3ext@imc.org>; Thu, 19 Mar 1998 13:54:51 -0800 (PST)
Received: from elwood.innosoft.com ("port 50118"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-10 #8694)
 with SMTP id <01IUUPNQGWD28Y5DFR@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu,
 19 Mar 1998 13:52:32 PST
Date: Thu, 19 Mar 1998 13:54:20 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
In-reply-to: <199803122108.NAA20701@cypress.nwnet.net>
To: Tom Killalea <tomk@nw.verio.net>
Cc: ietf-pop3ext@imc.org
Message-id: <Pine.SOL.3.95.980319134754.9319C-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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

		- Chris



From owner-ietf-pop3ext  Thu Mar 19 15:51:30 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA04375 for ietf-pop3ext-bks; Thu, 19 Mar 1998 15:51:30 -0800 (PST)
Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA04371 for <ietf-pop3ext@imc.org>; Thu, 19 Mar 1998 15:51:29 -0800 (PST)
Received: from dangermouse (d4.dial-14.mbo.ma.ultra.net [146.115.100.68]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with SMTP id SAA09835 for <ietf-pop3ext@imc.org>; Thu, 19 Mar 1998 18:51:06 -0500 (EST)
Message-Id: <3.0.1.32.19980319184857.00b55e00@no3.superb.net>
X-Sender: blighty@no3.superb.net
X-Mailer: Windows Eudora Light Version 3.0.1 (32)
Date: Thu, 19 Mar 1998 18:48:57 -0500
To: ietf-pop3ext@imc.org
From: Steve Atkins <steve@blighty.com>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
In-Reply-To: <Pine.SOL.3.95.980319134754.9319C-100000@elwood.innosoft.co
 m>
References: <199803122108.NAA20701@cypress.nwnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Chris newman wrote:
>On Thu, 12 Mar 1998, Tom Killalea wrote:
>
>> Given recent discussion on the GRIP WG list (grip-wg@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,
  Steve
--
-- Steve Atkins -- steve@blighty.com


From owner-ietf-pop3ext  Thu Mar 19 16:17:28 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA04550 for ietf-pop3ext-bks; Thu, 19 Mar 1998 16:17:28 -0800 (PST)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA04546 for <ietf-pop3ext@imc.org>; Thu, 19 Mar 1998 16:17:27 -0800 (PST)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA29061; Thu, 19 Mar 1998 16:16:48 -0800 (PST)
Message-Id: <v04010c38b13763ccd748@[129.46.136.131]>
In-Reply-To: <3.0.1.32.19980319184857.00b55e00@no3.superb.net>
References: 
 <Pine.SOL.3.95.980319134754.9319C-100000@elwood.innosoft.co m>
 <199803122108.NAA20701@cypress.nwnet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora Pro 4.0 for Macintosh
Date: Thu, 19 Mar 1998 16:08:20 -0800
To: Steve Atkins <steve@blighty.com>
From: Randall Gellens <Randy@Qualcomm.Com>
Subject: Re: comments on draft-gellens-pop3ext-02.txt
Cc: ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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.

From owner-ietf-pop3ext  Fri Mar 20 10:20:14 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA24367 for ietf-pop3ext-bks; Fri, 20 Mar 1998 10:20:14 -0800 (PST)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA24363 for <ietf-pop3ext@imc.org>; Fri, 20 Mar 1998 10:20:13 -0800 (PST)
Received: from localhost (llundbla@localhost) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id KAA08967; Fri, 20 Mar 1998 10:19:52 -0800 (PST)
Date: Fri, 20 Mar 1998 10:19:52 -0800 (PST)
From: Laurence Lundblade <llundbla@Qualcomm.Com>
To: Steve Atkins <steve@blighty.com>
cc: ietf-pop3ext@imc.org
Subject: Re: comments on draft-gellens-pop3ext-02.txt
In-Reply-To: <3.0.1.32.19980319184857.00b55e00@no3.superb.net>
Message-ID: <Pine.GSO.3.95.980320101205.6954C-100000@nala.qualcomm.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

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@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,
>   Steve
> --
> -- Steve Atkins -- steve@blighty.com
> 
> 


From owner-ietf-pop3ext  Wed May 20 23:23:12 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA13766 for ietf-pop3ext-bks; Wed, 20 May 1998 23:23:12 -0700 (PDT)
Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.50.75]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA13754 for <ietf-pop3ext@imc.org>; Wed, 20 May 1998 23:23:11 -0700 (PDT)
From: postmaster@Blue_Server.equisys.com
Received: from Blue_Server.equisys.com (equisys.dircon.co.uk [194.112.44.68])
	by mailhost.dircon.co.uk (8.8.8/8.8.7) with ESMTP id HAA13068
	for <ietf-pop3ext@imc.org>; Thu, 21 May 1998 07:26:47 +0100 (BST)
Received: (from Administrator@localhost) by Blue_Server.equisys.com (8.6.9/8.6.9) id HAA00511; Thu, 21 May 1998 07:31:24 GMT
Date: Thu, 21 May 1998 07:31:24 GMT
Message-Id: <199805210731.HAA00511@Blue_Server.equisys.com>
To: ietf-pop3ext@imc.org
Subject:   Non Delivery Report
X-Mailer: MailNet 4.10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk



Your Message

    To:  Huw Charles
       postmaster
    Subject:  Re: Mail collection

Was not delivered for the following reasons:

    Delivery failed to MS:postmaster.
    Reason: 1 (transfer impossible)
    diagnostic:  0 (OR name (Email address) unrecognized).
    MSEXCH:MSExchangeMTA:MSX1:EMERALD.


Original message body follows...



POP received a message that does not appear to be for this site:

Return-Path: <owner-ietf-fax@imc.org>
Received: (from root@localhost)
 by popmail.dircon.co.uk (8.8.5/8.8.7) id AAA10561
 for equisys; Thu, 21 May 1998 00:04:58 +0100 (BST)
Received: from mail.proper.com (mail.proper.com [206.86.127.224])
 by popmail.dircon.co.uk (8.8.5/8.8.7) with ESMTP id AAA10533;
 Thu, 21 May 1998 00:04:56 +0100 (BST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id
PAA01746 for ietf-fax-bks; Wed, 20 May 1998 15:41:57 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by
mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA01742 for <IETF-FAX@imc.org>;
Wed, 20 May 1998 15:41:56 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id SAA29464; Wed, 20 May 1998 18:45:30 -0400 (EDT)
Message-Id: <199805202245.SAA29464@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: George.Pajari@Faximum.COM (George Pajari)
cc: moore@cs.utk.edu (Keith Moore), GK@ACM.ORG, IETF-FAX@imc.org,
        moore@cs.utk.edu
Subject: Re: Mail collection
reply-to: ietf-pop3ext@imc.org
In-reply-to: Your message of "Wed, 20 May 1998 15:34:24 PDT."
             <199805202234.PAA14190@eclipse.faximum.com>
Date: Wed, 20 May 1998 18:45:29 -0400
Sender: owner-ietf-fax@imc.org
Precedence: bulk
X-Envelope-To: <pcrawley@equisys.com>
X-UIDL: 0d29d9ca1ce1314426497086bc722de9

> According to Keith Moore:
> > If on the other hand, we can do some careful tweaking to POP to let
> > it support confirmation of transfer and relaying of envelope information, 

> > and if ISPs offer the tweaked version of POP rather than what we have
> > now, (which are admittedly big IFs) then we can keep mail reliability 
from
> > degrading.
>
> Obviously I'm missing something here but it would seem to me that the
> effort of persuading ISPs to offer tweaked POP (and to get MUA software
> developers to support tweaked POP, etc. down the food chain) would seem
> isomorphic to the problem of getting them all to use
> "SMTP+TURN+authentication"

maybe, maybe not.  It depends on whether "supporting tweaked POP"
is seen as adding significant overhead.  It also depends on whether
the ISP thinks it can make more money by refusing to support tweaked
POP, and offering an SMTP+TURN service.

> And if the two problems are equally difficult, isn't pushing
> "SMTP+TURN+authentication" better for all?

The question is whether the two are equally difficult.

> Of course, we might have to rename "SMTP+TURN+authentication" POP4
> (POPng anyone?) in order to fool the masses into adopting it. It seems the
> only difference between selling POP+tweaks vs. SMTP+TURN+etc. is the name,
> n'est-ce-pas?

it's probably easier to tweak POP to transfer mail reliably,
than to tweak SMTP to allow it to read messages.

Keith

p.s. since discussion of POP extensions probably doesn't belong on
this list, I suggest that further discussion of these issues be
held on ietf-pop3ext@imc.org


Received: (from Administrator@localhost) by Blue_Server.equisys.com
(8.6.9/8.6.9) id AAA00613 for postmaster; Thu, 21 May 1998 00:10:30 GMT
Date: Thu, 21 May 1998 00:10:30 GMT
From: ietf-pop3ext@imc.org
Message-Id: <199805210010.AAA00613@Blue_Server.equisys.com>
Apparently-To: postmaster


From owner-ietf-pop3ext  Wed May 20 23:23:21 1998
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id XAA13812 for ietf-pop3ext-bks; Wed, 20 May 1998 23:23:21 -0700 (PDT)
Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.50.75]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id XAA13802 for <ietf-pop3ext@imc.org>; Wed, 20 May 1998 23:23:20 -0700 (PDT)
From: postmaster@Blue_Server.equisys.com
Received: from Blue_Server.equisys.com (equisys.dircon.co.uk [194.112.44.68])
	by mailhost.dircon.co.uk (8.8.8/8.8.7) with ESMTP id HAA13076
	for <ietf-pop3ext@imc.org>; Thu, 21 May 1998 07:27:01 +0100 (BST)
Received: (from Administrator@localhost) by Blue_Server.equisys.com (8.6.9/8.6.9) id HAA00575; Thu, 21 May 1998 07:31:36 GMT
Date: Thu, 21 May 1998 07:31:36 GMT
Message-Id: <199805210731.HAA00575@Blue_Server.equisys.com>
To: ietf-pop3ext@imc.org
Subject:   Non Delivery Report
X-Mailer: MailNet 4.10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk



Your Message

    To:  Huw Charles
       postmaster
    Subject:  Re: Mail collection

Was not delivered for the following reasons:

    Delivery failed to MS:postmaster.
    Reason: 1 (transfer impossible)
    diagnostic:  0 (OR name (Email address) unrecognized).
    MSEXCH:MSExchangeMTA:MSX1:EMERALD.


Original message body follows...



POP received a message that does not appear to be for this site:

Return-Path: <owner-ietf-fax@imc.org>
Received: (from root@localhost)
 by popmail.dircon.co.uk (8.8.5/8.8.7) id AAA10571
 for equisys; Thu, 21 May 1998 00:04:59 +0100 (BST)
Received: from mail.proper.com (mail.proper.com [206.86.127.224])
 by popmail.dircon.co.uk (8.8.5/8.8.7) with ESMTP id AAA10533;
 Thu, 21 May 1998 00:04:56 +0100 (BST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id
PAA01746 for ietf-fax-bks; Wed, 20 May 1998 15:41:57 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by
mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA01742 for <IETF-FAX@imc.org>;
Wed, 20 May 1998 15:41:56 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id SAA29464; Wed, 20 May 1998 18:45:30 -0400 (EDT)
Message-Id: <199805202245.SAA29464@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: George.Pajari@Faximum.COM (George Pajari)
cc: moore@cs.utk.edu (Keith Moore), GK@ACM.ORG, IETF-FAX@imc.org,
        moore@cs.utk.edu
Subject: Re: Mail collection
reply-to: ietf-pop3ext@imc.org
In-reply-to: Your message of "Wed, 20 May 1998 15:34:24 PDT."
             <199805202234.PAA14190@eclipse.faximum.com>
Date: Wed, 20 May 1998 18:45:29 -0400
Sender: owner-ietf-fax@imc.org
Precedence: bulk
X-Envelope-To: <coswald@equisys.com>
X-UIDL: a65aa2b0c4b4a89ee79fe33ddf1de3cc
Status: U

> According to Keith Moore:
> > If on the other hand, we can do some careful tweaking to POP to let
> > it support confirmation of transfer and relaying of envelope information, 

> > and if ISPs offer the tweaked version of POP rather than what we have
> > now, (which are admittedly big IFs) then we can keep mail reliability 
from
> > degrading.
>
> Obviously I'm missing something here but it would seem to me that the
> effort of persuading ISPs to offer tweaked POP (and to get MUA software
> developers to support tweaked POP, etc. down the food chain) would seem
> isomorphic to the problem of getting them all to use
> "SMTP+TURN+authentication"

maybe, maybe not.  It depends on whether "supporting tweaked POP"
is seen as adding significant overhead.  It also depends on whether
the ISP thinks it can make more money by refusing to support tweaked
POP, and offering an SMTP+TURN service.

> And if the two problems are equally difficult, isn't pushing
> "SMTP+TURN+authentication" better for all?

The question is whether the two are equally difficult.

> Of course, we might have to rename "SMTP+TURN+authentication" POP4
> (POPng anyone?) in order to fool the masses into adopting it. It seems the
> only difference between selling POP+tweaks vs. SMTP+TURN+etc. is the name,
> n'est-ce-pas?

it's probably easier to tweak POP to transfer mail reliably,
than to tweak SMTP to allow it to read messages.

Keith

p.s. since discussion of POP extensions probably doesn't belong on
this list, I suggest that further discussion of these issues be
held on ietf-pop3ext@imc.org


Received: (from Administrator@localhost) by Blue_Server.equisys.com
(8.6.9/8.6.9) id AAA00584 for postmaster; Thu, 21 May 1998 00:10:43 GMT
Date: Thu, 21 May 1998 00:10:43 GMT
From: ietf-pop3ext@imc.org
Message-Id: <199805210010.AAA00584@Blue_Server.equisys.com>
Apparently-To: postmaster


From owner-ietf-pop3ext  Wed Jul  8 18:30:06 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id SAA19988
	for ietf-pop3ext-bks; Wed, 8 Jul 1998 18:30:06 -0700 (PDT)
Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19983;
	Wed, 8 Jul 1998 18:30:05 -0700 (PDT)
Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK)
          id VAA28119; Wed, 8 Jul 1998 21:30:01 -0400 (EDT)
Message-Id: <199807090130.VAA28119@spot.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1  BC 08 05 7F 42 81 7E 90 
To: drums@cs.utk.edu, ietf-smtp@imc.org
Subject: [Off Topic] Need review for POP3 extension mechanism
cc: moore@cs.utk.edu, ietf-pop3ext@imc.org
From: Keith Moore <moore@cs.utk.edu>
Reply-To: ietf-pop3ext@imc.org
Date: Wed, 08 Jul 1998 21:30:01 -0400
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

I apologize for an off-topic posting.  
Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists.

On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has commented on the document.  I am 
reluctant to recommend that IESG approve this document without more evidence 
of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient precision?

Should the document be standards track or should it be Informational or 
Experimental?

Should the extension mechanism be separated from (and perhaps a different 
status from) the extensions themselves?

If the document is approved for Proposed, should all of the proposed extensions 
be included?  Or should some of the extensions be moved to a separate 
Informational or Experimental?   Which ones?

In the absence of more community input, my recommendation would be to direct
the authors to remove all of the capabilities from this document, except those 
which are already defined in standards-track documents.  Additional capabilities 
could be defined in a separate experimental or informational RFC.

thanks!

Keith Moore
APPS co-AD

From owner-ietf-pop3ext  Thu Jul  9 09:26:44 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id JAA11100
	for ietf-pop3ext-bks; Thu, 9 Jul 1998 09:26:44 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11096
	for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 09:26:43 -0700 (PDT)
Received: from elwood.innosoft.com ("port 60319"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-11 #U3049)
 with SMTP id <01IZ6WZRRM2A99DOLZ@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu,
 9 Jul 1998 09:25:51 PDT
Date: Thu, 09 Jul 1998 09:27:08 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
In-reply-to: <199807090130.VAA28119@spot.cs.utk.edu>
To: ietf-pop3ext@imc.org
Cc: moore@cs.utk.edu
Message-id: <Pine.SOL.3.95.980709081237.9154G-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

As one of the co-authors, I'll take a crack at your questions.

On Wed, 8 Jul 1998, Keith Moore wrote:
> Should the document be adopted as is?  Does it need more wordsmithing?

I have already implemented to the current spec (including all the
capabilities listed).  The only wordsmithing issue that might be a concern
is how strongly the "lots of POP extensions are undesirable" wording
should be.  It's pretty strong now in that it gives cause to reject any
extension which overlaps SMTP or IMAP functionality.  I'd consider it a
friendly amendment to make that language even stronger (although I don't
know about my co-authors).

> Are all of these capabilities needed?

All of the capabilities (with the exception of IMPLEMENTATION) reflect
functional variations in deployed POP servers which would function more
smoothly if the client knew about them.  So I'd say yes. 

> Are all of the capabilities defined with sufficient precision?

I think so.  But a proposed standard doesn't have to be perfect.

> Should the document be standards track or should it be Informational or 
> Experimental?

I think there are three extensions which together demand the capability
command for POP3.  The SASL AUTH command (RFC 1734), the STARTTLS
extension (draft-newman-tls-imappop-04.txt), and the LANG command (which
hasn't been written yet).  I expect these to be popular down the road, and
the last thing I'd want is for POP clients to have to probe for each of
these individually.  Further, since I want draft-newman-tls-imappop-04.txt
on the standards track, I'll simply rip the POP STARTTLS extension out of
that spec if the POP extensions draft doesn't go standards track.  Then
the industry will use the "pops" port for POP+TLS. 

The IMAP WG determined that probing for commands just wasn't a good plan
after months of debate.  So we should either forbid the addition of any
extensions to POP3 (including those necessary for internationalization
and TLS support), or we bite the bullet and put this on the standards
track.

> In the absence of more community input, my recommendation would be to direct
> the authors to remove all of the capabilities from this document, except those 
> which are already defined in standards-track documents.  Additional capabilities 
> could be defined in a separate experimental or informational RFC.

Ok, here's what we have:

TOP    -- RFC 1939, section 7
USER   -- RFC 1939, section 7
UIDL   -- RFC 1939, section 7
SASL   -- RFC 1734
EXPIRE -- RFC 1939, section 8 second bullet item.  In fact just announcing
this standards-track server behavior potentially resolves the problem
described in paragraph containing "may be confusing to the user
community." 

The "LOGIN-DELAY" option is based on a feature deployed in several servers
including Innosoft's and CMU Cyrus pop3d which only allows people to login
with a certain frequency to improve server scaling and reduce load.
Unfortunately, this creates a user confusion scenario when setting the
"mail check interval" since the POP client can only discover the interval
by annoying trial & error.  Without such a feature, some users will check
mail every 5 seconds or worse.  Imagine trying to scale a POP server with
that setting on all the clients.

The "PIPELINING" option is identical to the one in ESMTP, for similar
reasons.  I think this is a no-brainer.

I could care less about the "IMPLEMENTATION" capability.

The only other issue is the response codes which I believe are justified
both because of their successful addition to IMAP2, and because clients
are currently doing strcmp()s on the returned error strings which is
neither internationalizable nor interoperable.

		- Chris



From owner-ietf-pop3ext  Thu Jul  9 12:27:44 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA12491
	for ietf-pop3ext-bks; Thu, 9 Jul 1998 12:27:44 -0700 (PDT)
Received: from gw3.octel.com (gw3.octel.com [148.147.1.15])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12487
	for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 12:27:42 -0700 (PDT)
Received: from curly.eng.octel.com (curly.eng.octel.com [148.147.200.26])
	by gw3.octel.com (8.8.8/8.8.8) with ESMTP id MAA09872
	for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 12:27:18 -0700 (PDT)
Received: from buzz.ons.octel.com (buzz.ons.octel.com [155.184.13.4]) by curly.eng.octel.com (8.6.12/8.6.12) with ESMTP id MAA03261 for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 12:27:17 -0700
Received: from ex-ons0.ons.octel.com (exchange [155.184.13.159])
	by buzz.ons.octel.com (8.8.6/8.8.6) with ESMTP id OAA15123
	for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 14:27:14 -0500 (CDT)
Received: by exchange.ons.octel.com with Internet Mail Service (5.5.1960.3)
	id <3MSRZHYD>; Thu, 9 Jul 1998 14:26:06 -0500
Message-ID: <6B57F36F4FF9D111B30A0008C7F4133711EC91@exdal1.ons.octel.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: ietf-pop3ext@imc.org
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Thu, 9 Jul 1998 14:24:39 -0500 
X-Mailer: Internet Mail Service (5.5.1960.3)
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

I will take a look at this document.  Maybe it was just me, but I do not
recall having seen the last call announcement....

Greg V.

> ----------
> From: 	Keith Moore[SMTP:moore@cs.utk.edu]
> Reply To: 	ietf-pop3ext@imc.org
> Sent: 	Wednesday, July 08, 1998 8:30 PM
> To: 	drums@cs.utk.edu; ietf-smtp@imc.org
> Cc: 	moore@cs.utk.edu; ietf-pop3ext@imc.org
> Subject: 	[Off Topic] Need review for POP3 extension mechanism
> 
> I apologize for an off-topic posting.  
> Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp
> lists.
> 
> On May 18, a Last Call was issued on for document
> draft-gellens-pop3ext-05.txt ,
> for Proposed Standard status.  Nobody has commented on the document.  I am
> 
> reluctant to recommend that IESG approve this document without more
> evidence 
> of support.
> 
> So I'm asking for more review...
> 
> Should the document be adopted as is?  Does it need more wordsmithing?
> Are all of these capabilities needed?
> Are all of the capabilities defined with sufficient precision?
> 
> Should the document be standards track or should it be Informational or 
> Experimental?
> 
> Should the extension mechanism be separated from (and perhaps a different 
> status from) the extensions themselves?
> 
> If the document is approved for Proposed, should all of the proposed
> extensions 
> be included?  Or should some of the extensions be moved to a separate 
> Informational or Experimental?   Which ones?
> 
> In the absence of more community input, my recommendation would be to
> direct
> the authors to remove all of the capabilities from this document, except
> those 
> which are already defined in standards-track documents.  Additional
> capabilities 
> could be defined in a separate experimental or informational RFC.
> 
> thanks!
> 
> Keith Moore
> APPS co-AD
> 

From owner-ietf-pop3ext  Thu Jul  9 14:51:42 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA13882
	for ietf-pop3ext-bks; Thu, 9 Jul 1998 14:51:42 -0700 (PDT)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13878
	for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 14:51:41 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA12736 for <ietf-pop3ext@imc.org>; Thu, 9 Jul 1998 14:51:12 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100e02b1cae7b4dc1d@[129.46.136.131]>
In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 9 Jul 1998 14:38:50 -0700
To: ietf-pop3ext@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

In addition to Chris' response, I'd like to add that the document has
gone through some pretty major feature cuts, in response to comments on
this list, in private email, and in person at IETF meetings.  Every
capability or response code which was at all controversial was removed,
and the language of the extension mechanism itself was tightened up a
lot.  Of course, I welcome additional review, but I think this is ready
for Proposed.

From owner-ietf-pop3ext  Fri Jul 10 04:05:17 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id EAA03520
	for ietf-pop3ext-bks; Fri, 10 Jul 1998 04:05:17 -0700 (PDT)
Received: from doom.qualcomm.co.nz (doom.qualcomm.co.nz [203.97.157.3])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA03515
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 04:05:05 -0700 (PDT)
Received: from [203.97.157.3] (203.97.157.3) by doom.qualcomm.co.nz with ESMTP
 (Eudora Internet Mail Server 2.2b1); Fri, 10 Jul 1998 23:05:20 +1200
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: glenn@mail.qualcomm.co.nz
Message-Id: <v04011707b1cb1353926e@[203.97.157.3]>
In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu>
Date: Fri, 10 Jul 1998 23:05:10 +1200
To: ietf-pop3ext@imc.org
From: Glenn Anderson <glenn@qualcomm.co.nz>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

>Should the document be adopted as is?  Does it need more wordsmithing?
>Are all of these capabilities needed?

I have already implemented CAPA to advertise support for TOP, USER,
PIPELINING, EXPIRE, and UIDL in the server I work on. SASL and LOGIN-DELAY
I can see the use of, but IMPLEMENTATION is not something I personally
would bother implementing.

>Are all of the capabilities defined with sufficient precision?

I found the definitions more than sufficient.

>Should the document be standards track or should it be Informational or
>Experimental?

I would like to see it be standards track. I think this is no longer
experimental, and would benefit from later review in the standards track
process, rather than being a one off informational.

>Should the extension mechanism be separated from (and perhaps a different
>status from) the extensions themselves?
>
>If the document is approved for Proposed, should all of the proposed
>extensions
>be included?  Or should some of the extensions be moved to a separate
>Informational or Experimental?   Which ones?
>
>In the absence of more community input, my recommendation would be to direct
>the authors to remove all of the capabilities from this document, except
>those
>which are already defined in standards-track documents.  Additional
>capabilities
>could be defined in a separate experimental or informational RFC.

The extensions that are not already defined in standards-track documents
(LOGIN-DELAY and PIPELINING with POP3) and the extended POP3 response codes
deal with current practices or issues, so I think they should stay.

Glenn.

From owner-ietf-pop3ext  Fri Jul 10 07:38:14 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id HAA05080
	for ietf-pop3ext-bks; Fri, 10 Jul 1998 07:38:14 -0700 (PDT)
Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05076
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 07:38:13 -0700 (PDT)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85])
	by rembrandt.esys.ca (2.0.4-beta-1/SMS 2.0.4-beta-1) with ESMTP id IAA13965
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 08:38:20 -0600
From: Steve Hole <steve@esys.ca>
Date: Fri, 10 Jul 1998 08:37:05 -0600
To: ietf-pop3ext@imc.org
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu>
References: <199807090130.VAA28119@spot.cs.utk.edu>
Message-ID: <SIMEON.980710083705.C@gallileo.esys.ca>
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Text/PLAIN; CHARSET=US-ASCII
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk


On Wed, 08 Jul 1998 21:30:01 -0400 Keith Moore <moore@cs.utk.edu> wrote:

> Does it need more wordsmithing?

The wording seems fine to me.   Certainly good enough to implement against. 

> Are all of these capabilities needed?

I think that you will find individuals that support all of the capabilities 
listed.    I personally believe that most of them are useful, and many of
them are indepensable.

> Are all of the capabilities defined with sufficient precision?

Yes.   There are some conflicts though I think.   See below on the discussion 
of the SASL support.
 
> Should the document be standards track or should it be Informational or 
> Experimental?

The document should definitely be standards track.   Certain "optional" 
features like UIDL and TOP are unwieldly at best to implement without a
capability probe.   Perhaps it is because we were an IMAP4 mailer first 
(and therefore use to CAPABILITY), I *really* found I missed it in POP3.

> Should the extension mechanism be separated from (and perhaps a different 
> status from) the extensions themselves?

I don't know.   If it wasn't late in the process, I would say that the 
capabilities that reflect policy behaviour should be outside; leaving only 
those capabilities that reflect optional standard behaviour ie. UIDL, TOP
etc.

I also wasn't sure about the AUTH capability support.    It is a wonderful 
idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
only thing is that John's update to the POP3 AUTH extension defines a probe
function (AUTH with no arguments) for listing available server mechanisms.   
Perhaps there has been discussion on removing the probe (going back to the
RFC1734 behaviour) in favour of the capability response.   As it is, there
are two ways to get the same information.   I'm not sure if this is a problem
or not.    I'm not sure which to implement in my client.

> If the document is approved for Proposed, should all of the proposed extensions 
> be included?  Or should some of the extensions be moved to a separate 
> Informational or Experimental?   Which ones?

Unless they are private extensions, they should not be informational.   It 
does not make sense to me that you would even do an informational document
for an extension that you expect to get interoperability between multiple 
implementors on.   It would be wise to set the policy right up front that 
extensions go on the standards track, at least as experimental.   They can
always be punted later if nobody finds them interesting enough to implement 
and deploy.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:Steve.Hole@esys.ca  
Phone:403-424-4922


From owner-ietf-pop3ext  Fri Jul 10 12:56:19 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA07242
	for ietf-pop3ext-bks; Fri, 10 Jul 1998 12:56:19 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07238
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 12:56:18 -0700 (PDT)
Received: from elwood.innosoft.com ("port 35558"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-11 #U3049)
 with SMTP id <01IZ8IMUAEE099DSO5@INNOSOFT.COM> for ietf-pop3ext@imc.org; Fri,
 10 Jul 1998 12:56:09 PDT
Date: Fri, 10 Jul 1998 12:57:26 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
In-reply-to: <SIMEON.980710083705.C@gallileo.esys.ca>
To: Steve Hole <steve@esys.ca>
Cc: ietf-pop3ext@imc.org
Message-id: <Pine.SOL.3.95.980710124151.20219G-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

On Fri, 10 Jul 1998, Steve Hole wrote:
> I also wasn't sure about the AUTH capability support.    It is a wonderful 
> idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
> only thing is that John's update to the POP3 AUTH extension defines a probe
> function (AUTH with no arguments) for listing available server mechanisms.   
> Perhaps there has been discussion on removing the probe (going back to the
> RFC1734 behaviour) in favour of the capability response.   As it is, there
> are two ways to get the same information.   I'm not sure if this is a problem
> or not.    I'm not sure which to implement in my client.

There was a long discussion on this issue a few months ago which I believe
came to the rough concensus that most would prefer a slow migration to the
capability list, so that clients only have to do one kind of feature
probe.

The current draft of the POP3 STARTTLS support requires that CAPA be
implemented.  That way, one doesn't have to probe for STARTTLS, then probe
for SASL AUTH mechanisms, then probe for each optional command separately.

As for what to do in a server or client, the server code I wrote does both
the SASL list in the capabilities and the list in response to "AUTH" with
no arguments in John's draft.  That's not hard to do.

On the client side, I'd suggest using AUTH with no arguments if you're
using the non-standard LOGIN or NTLM mechanisms since I believe those were
deployed by one vendor with whom some clients may wish to interoperate. 
Otherwise, I'd rely on the SASL capability response, presuming it doesn't
get cut from this proposal. 

		- Chris



From owner-ietf-pop3ext  Fri Jul 10 15:25:57 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA08358
	for ietf-pop3ext-bks; Fri, 10 Jul 1998 15:25:57 -0700 (PDT)
Received: from dragon (ppp1215.glas.apc.org [194.154.81.161])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08352
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 15:25:53 -0700 (PDT)
Received: FROM demo.ru ([194.154.81.161]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 11 Jul 1998 02:27:16 +0300
Message-ID: <35A69543.42E82E0B@demo.ru>
Date: Sat, 11 Jul 1998 02:27:16 +0400
From: Alexey Melnikov <mel@demo.ru>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
References: <199807090130.VAA28119@spot.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Sorry for delay. I forgot about Last Call, my fault.

Keith Moore wrote:

> I apologize for an off-topic posting.
> Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists.
>
> On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt ,
> for Proposed Standard status.  Nobody has commented on the document.  I am
> reluctant to recommend that IESG approve this document without more evidence
> of support.
>
> So I'm asking for more review...
>
> Should the document be adopted as is?  Does it need more wordsmithing?

May be only only few comments/questions...

Section 6.3

    Discussion:
        [skipped].
       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.

Why outline the existence of the second base64-encoded parameters?
Are you trying to correct AUTH RFC?


Section 6.4

    Standard commands affected:
        USER APOP AUTH

    Discussion:
        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

May be I have paranoia, but PASS command is affected by LOGIN-DELAY also.


Section 8.1

    LOGIN-DELAY
        This occurs on an -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.

I don't like servers that says "-ERR user not known" to USER command.
I think that LOGIN-DELAY response to USER command may server as a hint for attack on
server.
I propose to forbid server answer "-ERR [LOGIN-DELAY n]" to the USER command.

Last question : why authors decided to change syntax for IMPLEMENTATION from
IMPLEMENTATION "Shlemazle Plotz v302"
to
IMPLEMENTATION Shlemazle-Plotz-v302

> Are all of these capabilities needed?

Yes, because client should know about their existence to operate correctly with
different servers and to provide with service.

> Are all of the capabilities defined with sufficient precision?

I think that descriptions are precise enough.

> Should the document be standards track or should it be Informational or
> Experimental?

I would like to see it on Standard track, to insure interoperability (as other list
members wrote).

> Should the extension mechanism be separated from (and perhaps a different
> status from) the extensions themselves?

I agree with Chris Newman. So nothing else I can add.


Chris Newman wrote:

> > Are all of these capabilities needed?
>
> All of the capabilities (with the exception of IMPLEMENTATION) reflect
> functional variations in deployed POP servers which would function more
> smoothly if the client knew about them.  So I'd say yes.

I agree. About IMPLEMENTATION : to be frank IMPLEMENTATION servers for
logging/debugging purposes only. I don't see other use. IMPLEMENTATION requires 1
line of code to implement, so I think we don't need to discuss it.


Best regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client
Imap Development Kit (my own product)

Epsylon Technologies, Russia
 http://www.demo.ru
------------------------------------------

P.S. I've implemented in my server TOP, USER, PIPELINING, EXPIRE, UIDL and
IMPLEMENTATION.
And I have plans to implement SASL (CRAM-MD5) and LOGIN-DELAY as well.

Has anybody client that support current draft? (Or I have to write it myself :-))




From owner-ietf-pop3ext  Fri Jul 10 16:32:53 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id QAA09370
	for ietf-pop3ext-bks; Fri, 10 Jul 1998 16:32:53 -0700 (PDT)
Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09366
	for <ietf-pop3ext@imc.org>; Fri, 10 Jul 1998 16:32:51 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA11701; Fri, 10 Jul 1998 16:32:27 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100e34b1cc517ae778@[129.46.136.131]>
In-Reply-To: <35A69543.42E82E0B@demo.ru>
References: <199807090130.VAA28119@spot.cs.utk.edu>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 10 Jul 1998 16:29:02 -0700
To: Alexey Melnikov <mel@demo.ru>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: ietf-pop3ext@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Thanks for your comments, Alexey.

At 3:27 PM -0700 7/10/98, Alexey Melnikov wrote:

>PASS command is affected by LOGIN-DELAY also.

Yes, this is a (minor) error and should be fixed.

>I think that LOGIN-DELAY response to USER command may server as a
>hint for attack on server.  I propose to forbid server answer "-ERR
>[LOGIN-DELAY n]" to the USER command.

It would be good to add text suggesting that servers not send
LOGIN-DELAY in response to a USER command, and noting why, but I'm not
sure we need to forbid it.

>Last question : why authors decided to change syntax for IMPLEMENTATION from
>IMPLEMENTATION "Shlemazle Plotz v302"
>to
>IMPLEMENTATION Shlemazle-Plotz-v302

The POP protocol doesn't have the concept of a quoted string; responses
are a series of space-delimited tokens.  The IMPLEMENTATION capability
was corrected to reflect this, and text was added to point out that if
the parameter is supposed to be a single token, to make sure there are
no embedded spaces.  (Of course, since IMPLEMENTATION is only for
logging, it doesn't really matter.)

I don't think these corrections are serious enough for a new version of
the draft and a new last call; they may be minor enough for the RFC
editor to make, as provided for, or they can be corrected later.


From owner-ietf-pop3ext  Sun Jul 12 02:37:29 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id CAA17766
	for ietf-pop3ext-bks; Sun, 12 Jul 1998 02:37:29 -0700 (PDT)
Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17752;
	Sun, 12 Jul 1998 02:36:43 -0700 (PDT)
Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138])
	by info.dsv.su.se (8.8.8/8.8.8) with ESMTP
	id LAA09126;
	Sun, 12 Jul 1998 11:37:02 +0200 (MET DST)
X-Sender: jpalme@mail.dsv.su.se (Unverified)
Message-Id: <v04003a05b1ce2daf562a@[130.237.150.138]>
In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 12 Jul 1998 11:35:46 +0200
To: ietf-pop3ext@imc.org, IETF mail extensions mailing list <mailext@imc.org>
From: Jacob Palme <jpalme@dsv.su.se>
Subject: Re: [Off Topic] Need review for POP3 extension
 mechanism
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 03.30 +0200 98-07-09, Keith Moore wrote:
> On May 18, a Last Call was issued on for document
>draft-gellens-pop3ext-05.txt ,
> for Proposed Standard status.  Nobody has commented on the document.  I am
> reluctant to recommend that IESG approve this document without more evidence
> of support.

I have read the document and have some comments. I am not a
POP expert and have no personal experience of implementing
POP.

I suggest that at the end of the description of each
capability is added a new subheader "Specified in". For
those capabilities which have been described in other IETF
standards, this subheader should give an explicit reference
to this standard. For thos capabilities, which have not
been described in other IETF standards, this subheader
could contain the phrase "This standard".

Chapter 4, second paragraph, I suggest add information of
whether CRLF is included in these 255 octets or not.

The way I understand the specification, two new
interactions between clients and server are needed, started
with the CAPA command, one before authorization and one
afterwards. Interactions usually incur delays. Is this
really necessary? One might compare with the EHLO command
in SMTP, which does not incur any additional interactions,
since it replaces the HELO interaction.

USER capability: "although they may not be available to all
users": I suggest this is specified more clearly. To which
users are they available and not available? My guess, from
reading the text, is that users are split into three
categories:

(a) Users who may issue USER and PASS

(b) Users who may not issue USER and PASS, but which can
use some kind of mechanism for general retrieval of public
messages

(c) Users who may not use this POP server at all

The above is only my guess, the standard should specify
what it means!

PIPELINING capability: Keith has indicated that maybe the
new capabilities should not be described here but in a
separate document. I have no general comment on this, but I
think the PIPELINING capability is important, and do not
want any delay in making it into a standard.

EXPIRE capability: Days after what? Days after the arrival
of the message into the POP mailbox? Days after last user
connection to the POP server?


Chapter 7: "Clients MUST NOT require the precense of any
extension for basic functionality". I do not like this at
all. Certainly, it should be permitted for a company to
supply its users with clients which will refuse to work
without requiring authorization! Such clients would
increase security against certain kinds of attacks, and it
is unreasonable that such clients are forbidden.

Chapter 9: "IANA considerations". Any specification of new
IANA registries must contain more information, such as the
procedure for IANA to employ in accepting new items into
the registry. See "draft-iesg-iana-considerations-04.txt".

I am not a member of the ietf-pop3ext@imc.org, so please
copy any replies to this message, which I should see,
either to me personally or to the mailext@imc.org
mailing list. (It is reasonable that discussion in the
final stage of IESG approval of a new standard is
widened to a more general ist, like the mailext list.
Since the mailext IETF wg stopped operation, discussion
in that list will not cause problem to ongoing standards
work in the same list.)

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Temporary summer phone No. +46-8-664 77 48 not +46-8-16 16 67



From owner-ietf-pop3ext  Mon Jul 13 08:08:55 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id IAA12051
	for ietf-pop3ext-bks; Mon, 13 Jul 1998 08:08:55 -0700 (PDT)
Received: from dragon (ppp1550.glas.apc.org [195.218.251.38])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12047
	for <ietf-pop3ext@imc.org>; Mon, 13 Jul 1998 08:08:46 -0700 (PDT)
Received: FROM demo.ru ([127.0.0.1]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 13 Jul 1998 18:58:16 +0300
Message-ID: <35AA2088.31FD8511@demo.ru>
Date: Mon, 13 Jul 1998 18:58:16 +0400
From: Alexey Melnikov <mel@demo.ru>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Randall Gellens <randy@Qualcomm.Com>
CC: ietf-pop3ext@imc.org
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
References: <199807090130.VAA28119@spot.cs.utk.edu> <v04100e34b1cc517ae778@[129.46.136.131]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk



Randall Gellens wrote:

> Thanks for your comments, Alexey.
>
> At 3:27 PM -0700 7/10/98, Alexey Melnikov wrote:
>
> >PASS command is affected by LOGIN-DELAY also.
>
> Yes, this is a (minor) error and should be fixed.
>
> >I think that LOGIN-DELAY response to USER command may server as a
> >hint for attack on server.  I propose to forbid server answer "-ERR
> >[LOGIN-DELAY n]" to the USER command.
>
> It would be good to add text suggesting that servers not send
> LOGIN-DELAY in response to a USER command, and noting why, but I'm not
> sure we need to forbid it.

I think it is acceptable.

> >Last question : why authors decided to change syntax for IMPLEMENTATION from
> >IMPLEMENTATION "Shlemazle Plotz v302"
> >to
> >IMPLEMENTATION Shlemazle-Plotz-v302
>
> The POP protocol doesn't have the concept of a quoted string; responses
> are a series of space-delimited tokens.  The IMPLEMENTATION capability
> was corrected to reflect this, and text was added to point out that if
> the parameter is supposed to be a single token, to make sure there are
> no embedded spaces.  (Of course, since IMPLEMENTATION is only for
> logging, it doesn't really matter.)
>
> I don't think these corrections are serious enough for a new version of
> the draft and a new last call; they may be minor enough for the RFC
> editor to make, as provided for, or they can be corrected later.

I agree, no need for a new version of the draft.
Personally - I would like to see "Pop3 extension" draft as standard as soon as
possible.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client
Imap Development Kit (my own product)

Epsylon Technologies, Russia
 http://www.demo.ru
------------------------------------------




From owner-ietf-pop3ext  Mon Jul 13 09:50:59 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id JAA12777
	for ietf-pop3ext-bks; Mon, 13 Jul 1998 09:50:59 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12773;
	Mon, 13 Jul 1998 09:50:58 -0700 (PDT)
Received: from elwood.innosoft.com ("port 37814"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-11 #U3049)
 with SMTP id <01IZCJ1NBOEQ99DUJH@INNOSOFT.COM>; Mon, 13 Jul 1998 09:51:16 PDT
Date: Mon, 13 Jul 1998 09:52:32 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
In-reply-to: <v04003a05b1ce2daf562a@[130.237.150.138]>
To: Jacob Palme <jpalme@dsv.su.se>
Cc: ietf-pop3ext@imc.org, IETF mail extensions mailing list <mailext@imc.org>
Message-id: <Pine.SOL.3.95.980713091826.60D-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

On Sun, 12 Jul 1998, Jacob Palme wrote:
> I suggest that at the end of the description of each
> capability is added a new subheader "Specified in". For
> those capabilities which have been described in other IETF
> standards, this subheader should give an explicit reference
> to this standard. For thos capabilities, which have not
> been described in other IETF standards, this subheader
> could contain the phrase "This standard".

That's a reasonable suggestion.  If Randy does "a revision reflecting
comments received during last call", then this would be useful.

> Chapter 4, second paragraph, I suggest add information of
> whether CRLF is included in these 255 octets or not.

Good point.

> The way I understand the specification, two new
> interactions between clients and server are needed, started
> with the CAPA command, one before authorization and one
> afterwards. Interactions usually incur delays. Is this
> really necessary? One might compare with the EHLO command
> in SMTP, which does not incur any additional interactions,
> since it replaces the HELO interaction.

A reasonable issue.  But realize there is no equivalent to HELO in POP3.
The only other place to put the capability list would be in the greeting
line which is already overloaded with the APOP challenge.  On the other
hand, without the CAPA command, one would have to do an extra round-trip
to probe for each capability one wanted to use.  If we add TLS to POP3,
that would be up to two round-trips before login and four afterwards. 
Knocking that down to one before and one afterwards is an improvement, and
with piplining, the round-trip after login can be eliminated -- with the
result of this being no more expensive than ESMTP EHLO.

I think you've just made a good argument for why this should be
standardized :-)

> USER capability: "although they may not be available to all
> users": I suggest this is specified more clearly. To which
> users are they available and not available? My guess, from
> reading the text, is that users are split into three
> categories:
> 
> (a) Users who may issue USER and PASS
> 
> (c) Users who may not use this POP server at all
> 
> The above is only my guess, the standard should specify
> what it means!

It's an issue of security policy.  A site may determine that some subset
of users aren't allowed to use clear text passwords and have to use APOP
or AUTH instead.  I don't think the current wording is particularly
troublesome, there are several reasonable interopretations none of which
result in an interoperability problem.

> (b) Users who may not issue USER and PASS, but which can
> use some kind of mechanism for general retrieval of public
> messages

FYI, POP3 has no such mechanism and probably never will given that's an
IMAP feature.

> EXPIRE capability: Days after what? Days after the arrival
> of the message into the POP mailbox? Days after last user
> connection to the POP server?

Since it says "indicates the minimum server retention period, in days, for
messages on the server", that would mean EXPIRE is: min(days after
arrival, days after retrieval) which the example describes in some detail.

There was a lot of discussion behind EXPIRE, and trying to express server
policy with more precision simply results in too much complexity.  EXPIRE
has just enough information for a client to know what it has to do (0 =
disallow "leave mail on server", NEVER = "leave mail on server" is fine,
something else = consult user about leave mail on server).

> Chapter 7: "Clients MUST NOT require the precense of any
> extension for basic functionality". I do not like this at
> all. Certainly, it should be permitted for a company to
> supply its users with clients which will refuse to work
> without requiring authorization! Such clients would
> increase security against certain kinds of attacks, and it
> is unreasonable that such clients are forbidden.

Good point.  POP3 is a strange beast since there is no
mandatory-to-implement authentication mechanism (which makes clear text
mandatory to implement implicitly), thus one has to require an
authentication command to function since anonymous POP3 is worthless.  I
propose:

  Clients MUST NOT require the presence of any extension or optional
  feature for basic functionality, with the exception of the
  authentication commands (APOP, AUTH and USER/PASS).

> Chapter 9: "IANA considerations". Any specification of new
> IANA registries must contain more information, such as the
> procedure for IANA to employ in accepting new items into
> the registry. See "draft-iesg-iana-considerations-04.txt".

It already identifies the procedure as "IESG approval" for POP3
capabilities and "Specification Required" for response codes.  What more
is necessary?  We certainly can't make a normative reference to an
Internet draft.

		- Chris



From owner-ietf-pop3ext  Mon Jul 13 15:22:52 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA15464
	for ietf-pop3ext-bks; Mon, 13 Jul 1998 15:22:52 -0700 (PDT)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15460
	for <ietf-pop3ext@imc.org>; Mon, 13 Jul 1998 15:22:51 -0700 (PDT)
Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA15036; Mon, 13 Jul 1998 15:22:45 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: lgl@randy-nt4.qualcomm.com
Message-Id: <v04100e07b1d03646e24e@[129.46.137.174]>
In-Reply-To: <SIMEON.980710083705.C@gallileo.esys.ca>
References: <199807090130.VAA28119@spot.cs.utk.edu>
 <199807090130.VAA28119@spot.cs.utk.edu>
Date: Mon, 13 Jul 1998 15:17:04 -0700
To: ietf-pop3ext@imc.org, Keith Moore <moore@cs.utk.edu>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 8:37 AM -0600 7/10/98, Steve Hole wrote:
>
>The document should definitely be standards track.   Certain "optional"
>features like UIDL and TOP are unwieldly at best to implement without a
>capability probe.   Perhaps it is because we were an IMAP4 mailer first
>(and therefore use to CAPABILITY), I *really* found I missed it in POP3.
>

If some one needs a concrete reason why probing is a problem, here's one:
If you do a TOP command and you get back -ERR you don't know if that
paritcular TOP command failed because the message wasn't available, or
because the TOP command isn't implemented.

LL

From owner-ietf-pop3ext  Mon Jul 13 15:23:54 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA15480
	for ietf-pop3ext-bks; Mon, 13 Jul 1998 15:23:54 -0700 (PDT)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15469;
	Mon, 13 Jul 1998 15:23:26 -0700 (PDT)
Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA15020; Mon, 13 Jul 1998 15:22:41 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: lgl@randy-nt4.qualcomm.com
Message-Id: <v04100e04b1d035cac556@[129.46.137.174]>
In-Reply-To: <v04003a05b1ce2daf562a@[130.237.150.138]>
References: <199807090130.VAA28119@spot.cs.utk.edu>
Date: Mon, 13 Jul 1998 15:09:37 -0700
To: Jacob Palme <jpalme@dsv.su.se>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension  mechanism
Cc: ietf-pop3ext@imc.org, IETF mail extensions mailing list <mailext@imc.org>
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 11:35 AM +0200 7/12/98, Jacob Palme wrote:
>
>The way I understand the specification, two new
>interactions between clients and server are needed, started
>with the CAPA command, one before authorization and one
>afterwards. Interactions usually incur delays. Is this
>really necessary? One might compare with the EHLO command
>in SMTP, which does not incur any additional interactions,
>since it replaces the HELO interaction.
>
In addition to Chris's comment, two CAPA commands are not always needed.
You only need two if the extension you're interested in is documented to
possibly occur after authorization.

LL

From owner-ietf-pop3ext  Wed Jul 15 17:34:23 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id RAA25398
	for ietf-pop3ext-bks; Wed, 15 Jul 1998 17:34:23 -0700 (PDT)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA25394
	for <ietf-pop3ext@imc.org>; Wed, 15 Jul 1998 17:34:21 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA29230; Wed, 15 Jul 1998 17:33:57 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100e72b1d2f9f9fa50@[129.46.136.131]>
In-Reply-To: <SIMEON.980710083705.C@gallileo.esys.ca>
References: <199807090130.VAA28119@spot.cs.utk.edu>
 <199807090130.VAA28119@spot.cs.utk.edu>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 15 Jul 1998 17:32:43 -0700
To: Steve Hole <steve@esys.ca>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: ietf-pop3ext@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 7:37 AM -0700 7/10/98, Steve Hole wrote:

>I also wasn't sure about the AUTH capability support.    It is a wonderful
>idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
>only thing is that John's update to the POP3 AUTH extension defines a probe
>function (AUTH with no arguments) for listing available server mechanisms.
>Perhaps there has been discussion on removing the probe (going back to the
>RFC1734 behaviour) in favour of the capability response.   As it is, there
>are two ways to get the same information.   I'm not sure if this is a problem
>or not.    I'm not sure which to implement in my client.

This issue came up in discussions on John's draft, and the general
consensus (as I recall it) was that new clients should only implement
the CAPA mechanism, and new servers should implement both, so that they
support both new CAPA clients and any clients which have already
implemented the empty-AUTH mechanism.

From owner-ietf-pop3ext  Wed Jul 15 18:21:07 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id SAA25678
	for ietf-pop3ext-bks; Wed, 15 Jul 1998 18:21:07 -0700 (PDT)
Received: from mail.hethmon.com (mail.hethmon.com [208.147.156.6])
	by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA25674
	for <ietf-pop3ext@imc.org>; Wed, 15 Jul 1998 18:21:05 -0700 (PDT)
Received: from mail.hethmon.com (mail.hethmon.com [208.147.156.6] ) by mail.hethmon.com
    (Hethmon Brothers Smtpd) ; Wed, 15 Jul 1998 21:25:32 -0400
Message-Id: <199807152125.3235110.6@mail.hethmon.com>
Received: from sambo.hethmon.com by mail.hethmon.com
    (Hethmon Brothers Pop3d) ; Wed, 15 Jul 1998 21:25:31 -0400
To: ietf-pop3ext@imc.org
X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0)
Date: Wed, 15 Jul 1998 21:21:32 -0400
From: Paul Hethmon <phethmon@hethmon.com>
Reply-To: Paul Hethmon <phethmon@hethmon.com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

** Reply to note from Keith Moore <moore@cs.utk.edu> Wed, 08 Jul 1998 21:30:01 -0400

Here are my thoughts:

> On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt , 
> for Proposed Standard status.  Nobody has commented on the document.  I am  
> reluctant to recommend that IESG approve this document without more evidence  
> of support. 
>    
> So I'm asking for more review... 
>  
> Should the document be adopted as is?  Does it need more wordsmithing? 

A quick reading didn't leave me any questions about it. It seemed to
be easily comprehended.

> Are all of these capabilities needed? 

I can see use for it to a certain extent. I haven't had many requests from
my customers for extensions and/or capabilities of this nature though I
already support all of the 1939 optional commands.

> Are all of the capabilities defined with sufficient precision? 

Yes.
  
> Should the document be standards track or should it be Informational or  
> Experimental? 

If it's going to be anything, it should be standards track. With standard
status, it's dead at the starting gate. I would likely implement it if it
went Informational, not likely if Experimental.
  
> Should the extension mechanism be separated from (and perhaps a different  
> status from) the extensions themselves? 

No. I'd leave them in. I see the extensions as not quite extensions to the
protocol but more refinements. As the document said, it's not the intent
to turn POP3 into IMAP. In this light, it would be better for implementors
to have the gathered into one spot. TOP, USER, and UIDL are already in
1939, so no need to separate them out. SASL is in 2222 so it's documented.

The other commands are more of an informational nature than operational. Defining
them here seems a good thing in that we shouldn't expect many if any further
extensions to POP3.
  
> If the document is approved for Proposed, should all of the proposed extensions  
> be included?  Or should some of the extensions be moved to a separate  
> Informational or Experimental?   Which ones? 

I would keep them together and in the standards track.
  
> In the absence of more community input, my recommendation would be to direct 
> the authors to remove all of the capabilities from this document, except those  
> which are already defined in standards-track documents.  Additional capabilities  
> could be defined in a separate experimental or informational RFC.

Paul



-------------------------------------------------------------------------
Paul Hethmon                                         phethmon@hethmon.com
Inet.Mail Internet Mail Server                     http://www.hethmon.com
-------------------------------------------------------------------------
Author   "Illustrated Guide to HTTP"   http://www.manning.com/Hethmon?882
-------------------------------------------------------------------------
Warpstock    --    Tune In! & Warp Out!    --    http://www.warpstock.org

cc: Keith Moore <moore@cs.utk.edu>


From owner-ietf-pop3ext  Thu Jul 16 07:05:54 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id HAA10146
	for ietf-pop3ext-bks; Thu, 16 Jul 1998 07:05:54 -0700 (PDT)
Received: from monet.esys.ca (monet.esys.ca [198.161.92.2])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10142
	for <ietf-pop3ext@imc.org>; Thu, 16 Jul 1998 07:05:53 -0700 (PDT)
Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85])
	by monet.esys.ca (2.0.4-beta-2/SMS 2.0.4-devel) with ESMTP id IAA27304;
	Thu, 16 Jul 1998 08:05:47 -0600 (MDT)
Message-Id: <199807161405.IAA27304@monet.esys.ca>
From: Steve Hole <steve@esys.ca>
Date: Thu, 16 Jul 1998 08:04:25 -0600
To: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: ietf-pop3ext@imc.org
In-Reply-To: <v04100e72b1d2f9f9fa50@[129.46.136.131]>
References: <v04100e72b1d2f9f9fa50@[129.46.136.131]> <199807090130.VAA28119@spot.cs.utk.edu>   <199807090130.VAA28119@spot.cs.utk.edu>   
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Message-ID: <SIMEON.980716080425.E@gallileo.esys.ca>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9807160804.F; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9807160804.F
Content-Type: Text/PLAIN; CHARSET=US-ASCII


On Wed, 15 Jul 1998 17:32:43 -0700 Randall Gellens <randy@qualcomm.com> wrote:

> At 7:37 AM -0700 7/10/98, Steve Hole wrote:
> 
> >I also wasn't sure about the AUTH capability support.    It is a wonderful
> >idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
> >only thing is that John's update to the POP3 AUTH extension defines a probe
> >function (AUTH with no arguments) for listing available server mechanisms.
> >Perhaps there has been discussion on removing the probe (going back to the
> >RFC1734 behaviour) in favour of the capability response.   As it is, there
> >are two ways to get the same information.   I'm not sure if this is a problem
> >or not.    I'm not sure which to implement in my client.
> 
> This issue came up in discussions on John's draft, and the general
> consensus (as I recall it) was that new clients should only implement
> the CAPA mechanism, and new servers should implement both, so that they
> support both new CAPA clients and any clients which have already
> implemented the empty-AUTH mechanism.

Hmm ... that works as long as all servers that support AUTH also support CAPA.
I presume that it was the concensus of the group that there were no servers 
that supported AUTH without supporting CAPA as well.   I do know that the 
current Cyrus server release supports AUTH but not CAPA.    That's why I 
raised the issue.   I have implemented both in the client and do the probe
because I know of at least one deployed POP3 server that does it.

I think that we need to pick one way or the other and make both documents 
agree on the choice.   There can't be that many implementations yet.   This
would force any server implementations of AUTH to do the right thing (yet to
be defined).   As long as both go to Proposed in agreement, we should be able
to get consistent implementations.

Am I worrying over nothing?   What other implementations, client or server, 
are their of AUTH and/or CAPA?

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:Steve.Hole@esys.ca  
Phone:403-424-4922

--Part9807160804.F
Content-Type: Application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version)

iQA/AwUBNa4Iati5Jj9Fn5KMEQL85ACgxq0Kg7FKaxRHQVH79a92+YX3/BMAn1CG
CZUtzdF0PLy4SVdKuMKsQYK0
=/6hC
-----END PGP SIGNATURE-----

--Part9807160804.F--

From owner-ietf-pop3ext  Thu Jul 16 10:26:29 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id KAA11933
	for ietf-pop3ext-bks; Thu, 16 Jul 1998 10:26:29 -0700 (PDT)
Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11929
	for <ietf-pop3ext@imc.org>; Thu, 16 Jul 1998 10:26:27 -0700 (PDT)
Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA12008; Thu, 16 Jul 1998 10:26:03 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: lgl@randy-nt4.qualcomm.com
Message-Id: <v04100e01b1d3e1ee1e81@[129.46.137.174]>
In-Reply-To: <v04100e72b1d2f9f9fa50@[129.46.136.131]>
References: <SIMEON.980710083705.C@gallileo.esys.ca>
 <199807090130.VAA28119@spot.cs.utk.edu>
 <199807090130.VAA28119@spot.cs.utk.edu>
Date: Thu, 16 Jul 1998 10:04:41 -0700
To: Randall Gellens <randy@Qualcomm.Com>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: Steve Hole <steve@esys.ca>, ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

What Randy says below was my recollection too, but Steve has pointed out a
problem with this. Seems as long as there are clients that support only
AUTH and servers that support only AUTH we'll have to continue to implement
both AUTH and CAPA probing in both clients and servers for a while. (All
the more reason to get this on the standards track :-)

Implementing both for the servers is dead simple trivial. The client is a
little more work and introduces an additional RTT if CAPA fails, but I
don't think there are any major difficulties. There are far far worse
attrocities in standards these days, and I don't think there's anything we
can do about it anyway.

LL


At 5:32 PM -0700 7/15/98, Randall Gellens wrote:
>At 7:37 AM -0700 7/10/98, Steve Hole wrote:
>
>>I also wasn't sure about the AUTH capability support.    It is a wonderful
>>idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
>>only thing is that John's update to the POP3 AUTH extension defines a probe
>>function (AUTH with no arguments) for listing available server mechanisms.
>>Perhaps there has been discussion on removing the probe (going back to the
>>RFC1734 behaviour) in favour of the capability response.   As it is, there
>>are two ways to get the same information.   I'm not sure if this is a problem
>>or not.    I'm not sure which to implement in my client.
>
>This issue came up in discussions on John's draft, and the general
>consensus (as I recall it) was that new clients should only implement
>the CAPA mechanism, and new servers should implement both, so that they
>support both new CAPA clients and any clients which have already
>implemented the empty-AUTH mechanism.


From owner-ietf-pop3ext  Thu Jul 16 18:00:50 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id SAA15577
	for ietf-pop3ext-bks; Thu, 16 Jul 1998 18:00:50 -0700 (PDT)
Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15573
	for <ietf-pop3ext@imc.org>; Thu, 16 Jul 1998 18:00:49 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by warlock.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA06358; Thu, 16 Jul 1998 17:58:20 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100ea5b1d450817810@[129.46.136.131]>
In-Reply-To: <v04100e01b1d3e1ee1e81@[129.46.137.174]>
References: <v04100e72b1d2f9f9fa50@[129.46.136.131]>
 <SIMEON.980710083705.C@gallileo.esys.ca>
 <199807090130.VAA28119@spot.cs.utk.edu>
 <199807090130.VAA28119@spot.cs.utk.edu>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 16 Jul 1998 17:54:32 -0700
To: Laurence Lundblade <lgl@Qualcomm.Com>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: Randall Gellens <randy@Qualcomm.Com>, Steve Hole <steve@esys.ca>,
        ietf-pop3ext@imc.org, John Gardiner Myers <jgmyers@netscape.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

I apologize for the excessive quoting, but I added John Myers to the cc
list and don't know if he's seen this thread or not.

Since the POP Extensions draft references RFC 1734, which does not use
the empty auth command as a probe, I don't think we need to say
anything about that.  I think John's update should include advice on
supporting both CAPA and the empty auth command, in clients and
servers, as Laurence suggests.


At 10:04 AM -0700 7/16/98, Laurence Lundblade wrote:

>What Randy says below was my recollection too, but Steve has pointed out a
>problem with this. Seems as long as there are clients that support only
>AUTH and servers that support only AUTH we'll have to continue to implement
>both AUTH and CAPA probing in both clients and servers for a while. (All
>the more reason to get this on the standards track :-)
>
>Implementing both for the servers is dead simple trivial. The client is a
>little more work and introduces an additional RTT if CAPA fails, but I
>don't think there are any major difficulties. There are far far worse
>attrocities in standards these days, and I don't think there's anything we
>can do about it anyway.
>
>LL
>
>
>At 5:32 PM -0700 7/15/98, Randall Gellens wrote:
>>At 7:37 AM -0700 7/10/98, Steve Hole wrote:
>>
>>>I also wasn't sure about the AUTH capability support.    It is a wonderful
>>>idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
>>>only thing is that John's update to the POP3 AUTH extension defines a probe
>>>function (AUTH with no arguments) for listing available server mechanisms.
>>>Perhaps there has been discussion on removing the probe (going back to the
>>>RFC1734 behaviour) in favour of the capability response.   As it is, there
>>>are two ways to get the same information.   I'm not sure if this is
>>>a problem
>>>or not.    I'm not sure which to implement in my client.
>>
>>This issue came up in discussions on John's draft, and the general
>>consensus (as I recall it) was that new clients should only implement
>>the CAPA mechanism, and new servers should implement both, so that they
>>support both new CAPA clients and any clients which have already
>>implemented the empty-AUTH mechanism.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
My friends, no matter how rough the road may be, we can and we will,
never, never surrender to what is right
                  --Vice President  Dan Quayle, in a speech
                    to the Christian Coalition

From owner-ietf-pop3ext  Thu Jul 16 18:14:57 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id SAA15728
	for ietf-pop3ext-bks; Thu, 16 Jul 1998 18:14:57 -0700 (PDT)
Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15724
	for <ietf-pop3ext@imc.org>; Thu, 16 Jul 1998 18:14:54 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA20686; Thu, 16 Jul 1998 18:14:55 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100ea6b1d45264e99d@[129.46.136.131]>
In-Reply-To: <35A69543.42E82E0B@demo.ru>
References: <199807090130.VAA28119@spot.cs.utk.edu>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 16 Jul 1998 18:06:19 -0700
To: Alexey Melnikov <mel@demo.ru>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: ietf-pop3ext@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 3:27 PM -0700 7/10/98, Alexey Melnikov wrote:

>Section 6.3
>
>    Discussion:
>        [skipped].
>       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.
>
>Why outline the existence of the second base64-encoded parameters?

Sorry, Alexey, I neglected to answer this in my previous reply.

RFC 1734 doesn't specify an optional second parameter.  RFC 2222 does
mention it, but does not say it should be base64 encoded; it talks
about binary tokens.  Because POP is not a binary protocol, it makes
sense to specify that the parameter (initial response) be base64
encoded.

From owner-ietf-pop3ext  Fri Jul 17 07:16:07 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id HAA00990
	for ietf-pop3ext-bks; Fri, 17 Jul 1998 07:16:07 -0700 (PDT)
Received: from att.com (kcgw2.att.com [192.128.133.152])
	by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA00986
	for <ietf-pop3ext@imc.org>; Fri, 17 Jul 1998 07:16:06 -0700 (PDT)
Received: by kcgw2.att.com; Fri Jul 17 08:48 CDT 1998
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99])
	by kcig2.att.att.com (AT&T/GW-1.0) with ESMTP id JAA08924
	for <ietf-pop3ext@imc.org>; Fri, 17 Jul 1998 09:08:17 -0500 (CDT)
Received: from hansen.bl-els.att.com by maillennium.att.com (inetlab) with SMTP
          id <19980717140854un10478231e>; Fri, 17 Jul 1998 14:08:54 +0000
Message-ID: <35AF5B59.20984366@att.com>
Date: Fri, 17 Jul 1998 10:10:33 -0400
From: Tony Hansen <tony@att.com>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: any comments on draft-hansen-pop3-xtndext-00.txt?
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Any comments on draft-hansen-pop3-xtndext-00.txt? I've included the
abstract below. It was published in June as part of work for the GRIP
WG, but I forgot to mention it in the pop3ext mailing list.

    Tony Hansen, tony@att.com

====
     1. Abstract

          This Internet Draft describes some  extensions  to
     the  Post Office Protocol [POP3] and are described here
     for historical purposes.  The status of  this  Internet
     Draft will be Historic.

          [XTND] describes a mechanism to  extend  the  POP3
     protocol,  called XTND.  Two extensions which have been
     implemented on some  server  implementations  are  XTND
     XMIT  and  XTND  XLST; this memo describes these exten-
     sions.

          New implementations of POP3  clients  and  servers
     are  not  expected to implement these extensions; other
     mechanisms should be used instead.  For example, [SMTP]
     should  be used instead of XTND XMIT for sending email.
     If authentication is needed for sending email, then the
     proposed [ESMTP] [AUTH] extension should be used.



From owner-ietf-pop3ext  Fri Jul 17 10:55:48 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id KAA02691
	for ietf-pop3ext-bks; Fri, 17 Jul 1998 10:55:48 -0700 (PDT)
Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02687
	for <ietf-pop3ext@imc.org>; Fri, 17 Jul 1998 10:55:47 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA22595; Fri, 17 Jul 1998 10:56:01 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04100eaeb1d53f5aac44@[129.46.136.131]>
In-Reply-To: <35AF5B59.20984366@att.com>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Fri, 17 Jul 1998 10:54:31 -0700
To: Tony Hansen <tony@att.com>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
Cc: ietf-pop3ext@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 7:10 AM -0700 7/17/98, Tony Hansen wrote:

>Any comments on draft-hansen-pop3-xtndext-00.txt?

It seems quite reasonable to me.  My only comment would be on section 2:

>recipients MUST NOT see a Bcc: header listing  anyone
>       except possibly that recipient.

My understanding is that it is an acceptable, but less common,
implementation choice to allow Bcc recipients to see each other; that
is, the message text sent to Bcc recipients MAY include a Bcc header
listing all Bcc recipients.

RFC 822 says:

    4.5.3.  BCC / RESENT-BCC

        This field contains the identity of additional  recipients  of
        the  message.   The contents of this field are not included in
        copies of the message sent to the primary and secondary  reci-
        pients.   Some  systems  may choose to include the text of the
        "Bcc" field only in the author(s)'s  copy,  while  others  may
        also include it in the text sent to all those indicated in the
        "Bcc" list.

From owner-ietf-pop3ext  Fri Jul 17 14:37:19 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA04214
	for ietf-pop3ext-bks; Fri, 17 Jul 1998 14:37:19 -0700 (PDT)
Received: from dragon (ppp1166.glas.apc.org [194.154.81.112])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04210
	for <ietf-pop3ext@imc.org>; Fri, 17 Jul 1998 14:37:15 -0700 (PDT)
Received: FROM demo.ru ([194.154.81.112]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 18 Jul 1998 01:38:04 +0300
Message-ID: <35AFC43C.28A91CAA@demo.ru>
Date: Sat, 18 Jul 1998 01:38:04 +0400
From: Alexey Melnikov <mel@demo.ru>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
References: <199807090130.VAA28119@spot.cs.utk.edu> <v04100ea6b1d45264e99d@[129.46.136.131]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Randall Gellens wrote:

> At 3:27 PM -0700 7/10/98, Alexey Melnikov wrote:
>
> >Section 6.3
> >
> >    Discussion:
> >        [skipped].
> >       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.
> >
> >Why outline the existence of the second base64-encoded parameters?
>
> Sorry, Alexey, I neglected to answer this in my previous reply.
>
> RFC 1734 doesn't specify an optional second parameter.  RFC 2222 does
> mention it, but does not say it should be base64 encoded; it talks
> about binary tokens.  Because POP is not a binary protocol, it makes
> sense to specify that the parameter (initial response) be base64
> encoded.

I understand and agree. Nevertheless I think that updated (if any) version of
RFC 1734 should mention this.

Cheers,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client
Imap Development Kit (my own product)

Epsylon Technologies, Russia
 http://www.demo.ru
------------------------------------------




From owner-ietf-pop3ext  Fri Jul 17 16:04:53 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id QAA04823
	for ietf-pop3ext-bks; Fri, 17 Jul 1998 16:04:53 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04819
	for <ietf-pop3ext@imc.org>; Fri, 17 Jul 1998 16:04:52 -0700 (PDT)
Received: from elwood.innosoft.com ("port 46160"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-11 #U3049)
 with SMTP id <01IZIH8TEWF699E0HA@INNOSOFT.COM> for ietf-pop3ext@imc.org; Fri,
 17 Jul 1998 16:04:32 PDT
Date: Fri, 17 Jul 1998 16:05:46 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
In-reply-to: <35AF5B59.20984366@att.com>
To: Tony Hansen <tony@att.com>
Cc: ietf-pop3ext@imc.org
Message-id: <Pine.SOL.3.95.980717155549.11598F-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

On Fri, 17 Jul 1998, Tony Hansen wrote:
> Any comments on draft-hansen-pop3-xtndext-00.txt? I've included the
> abstract below. It was published in June as part of work for the GRIP
> WG, but I forgot to mention it in the pop3ext mailing list.

I just skimmed it.  It would be worth mentioning that XTND XLST is
obsoleted by the HEADER.FIELDS facility in IMAP4rev1 (RFC 2060).

Also, I'd appreciate it if the document wasn't full justified and
hypenated -- it makes plain text hard to read.  If you're using nroff,
try the ".ad l" and ".hy 0" options.

Note that I still maintain it would be a mistake to publish this spec
prior to the publication of the SMTP AUTH extension.  Hopefully that won't
be too long as SMTP AUTH has completed last call and is awaiting an IESG
ruling.

		- Chris


From owner-ietf-pop3ext  Mon Jul 20 16:18:18 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id QAA18415
	for ietf-pop3ext-bks; Mon, 20 Jul 1998 16:18:18 -0700 (PDT)
Received: from mysa.qualcomm.com (mysa.qualcomm.com [129.46.52.23])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18411
	for <ietf-pop3ext@imc.org>; Mon, 20 Jul 1998 16:18:15 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by mysa.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA03713; Mon, 20 Jul 1998 16:17:42 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101000b1d97a511d44@[129.46.136.131]>
In-Reply-To: 
 <Pine.SOL.3.95.980717155549.11598F-100000@elwood.innosoft.com>
References: <35AF5B59.20984366@att.com>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Mon, 20 Jul 1998 16:13:23 -0700
To: Chris Newman <Chris.Newman@INNOSOFT.COM>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
Cc: Tony Hansen <tony@att.com>, ietf-pop3ext@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 4:05 PM -0700 7/17/98, Chris Newman wrote:

>I just skimmed it.  It would be worth mentioning that XTND XLST is
>obsoleted by the HEADER.FIELDS facility in IMAP4rev1 (RFC 2060).

I'm not sure "obsoleted by" is the right wording, since IMAP has not
obsoleted POP; not yet anyway.  Perhaps "XTND XLST was designed to
provide functionality similar to that now available in IMAP4rev1 (RFC
2060) by the HEADER.FIELDS facility".


>Note that I still maintain it would be a mistake to publish this spec
>prior to the publication of the SMTP AUTH extension.  Hopefully that won't
>be too long as SMTP AUTH has completed last call and is awaiting an IESG
>ruling.

I agree; I'd prefer that this was held until SMTP AUTH (and maybe the
Submit BCP) are out.


From owner-ietf-pop3ext  Tue Jul 21 21:17:50 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id VAA11175
	for ietf-pop3ext-bks; Tue, 21 Jul 1998 21:17:50 -0700 (PDT)
Received: from yuri.exchange.microsoft.com (yuri.exchange.microsoft.com [131.107.88.54])
	by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA11171;
	Tue, 21 Jul 1998 21:17:49 -0700 (PDT)
Received: by yuri.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <PMFFLV67>; Tue, 21 Jul 1998 21:18:24 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010B37E591@DINO>
From: "Mike Gahrns (Exchange)" <mikega@EXCHANGE.MICROSOFT.com>
To: "'ietf-pop3ext@imc.org'" <ietf-pop3ext@imc.org>, drums@cs.utk.edu,
        ietf-smtp@imc.org
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Tue, 21 Jul 1998 21:18:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BDB527.C46A0970"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BDB527.C46A0970
Content-Type: text/plain;
	charset="iso-8859-1"

I apologize for such a late response, but i have been out of the office for
the last few weeks.

I agree with the others who view this as being a useful draft, and second
the motion that it should go as proposed instead of informational or
experimental.

Although the list has not had a lot of dicussion on it, I know Randy has
been discussing this with various people at venues like the ietf, so it has
been getting review.  My biggest concern was the former LMOS setting allowed
for expiration settings to be based on the command used to acccess the msg,
which Randy has addressed with the new EXPIRE setting.

I do have one minor concern regarding the current wording of the EXPIRE
setting. 

The draft states:
"If the expiration policy might differ per user (that is, the EXPIRE
argument might change after authentication), the server MUST announce in the
AUTHENTICATION state the smallest value which might be used.  The server
should announce the more accurate value in the TRANSACTION state.

It is unclear to me whether the intent of this is to force the server to
keep track of the smallest setting a user currently has set, or if it is for
the server to annouce the smallest value that an administrator could
conceivably set for a particular user.  If the intent is the former, than
this will be problematic for servers that are not tightly coupled with their
directory, as it effectively forces the server to scan a list of all user
settings at each log on time. 

I'll talk to Randy to get clarification, and perhaps come up with some
clarification wording in regards to this.

Another minor nit is the wording:
"If the authentication step negotiates an integrity protection layer, the
client SHOULD reissue the CAPA command after authenticating to check for
active down-negotiation attacks."

I'd like to see the wording changed to something like:
"The client SHOULD reissue the CAPA command after authenticating to check
for active down-negotiation attacks and to get any per user capability
settings."



-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Wednesday, July 08, 1998 6:30 PM
To: drums@cs.utk.edu; ietf-smtp@imc.org
Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org
Subject: [Off Topic] Need review for POP3 extension mechanism


I apologize for an off-topic posting.  
Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp
lists.

On May 18, a Last Call was issued on for document
draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has commented on the document.  I am 
reluctant to recommend that IESG approve this document without more evidence

of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient precision?

Should the document be standards track or should it be Informational or 
Experimental?

Should the extension mechanism be separated from (and perhaps a different 
status from) the extensions themselves?

If the document is approved for Proposed, should all of the proposed
extensions 
be included?  Or should some of the extensions be moved to a separate 
Informational or Experimental?   Which ones?

In the absence of more community input, my recommendation would be to direct
the authors to remove all of the capabilities from this document, except
those 
which are already defined in standards-track documents.  Additional
capabilities 
could be defined in a separate experimental or informational RFC.

thanks!

Keith Moore
APPS co-AD

------_=_NextPart_001_01BDB527.C46A0970
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: [Off Topic] Need review for POP3 extension mechanism</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I apologize for such a late response, but i have been =
out of the office for the last few weeks.</FONT>
</P>

<P><FONT SIZE=3D2>I agree with the others who view this as being a =
useful draft, and second the motion that it should go as proposed =
instead of informational or experimental.</FONT></P>

<P><FONT SIZE=3D2>Although the list has not had a lot of dicussion on =
it, I know Randy has been discussing this with various people at venues =
like the ietf, so it has been getting review.&nbsp; My biggest concern =
was the former LMOS setting allowed for expiration settings to be based =
on the command used to acccess the msg, which Randy has addressed with =
the new EXPIRE setting.</FONT></P>

<P><FONT SIZE=3D2>I do have one minor concern regarding the current =
wording of the EXPIRE setting. </FONT>
</P>

<P><FONT SIZE=3D2>The draft states:</FONT>
<BR><FONT SIZE=3D2>&quot;If the expiration policy might differ per user =
(that is, the EXPIRE argument might change after authentication), the =
server MUST announce in the AUTHENTICATION state the smallest value =
which might be used.&nbsp; The server should announce the more accurate =
value in the TRANSACTION state.</FONT></P>

<P><FONT SIZE=3D2>It is unclear to me whether the intent of this is to =
force the server to keep track of the smallest setting a user currently =
has set, or if it is for the server to annouce the smallest value that =
an administrator could conceivably set for a particular user.&nbsp; If =
the intent is the former, than this will be problematic for servers =
that are not tightly coupled with their directory, as it effectively =
forces the server to scan a list of all user settings at each log on =
time. </FONT></P>

<P><FONT SIZE=3D2>I'll talk to Randy to get clarification, and perhaps =
come up with some clarification wording in regards to this.</FONT>
</P>

<P><FONT SIZE=3D2>Another minor nit is the wording:</FONT>
<BR><FONT SIZE=3D2>&quot;If the authentication step negotiates an =
integrity protection layer, the client SHOULD reissue the CAPA command =
after authenticating to check for active down-negotiation =
attacks.&quot;</FONT></P>

<P><FONT SIZE=3D2>I'd like to see the wording changed to something =
like:</FONT>
<BR><FONT SIZE=3D2>&quot;The client SHOULD reissue the CAPA command =
after authenticating to check for active down-negotiation attacks and =
to get any per user capability settings.&quot;</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Keith Moore [<A =
HREF=3D"mailto:moore@cs.utk.edu">mailto:moore@cs.utk.edu</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 08, 1998 6:30 PM</FONT>
<BR><FONT SIZE=3D2>To: drums@cs.utk.edu; ietf-smtp@imc.org</FONT>
<BR><FONT SIZE=3D2>Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org</FONT>
<BR><FONT SIZE=3D2>Subject: [Off Topic] Need review for POP3 extension =
mechanism</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I apologize for an off-topic posting.&nbsp; </FONT>
<BR><FONT SIZE=3D2>Please send replies to ietf-pop3ext@imc.org, not to =
the drums or ietf-smtp lists.</FONT>
</P>

<P><FONT SIZE=3D2>On May 18, a Last Call was issued on for document =
draft-gellens-pop3ext-05.txt ,</FONT>
<BR><FONT SIZE=3D2>for Proposed Standard status.&nbsp; Nobody has =
commented on the document.&nbsp; I am </FONT>
<BR><FONT SIZE=3D2>reluctant to recommend that IESG approve this =
document without more evidence </FONT>
<BR><FONT SIZE=3D2>of support.</FONT>
</P>

<P><FONT SIZE=3D2>So I'm asking for more review...</FONT>
</P>

<P><FONT SIZE=3D2>Should the document be adopted as is?&nbsp; Does it =
need more wordsmithing?</FONT>
<BR><FONT SIZE=3D2>Are all of these capabilities needed?</FONT>
<BR><FONT SIZE=3D2>Are all of the capabilities defined with sufficient =
precision?</FONT>
</P>

<P><FONT SIZE=3D2>Should the document be standards track or should it =
be Informational or </FONT>
<BR><FONT SIZE=3D2>Experimental?</FONT>
</P>

<P><FONT SIZE=3D2>Should the extension mechanism be separated from (and =
perhaps a different </FONT>
<BR><FONT SIZE=3D2>status from) the extensions themselves?</FONT>
</P>

<P><FONT SIZE=3D2>If the document is approved for Proposed, should all =
of the proposed extensions </FONT>
<BR><FONT SIZE=3D2>be included?&nbsp; Or should some of the extensions =
be moved to a separate </FONT>
<BR><FONT SIZE=3D2>Informational or Experimental?&nbsp;&nbsp; Which =
ones?</FONT>
</P>

<P><FONT SIZE=3D2>In the absence of more community input, my =
recommendation would be to direct</FONT>
<BR><FONT SIZE=3D2>the authors to remove all of the capabilities from =
this document, except those </FONT>
<BR><FONT SIZE=3D2>which are already defined in standards-track =
documents.&nbsp; Additional capabilities </FONT>
<BR><FONT SIZE=3D2>could be defined in a separate experimental or =
informational RFC.</FONT>
</P>

<P><FONT SIZE=3D2>thanks!</FONT>
</P>

<P><FONT SIZE=3D2>Keith Moore</FONT>
<BR><FONT SIZE=3D2>APPS co-AD</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BDB527.C46A0970--

From owner-ietf-pop3ext  Wed Jul 22 12:12:11 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA27464
	for ietf-pop3ext-bks; Wed, 22 Jul 1998 12:12:11 -0700 (PDT)
Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27452;
	Wed, 22 Jul 1998 12:11:42 -0700 (PDT)
Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA20867; Wed, 22 Jul 1998 12:12:09 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101020b1dbe6dc00fc@[129.46.136.131]>
In-Reply-To: <2FBF98FC7852CF11912A0000000000010B37E591@DINO>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 22 Jul 1998 12:08:00 -0700
To: "Mike Gahrns (Exchange)" <mikega@EXCHANGE.MICROSOFT.com>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Cc: "'ietf-pop3ext@imc.org'" <ietf-pop3ext@imc.org>, drums@cs.utk.edu,
        ietf-smtp@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Random-Signature-Tag: v1.0a10
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote:

>I do have one minor concern regarding the current wording of the
>EXPIRE setting.
>
>The draft states:
>"If the expiration policy might differ per user (that is, the EXPIRE
>argument might change after authentication), the server MUST announce
>in the AUTHENTICATION state the smallest value which might be used. 
>The server should announce the more accurate value in the TRANSACTION
>state.
>
>It is unclear to me whether the intent of this is to force the server
>to keep track of the smallest setting a user currently has set, or if
>it is for the server to annouce the smallest value that an
>administrator could conceivably set for a particular user.  If the
>intent is the former, than this will be problematic for servers that
>are not tightly coupled with their directory, as it effectively forces
>the server to scan a list of all user settings at each log on time.

The intent is to let the client know that the server does permit mail
to be left on the server, and to present a value which is the smallest
which might be set for the user.  This could be the smallest value
currently in use for any user (so only one value per server), or even
the smallest value which the server permits to be set for any user.
This way a client can decide (because the user has told the client to
leave mail on the server for a larger number of days)  if it needs to
reissue CAPA after authenticating and/or warn the user.


>Another minor nit is the wording:
>"If the authentication step negotiates an integrity protection layer,
>the client SHOULD reissue the CAPA command after authenticating to
>check for active down-negotiation attacks."
>
>I'd like to see the wording changed to something like:
>"The client SHOULD reissue the CAPA command after authenticating to
>check for active down-negotiation attacks and to get any per user
>capability settings."

The intent is to not require clients to issue two CAPA commands.  The
client pretty much has to issue one before authenticating, to learn
which SASL mechanisms are supported, but doesn't have to issue on
afterwards, unless the first CAPA reveals that the server supports some
capabilities whose parameters might change after authentication, and
the client needs the most accurate values (it might be able to use the
more general ones), or the client wants to check for down-negotiation
attacks.  A simple client that only uses a few basic SASL mechanisms,
for example, and only needs to know if the server supports TOP, UIDL,
and allows mail to be left on the server, doesn't need to issue two
CAPAs.  (A client which only uses plaintext or APOP could issue only
one CAPA, after authenticating.)


From owner-ietf-pop3ext  Wed Jul 22 20:43:20 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id UAA00852
	for ietf-pop3ext-bks; Wed, 22 Jul 1998 20:43:20 -0700 (PDT)
Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00842;
	Wed, 22 Jul 1998 20:42:55 -0700 (PDT)
Received: by tide03.microsoft.com; id UAA17039; Wed, 22 Jul 1998 20:43:45 -0700 (PDT)
Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1)
	id xma017036; Wed, 22 Jul 98 20:43:44 -0700
Received: from red-01-imc.dns.microsoft.com ([157.54.1.197]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id UAA28977; Wed, 22 Jul 1998 20:53:56 -0700 (PDT)
Received: from popdog.exchange.microsoft.com (POPDOG [172.30.236.242]) by red-01-imc.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id PKF6X2L1; Wed, 22 Jul 1998 20:43:44 -0700
Received: from mikega9 (mikega9.dns.microsoft.com [157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id 37DWQA4C; Wed, 22 Jul 1998 20:43:49 -0700
Message-ID: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Randall Gellens" <randy@Qualcomm.Com>
Cc: <ietf-pop3ext@imc.org>, <drums@cs.utk.edu>, <ietf-smtp@imc.org>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Date: Wed, 22 Jul 1998 20:46:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

*** within



>At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote:
>
>>I do have one minor concern regarding the current wording of the
>>EXPIRE setting.
>>
>>The draft states:
>>"If the expiration policy might differ per user (that is, the EXPIRE
>>argument might change after authentication), the server MUST announce
>>in the AUTHENTICATION state the smallest value which might be used.
>>The server should announce the more accurate value in the TRANSACTION
>>state.
>>
>>It is unclear to me whether the intent of this is to force the server
>>to keep track of the smallest setting a user currently has set, or if
>>it is for the server to annouce the smallest value that an
>>administrator could conceivably set for a particular user.  If the
>>intent is the former, than this will be problematic for servers that
>>are not tightly coupled with their directory, as it effectively forces
>>the server to scan a list of all user settings at each log on time.
>
>The intent is to let the client know that the server does permit mail
>to be left on the server, and to present a value which is the smallest
>which might be set for the user.  This could be the smallest value
>currently in use for any user (so only one value per server), or even
>the smallest value which the server permits to be set for any user.
*** If it is the smallest value which the server permits to be set for any
user, I am happy with it.
Would it be possible for you to update the draft with the above paragraph?
If I had the question, I am sure others will... The more precise we are now
with things, will save us interoperability grief later and it really is just
a minor clarification so we won't need to worry about another last call.
(The smallest value currently in use by any user on a server is problematic
for us, but we do not have any objections if other servers want to present
this value if they can easily calculate it) This should not pose any interop
problems either.  Basically, if a client wants to get the accurate setting,
they need to re-issue the CAPA command after authenticating, so i do not
really think it matters too much what was presented in the unauthenticated
state.
Having said that, perhaps a better solution would be to define another
arguement called "USER".
If a client does a CAPA and gets an EXPIRE USER, in the unauthenticated
state, it knows that the server supports per user expiry settings.  It
explicitly informs the user when they need to re-issue the CAPA command
after authentication due to per user options.

>This way a client can decide (because the user has told the client to
>leave mail on the server for a larger number of days)  if it needs to
>reissue CAPA after authenticating and/or warn the user.
*** this is assuming that