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 the client ui has something that allows the user
to specify the number of days to leave mail on the server.  I believe some
clients just have a "leave mail on server" option.  In this case, I guess
the client will always need to reissue the CAPA command after
authentication.

The interop problem I see is the following:
The client is running against a server where expiry is set on a per user
setting.  Let's say the server allows the admin to specify per user expiry
settings. For the client that is logged on, the per user expiry is set to
30.  However, on the server he is running against, there is a user who has
expiry set to 15.  Or it is a server, where the lowest expiry setting is not
available, so the server reports what the theoretical minimum it can be set
to, lets say 1.
Unless things are spelled out explicitly within your draft, I can see a
client issueing only a single CAPA before authentication.  Without it doing
another CAPA after authentication, the client would be spitting out bogus
warnings for the user saying "your messages will be deleted from the server
after 15 days" when really the setting is for 30 days.  Being really
explicit in the draft will ensure that client writers don't make that
mistake.

>
>
>>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.
*** Agreed.  The point I was making is that it does not hurt to call out in
the doc the need to recheck parameters that might change after
authentication.  The wording you have only mentions 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.)
Agreed. And perhaps this adds more fuel to returning USER when there are per
user settings.





From owner-ietf-pop3ext  Thu Jul 23 12:01:22 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA17031
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 12:01:22 -0700 (PDT)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17006
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 11:58:51 -0700 (PDT)
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 LAA20346; Thu, 23 Jul 1998 11:59:17 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101045b1dd33f946d9@[129.46.136.131]>
In-Reply-To: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 23 Jul 1998 11:52:14 -0700
To: "Mike Gahrns" <mikega@microsoft.com>
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 8:46 PM -0700 7/22/98, Mike Gahrns wrote:

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

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

I will modify the draft to clarify this.

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

I'm not sure the added complexity would buy us anything useful.  The
EXPIRE setting can only be a rough guide to the user, never accurate
(without some complex per-message expiration warning mechanism).  Even
if the server presents the currently accurate value for a specific
user, that value could change, the user doesn't know how long the
message has already been on the server, and some servers could change
the expiration period after the user has seen the message.  So I think
the most that can be usefully done with a simple mechanism is to handle
the no-LMOS and indefinite-LMOS states, and for everything else, inform
the user, especially if the user tries to set the client's LMOS setting
to a value within some threshold of what the server's reported EXPIRE
value.

>The interop problem I see is the following:
>The client is running against a server where expiry is set on a per user
>setting.  Let's say the server allows the admin to specify per user expiry
>settings. For the client that is logged on, the per user expiry is set to
>30.  However, on the server he is running against, there is a user who has
>expiry set to 15.  Or it is a server, where the lowest expiry setting is not
>available, so the server reports what the theoretical minimum it can be set
>to, lets say 1.
>Unless things are spelled out explicitly within your draft, I can see a
>client issueing only a single CAPA before authentication.  Without it doing
>another CAPA after authentication, the client would be spitting out bogus
>warnings for the user saying "your messages will be deleted from the server
>after 15 days" when really the setting is for 30 days.  Being really
>explicit in the draft will ensure that client writers don't make that
>mistake.

If a client tries to give warnings at that level of precision, I think
it will often be wrong, unless the server doesn't start the expire
clock until the client has been informed of the presence of the message.

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

>*** Agreed.  The point I was making is that it does not hurt to call out in
>the doc the need to recheck parameters that might change after
>authentication.  The wording you have only mentions down negotiation
>attacks.

I will try and clarify the text, to indicate that some clients may wish
to check for other parameter changes.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
--Chair, Californians for higher taxes, worse government, poorer schools,
  unsafe water, and more crime.--
-------------- Randomly-selected tag: ---------------
Think of your family tonight.  Try to crawl home after the
computer crashes.

From owner-ietf-pop3ext  Thu Jul 23 12:45:46 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA17240
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 12:45:46 -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 MAA17236
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 12:45:45 -0700 (PDT)
Received: from warhol.esys.ca (warhol.esys.ca [198.161.92.20])
	by rembrandt.esys.ca (2.0.4-beta-1/SMS 2.0.4-beta-1) with ESMTP id NAA07539;
	Thu, 23 Jul 1998 13:46:40 -0600
From: Lyndon Nerenberg <lyndon@esys.ca>
Date: Thu, 23 Jul 1998 13:46:39 -0600
To: Randall Gellens <randy@Qualcomm.Com>
Subject: EXPIRE
Cc: ietf-pop3ext@imc.org, Mike Gahrns <mikega@microsoft.com>
In-Reply-To: <v04101045b1dd33f946d9@[129.46.136.131]>
References: <v04101045b1dd33f946d9@[129.46.136.131]> <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com>
Message-ID: <SIMEON.9807231339.A17740@warhol.esys.ca>
X-Mailer: Simeon for Aix Motif Version Mercury a8 Build (11)
MIME-Version: 1.0
Content-Type: Text/PLAIN; CHARSET=US-ASCII
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk


> I'm not sure the added complexity would buy us anything useful.  The
> EXPIRE setting can only be a rough guide to the user, never accurate
> (without some complex per-message expiration warning mechanism).  Even
> if the server presents the currently accurate value for a specific
> user, that value could change, the user doesn't know how long the
> message has already been on the server, and some servers could change
> the expiration period after the user has seen the message.

And for those exact reasons I oppose including EXPIRE. At best the information 
it provides is of marginal utility, and in practice, any incorrect/invalid 
data returned by EXPIRE will most likely result in lost mail. The only way I 
will support EXPIRE is if the protocol spec *requires* the server to enforce 
the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
on day n+1 you say EXPIRE 2, any operations I performed on day n must continue
to work within the constraints of the EXPIRE 30 information you gave me). If 
you cannot guarantee the semantics of operations based on EXPIRE data it 
doesn't belong in the protocol.

--lyndon


From owner-ietf-pop3ext  Thu Jul 23 14:16:34 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA17800
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 14:16:34 -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 OAA17796
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 14:16:31 -0700 (PDT)
Received: from elwood.innosoft.com ("port 56195"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-11 #U3049)
 with SMTP id <01IZQR86OEPM99E6S3@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu,
 23 Jul 1998 14:16:41 PDT
Date: Thu, 23 Jul 1998 14:17:53 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: EXPIRE
In-reply-to: <SIMEON.9807231339.A17740@warhol.esys.ca>
To: Lyndon Nerenberg <lyndon@esys.ca>
Cc: Randall Gellens <randy@Qualcomm.Com>, ietf-pop3ext@imc.org,
        Mike Gahrns <mikega@microsoft.com>
Message-id: <Pine.SOL.3.95.980723140852.8391S-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, 23 Jul 1998, Lyndon Nerenberg wrote:
> And for those exact reasons I oppose including EXPIRE. At best the information 
> it provides is of marginal utility, and in practice, any incorrect/invalid 
> data returned by EXPIRE will most likely result in lost mail. The only way I 
> will support EXPIRE is if the protocol spec *requires* the server to enforce 
> the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
> on day n+1 you say EXPIRE 2, any operations I performed on day n must continue
> to work within the constraints of the EXPIRE 30 information you gave me). If 
> you cannot guarantee the semantics of operations based on EXPIRE data it 
> doesn't belong in the protocol.

A sysadmin can always change policy regardless of what any standard says.
I really wish you had complained during the past year this proposal has
been refined.  It's really frustrating to get lots of review on a
proposal, get it near complete, then go back to the drawing board as
complaints spring out of the woodwork.

If we want to ratchet down one level of complexity from EXPIRE, the next
would be an "AUTODELE" capability which indicates that RETR and/or TOP
cause an implicit DELE.

		- Chris




From owner-ietf-pop3ext  Thu Jul 23 14:55:53 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA17976
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 14:55:53 -0700 (PDT)
Received: from dragon (ppp1666.glas.apc.org [195.218.251.154])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17972
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 14:55:47 -0700 (PDT)
Received: FROM demo.ru ([195.218.251.154]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 24 Jul 1998 01:58:05 +0300
Message-ID: <35B7B1EC.448882AC@demo.ru>
Date: Fri, 24 Jul 1998 01:58: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: <v04101045b1dd33f946d9@[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 8:46 PM -0700 7/22/98, Mike Gahrns wrote:
>
> >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.
>
> I'm not sure the added complexity would buy us anything useful.  The
> EXPIRE setting can only be a rough guide to the user, never accurate
> (without some complex per-message expiration warning mechanism).  Even
> if the server presents the currently accurate value for a specific
> user, that value could change, the user doesn't know how long the
> message has already been on the server, and some servers could change
> the expiration period after the user has seen the message.  So I think
> the most that can be usefully done with a simple mechanism is to handle
> the no-LMOS and indefinite-LMOS states, and for everything else, inform
> the user, especially if the user tries to set the client's LMOS setting
> to a value within some threshold of what the server's reported EXPIRE
> value.

Imagine, for example, that server calculates the minimal EXPIRE value for all
users and returns it in the unauthenticated state. Let user A have EXPIRE value
equal to 0 and user B has EXPIRE >0 (5 for example). Described server will return
EXPIRE 0 in unauthenticated state, but it will not be the truth for user B.
I think that something like EXPIRE USER will help to solve such problem.


One question about EXPIRE 0 : Am I right that all messages will be deleted after
QUIT command. What happens if client disconnects without QUIT? How client can
prevent messages from being deleted?

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  Thu Jul 23 15:14:08 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA18055
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:14:08 -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 PAA18051
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 15:14:07 -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 PAA02304; Thu, 23 Jul 1998 15:14:17 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101005b1dd60098fbf@[129.46.136.131]>
In-Reply-To: <SIMEON.9807231339.A17740@warhol.esys.ca>
References: <v04101045b1dd33f946d9@[129.46.136.131]>
 <v04101045b1dd33f946d9@[129.46.136.131]>
 <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 23 Jul 1998 15:02:25 -0700
To: Lyndon Nerenberg <lyndon@esys.ca>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: EXPIRE
Cc: Randall Gellens <randy@Qualcomm.Com>, ietf-pop3ext@imc.org,
        Mike Gahrns <mikega@microsoft.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

At 12:46 PM -0700 7/23/98, Lyndon Nerenberg wrote:

>> I'm not sure the added complexity would buy us anything useful.  The
>> EXPIRE setting can only be a rough guide to the user, never accurate
>> (without some complex per-message expiration warning mechanism).  Even
>> if the server presents the currently accurate value for a specific
>> user, that value could change, the user doesn't know how long the
>> message has already been on the server, and some servers could change
>> the expiration period after the user has seen the message.
>
>And for those exact reasons I oppose including EXPIRE. At best the
>information
>it provides is of marginal utility, and in practice, any incorrect/invalid
>data returned by EXPIRE will most likely result in lost mail. The only way I
>will support EXPIRE is if the protocol spec *requires* the server to enforce
>the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
>on day n+1 you say EXPIRE 2, any operations I performed on day n must
>continue
>to work within the constraints of the EXPIRE 30 information you gave me). If
>you cannot guarantee the semantics of operations based on EXPIRE data it
>doesn't belong in the protocol.

EXPIRE doesn't cause lost mail.

Currently, POP servers are operated in one of three modes: users are
permitted to leave mail on the server indefinitely (perhaps subject to
maildrop size limits); users are not permitted to leave mail on the
server at all; or users are permitted to leave mail on the server for
some period of time, either from arrival on the server or first notice
to the client, and perhaps subject to earlier or later deletion based
on user action (TOP, RETR).

Currently, there is no standardized, interoperable way to inform users
of the server's operating mode.

With the EXPIRE capability, the server can inform the client as to
which of the three modes is in force, and additionally offer some
guidance regarding the time period for the third mode.  This guidance
should not be used for anything more specific than warnings for setting
client LMOS days.

I think this is a big improvement over the current situation.  It
causes no harm, and it improves things.

Earlier versions of the draft had more three different EXPIRE
capabilities, based on message status.  There was consensus that this
was too complex, that something simpler was needed.

Please keep in mind that this is POP, not IMAP.  This is primarily a
download-and-delete-from-server model.  Leaving mail on the server is
generally used to allow mail to be downloaded to multiple clients.  POP
is not intended to be a generalized mail retention and access protocol.
If a user leaves mail on the server and deletes it from a client,
expecting to be able to download it again later, then mail might be
lost.  This is a misuse of POP.  The EXPIRE capability does not make
this any more likely.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
--Chair, Californians for higher taxes, worse government, poorer schools,
  unsafe water, and more crime.--
-------------- Randomly-selected tag: ---------------
Things get worse under pressure.

From owner-ietf-pop3ext  Thu Jul 23 15:29:47 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA18167
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:29:47 -0700 (PDT)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18163
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 15:29:43 -0700 (PDT)
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 PAA16800; Thu, 23 Jul 1998 15:29:13 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101006b1dd63bc6e21@[129.46.136.131]>
In-Reply-To: <35B7B1EC.448882AC@demo.ru>
References: <v04101045b1dd33f946d9@[129.46.136.131]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 23 Jul 1998 15:22:59 -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 2:58 PM -0700 7/23/98, Alexey Melnikov wrote:

>Imagine, for example, that server calculates the minimal EXPIRE value for all
>users and returns it in the unauthenticated state. Let user A have
>EXPIRE value
>equal to 0 and user B has EXPIRE >0 (5 for example). Described server
>will return
>EXPIRE 0 in unauthenticated state, but it will not be the truth for user B.
>I think that something like EXPIRE USER will help to solve such problem.

If user B's client does not do another CAPA after authenticating, it
might issue a warning if user B has LMOS set, something like "Warning:
your mail server might delete messages immediately".

I don't like the idea of CAPA returning EXPIRE USER, because that
forces the client to reissue CAPA after authenticating.  I could see
perhaps adding USER as an extra token after the value parameter (EXPIRE
5 USER) to indicate that the value might be inaccurate.   But remember
we're talking POP, not IMAP, here.  We want to keep things simple.  How
many servers are going to be operating in a mode such that there is a
number-of-days-per-user expiration policy, which for some users is 0
(immediate deletion) and for others is something else?  Is it worth
cluttering the protocol to be able to do something slightly better in
those few cases?

>One question about EXPIRE 0 : Am I right that all messages will be
>deleted after
>QUIT command. What happens if client disconnects without QUIT? How client can
>prevent messages from being deleted?

EXPIRE 0 means the server MAY delete messages immediately after QUIT.
In actual practice, I would expect message expiration to happen later
in most cases, such as overnight.  The QUIT issue is really no-win.  If
we say that servers can't delete unless the client sends a QUIT,
clients will simply not send QUIT (many don't anyway).  And why should
EXPIRE 0 be different from EXPIRE 1 or EXPIRE 30?

There are widely-deployed servers today which delete messages after a
DELE has been received for them, even if the client does not send QUIT
before the connection closes, even though this is a clear violation of
POP3.

Since there are always edge cases, maybe we should cut EXPIRE from the
draft, which means we live with the status quo, at least until a
replacement draft advances.  I tend to think that would be worse,
because we simply aren't going to be able to solve 100% of the
expiration cases without complexity that doesn't belong in POP.  But if
the consensus is that that's better, I'll do it.



From owner-ietf-pop3ext  Thu Jul 23 15:30:38 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA18186
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:30:38 -0700 (PDT)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18182
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 15:30:36 -0700 (PDT)
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 PAA16827; Thu, 23 Jul 1998 15:29:18 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101007b1dd67e668ba@[129.46.136.131]>
In-Reply-To: 
 <Pine.SOL.3.95.980723140852.8391S-100000@elwood.innosoft.com>
References: <SIMEON.9807231339.A17740@warhol.esys.ca>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Thu, 23 Jul 1998 15:22:47 -0700
To: Chris Newman <Chris.Newman@INNOSOFT.COM>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: EXPIRE
Cc: Lyndon Nerenberg <lyndon@esys.ca>, Randall Gellens <randy@Qualcomm.Com>,
        ietf-pop3ext@imc.org, Mike Gahrns <mikega@microsoft.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

At 2:17 PM -0700 7/23/98, Chris Newman wrote:

>A sysadmin can always change policy regardless of what any standard says.
>I really wish you had complained during the past year this proposal has
>been refined.  It's really frustrating to get lots of review on a
>proposal, get it near complete, then go back to the drawing board as
>complaints spring out of the woodwork.

I agree, especially for edge cases that we really can't solve and
remain simple.

>If we want to ratchet down one level of complexity from EXPIRE, the next
>would be an "AUTODELE" capability which indicates that RETR and/or TOP
>cause an implicit DELE.

That doesn't allow a server to advertise that it expires unseen messages.


From owner-ietf-pop3ext  Thu Jul 23 15:56:20 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA18337
	for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:56: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 PAA18333
	for <ietf-pop3ext@imc.org>; Thu, 23 Jul 1998 15:56:19 -0700 (PDT)
Received: by tide03.microsoft.com; id PAA12595; Thu, 23 Jul 1998 15:56:52 -0700 (PDT)
Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1)
	id xma012588; Thu, 23 Jul 98 15:56:41 -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 QAA19620; Thu, 23 Jul 1998 16:06:53 -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 PKF6X7S1; Thu, 23 Jul 1998 15:56:42 -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 37DWQLZL; Thu, 23 Jul 1998 15:56:44 -0700
Message-ID: <000801bdb68d$97814f80$8dff3b9d@mikega9.dns.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Alexey Melnikov" <mel@demo.ru>, "Randall Gellens" <randy@Qualcomm.Com>
Cc: <ietf-pop3ext@imc.org>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Date: Thu, 23 Jul 1998 15:59:48 -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 2:58 PM -0700 7/23/98, Alexey Melnikov wrote:
>
>>Imagine, for example, that server calculates the minimal EXPIRE value for
all
>>users and returns it in the unauthenticated state. Let user A have
>>EXPIRE value
>>equal to 0 and user B has EXPIRE >0 (5 for example). Described server
>>will return
>>EXPIRE 0 in unauthenticated state, but it will not be the truth for user
B.
>>I think that something like EXPIRE USER will help to solve such problem.
>
>If user B's client does not do another CAPA after authenticating, it
>might issue a warning if user B has LMOS set, something like "Warning:
>your mail server might delete messages immediately".

*** I did not mean to open a rat's nest here.  I thought the idea of EXPIRE
USER off the top my head and I was sitting on the fence as to whether I
should even mention it...  The comments about over engineering things and
adding complexity are always valid concerns, and I am happy with EXPIRE the
way it is.  The area, that I thought that could be improved was adding
clarification text so that everyone knew EXACTLY how it would work.  I think
it needs to be made really clear how it works with per user settings, and
that the client needs to reissue CAPA after authentication.   With the text
Randy will be adding, I am happy with the draft.

Alexey also brings up a good point on EXPIRE 0.  Clarification text and the
example Alexy brings up below should also be added to the spec.

As to Chris's comments, I agree that we don't want re-open and redesign the
whole spec.  I apologize for the late comments, and really all I was looking
for was looking for was more clarification text so that it was crystal clear
exactly how everything worked.  I did not mean to start re-engineering
thigns.  With clarifications added, I am happy with the doc, and think it is
ready for it to go to proposed standard.  It is something we are interested
in implementing.

>>
>Since there are always edge cases, maybe we should cut EXPIRE from the
>draft, which means we live with the status quo, at least until a
>replacement draft advances.  I tend to think that would be worse,
*** I think EXPIRE should stay.  The doc just needed to be more explicit
explaining how it worked.




From owner-ietf-pop3ext  Fri Jul 24 14:27:39 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA14437
	for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:27:39 -0700 (PDT)
Received: from dragon (ppp1663.glas.apc.org [195.218.251.151])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14430
	for <ietf-pop3ext@imc.org>; Fri, 24 Jul 1998 14:27:33 -0700 (PDT)
Received: FROM demo.ru ([195.218.251.151]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 25 Jul 1998 01:25:10 +0300
Message-ID: <35B8FBB4.2435CCAE@demo.ru>
Date: Sat, 25 Jul 1998 01:25:08 +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: <v04101045b1dd33f946d9@[129.46.136.131]> <v04101006b1dd63bc6e21@[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 2:58 PM -0700 7/23/98, Alexey Melnikov wrote:
>
> >Imagine, for example, that server calculates the minimal EXPIRE value for all
> >users and returns it in the unauthenticated state. Let user A have
> >EXPIRE value
> >equal to 0 and user B has EXPIRE >0 (5 for example). Described server
> >will return
> >EXPIRE 0 in unauthenticated state, but it will not be the truth for user B.
> >I think that something like EXPIRE USER will help to solve such problem.
>
> If user B's client does not do another CAPA after authenticating, it
> might issue a warning if user B has LMOS set, something like "Warning:
> your mail server might delete messages immediately".
>
> I don't like the idea of CAPA returning EXPIRE USER, because that
> forces the client to reissue CAPA after authenticating.  I could see
> perhaps adding USER as an extra token after the value parameter (EXPIRE
> 5 USER) to indicate that the value might be inaccurate.   But remember
> we're talking POP, not IMAP, here.  We want to keep things simple.  How
> many servers are going to be operating in a mode such that there is a
> number-of-days-per-user expiration policy, which for some users is 0
> (immediate deletion) and for others is something else?  Is it worth
> cluttering the protocol to be able to do something slightly better in
> those few cases?

I don't want to make things more complex, I just want to make them good from the
beginning (i.e. not to redesign them later). Personally I am happy with EXPIRE 0,
EXPIRE 1 (everything non zero), EXPIRE NEVER, EXPIRE USER.

Extra token is a good way to go.

> There are widely-deployed servers today which delete messages after a
> DELE has been received for them, even if the client does not send QUIT
> before the connection closes, even though this is a clear violation of
> POP3.
>
> Since there are always edge cases, maybe we should cut EXPIRE from the
> draft, which means we live with the status quo, at least until a
> replacement draft advances.  I tend to think that would be worse,
> because we simply aren't going to be able to solve 100% of the
> expiration cases without complexity that doesn't belong in POP.  But if
> the consensus is that that's better, I'll do it.

I agree with Mike : EXPIRE should stay. However I don't mind to place it in a
separate document.


One more comment : I think it is good idea to add more text about how EXPIRE value
is calculated (What Chris wrote before), because it is not obvious for readers,
that didn't take a look at the previous versions of POP3ext draft.

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  Fri Jul 24 14:27:33 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA14429
	for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:27:33 -0700 (PDT)
Received: from dragon (ppp1663.glas.apc.org [195.218.251.151])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14425
	for <ietf-pop3ext@imc.org>; Fri, 24 Jul 1998 14:27:28 -0700 (PDT)
Received: FROM demo.ru ([195.218.251.151]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 25 Jul 1998 01:25:44 +0300
Message-ID: <35B8FBD8.656D4763@demo.ru>
Date: Sat, 25 Jul 1998 01:25:44 +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: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism)
References: <v04101045b1dd33f946d9@[129.46.136.131]> <v04101006b1dd63bc6e21@[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:

> >One question about EXPIRE 0 : Am I right that all messages will be
> >deleted after
> >QUIT command. What happens if client disconnects without QUIT? How client can
> >prevent messages from being deleted?
>
> EXPIRE 0 means the server MAY delete messages immediately after QUIT.
> In actual practice, I would expect message expiration to happen later
> in most cases, such as overnight.  The QUIT issue is really no-win.  If
> we say that servers can't delete unless the client sends a QUIT,
> clients will simply not send QUIT (many don't anyway).  And why should
> EXPIRE 0 be different from EXPIRE 1 or EXPIRE 30?

Here I see a problem.
If server will clear mailbox unconditionally when EXPIRE value is zero (i.e.
server will delete even unseen message) it must not advertise EXPIRE 0.
Let's see what may happen otherwise. Client connects to server using dial-up
TCP/IP connection. Client opens mailbox, starts to download mail, but unexpectedly
ISP hangs up modem connection.
Server discovers that connection is lost and deletes mail.

[I ask to forgive my extreme examples, I have mathematical background :-)]

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  Fri Jul 24 14:44:57 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA14524
	for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:44:57 -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 OAA14520
	for <ietf-pop3ext@imc.org>; Fri, 24 Jul 1998 14:44:56 -0700 (PDT)
Received: by tide03.microsoft.com; id OAA05130; Fri, 24 Jul 1998 14:45:46 -0700 (PDT)
Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1)
	id xma005126; Fri, 24 Jul 98 14:45:22 -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 OAA08398; Fri, 24 Jul 1998 14:55:35 -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 PKF6715M; Fri, 24 Jul 1998 14:45:22 -0700
Received: from MIKEGA9 ([157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9)
	id 37DWQYV1; Fri, 24 Jul 1998 14:45:34 -0700
Message-ID: <000901bdb74c$c62df4e0$8dff3b9d@mikega9.dns.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Alexey Melnikov" <mel@demo.ru>, "Randall Gellens" <randy@Qualcomm.Com>
Cc: <ietf-pop3ext@imc.org>
Subject: Re: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism)
Date: Fri, 24 Jul 1998 14:48:20 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
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

Alexey wrote:
>> EXPIRE 0 means the server MAY delete messages immediately after QUIT.
>> In actual practice, I would expect message expiration to happen later
>> in most cases, such as overnight.  The QUIT issue is really no-win.  If
>> we say that servers can't delete unless the client sends a QUIT,
>> clients will simply not send QUIT (many don't anyway).  And why should
>> EXPIRE 0 be different from EXPIRE 1 or EXPIRE 30?
>
>Here I see a problem.
>If server will clear mailbox unconditionally when EXPIRE value is zero
(i.e.
>server will delete even unseen message) it must not advertise EXPIRE 0.
>Let's see what may happen otherwise. Client connects to server using
dial-up
>TCP/IP connection. Client opens mailbox, starts to download mail, but
unexpectedly
>ISP hangs up modem connection.
>Server discovers that connection is lost and deletes mail.
*** I assumed that if the setting was EXPIRE 0, then the server would only
delete the mail after a message was succesfully downloaded with a RETR.
Assuming that this was Randy's intent, then this could be easily addressed
with another line of text in the document.  This is a good case that Alexey
brings up, and think it should be mentioned in the draft.



From owner-ietf-pop3ext  Mon Jul 27 14:42:44 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA06243
	for ietf-pop3ext-bks; Mon, 27 Jul 1998 14:42:44 -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 OAA06239
	for <ietf-pop3ext@imc.org>; Mon, 27 Jul 1998 14:42:42 -0700 (PDT)
Received: from [129.46.219.133] (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA13670; Mon, 27 Jul 1998 14:43:41 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101004b1e2a434b661@[129.46.219.133]>
In-Reply-To: <000901bdb74c$c62df4e0$8dff3b9d@mikega9.dns.microsoft.com>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Mon, 27 Jul 1998 14:40:15 -0700
To: "Mike Gahrns" <mikega@microsoft.com>
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review
 for POP3 extension mechanism)
Cc: "Alexey Melnikov" <mel@demo.ru>, "Randall Gellens" <randy@Qualcomm.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 2:48 PM -0700 7/24/98, Mike Gahrns wrote:

>I assumed that if the setting was EXPIRE 0, then the server would only
>delete the mail after a message was succesfully downloaded with a RETR.
>Assuming that this was Randy's intent, then this could be easily addressed
>with another line of text in the document.  This is a good case that Alexey
>brings up, and think it should be mentioned in the draft.

I agree.

From owner-ietf-pop3ext  Tue Aug  4 18:34:55 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id SAA12451
	for ietf-pop3ext-bks; Tue, 4 Aug 1998 18:34:55 -0700 (PDT)
Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA12447
	for <ietf-pop3ext@imc.org>; Tue, 4 Aug 1998 18:34:54 -0700 (PDT)
Received: from [129.46.219.133] (randy-mac.qualcomm.com [129.46.219.133]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA23491 for <ietf-pop3ext@imc.org>; Tue, 4 Aug 1998 18:36:41 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v0410111bb1ed647a0538@[129.46.219.133]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 4 Aug 1998 18:25:43 -0700
To: ietf-pop3ext@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: draft-gellens-pop3ext-07.txt
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

Version -07 of the POP3 Extensions draft was just sent in; it should be
posted soon. If anyone wants it before then, let me know and I'll send
a copy by email.

From owner-ietf-pop3ext  Tue Aug 18 12:02:30 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id MAA04990
	for ietf-pop3ext-bks; Tue, 18 Aug 1998 12:02:30 -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 MAA04986
	for <ietf-pop3ext@imc.org>; Tue, 18 Aug 1998 12:02:28 -0700 (PDT)
Received: from elwood.innosoft.com ("port 37779"@ELWOOD.INNOSOFT.COM)
 by INNOSOFT.COM (PMDF V5.1-12 #U3049)
 with SMTP id <01J0QY6P8RK48WWEDL@INNOSOFT.COM> for ietf-pop3ext@imc.org; Tue,
 18 Aug 1998 12:04:03 PDT
Date: Tue, 18 Aug 1998 12:05:07 -0700 (PDT)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: mailrev BOF
To: ietf-pop3ext@imc.org
Message-id: <Pine.SOL.3.95.980818120248.24362O-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

Here is a BOF which should interest participants on this mailing list.
The pop3 extensions proposal and POP3 SASL revision are on the agenda for
brief review and a sense of rough concensus.

----
Review of Short Mail-related Extension Proposals (mailrev)

Thursday, August 27 at 0900-1130
================================

Chair: Chris Newman <chris.newman@innosoft.com>
Timekeeper: volunteer needed who is willing to cut people off
Note Taker: volunteer needed

DESCRIPTION:

Thare are a number of short mail-related individual submissions which
appear not to require the review of a full working group, but would
benefit from some review and a sense of rough concensus.  Each draft
on the agenda will be allocated a fixed (and enforced) time limit for a
brief presentation and technical debate.  At the end of the time
limit, the rough concensus of the room will be measured to see if the
draft in question should go standards track expediously, standards
track with revisions, experimental, punt to WG, defer or discourage.

The success of this effort is likely to depend on the number of
participants who read the drafts in advance.  Most of these drafts are
short.  Draft authors are requested to prepare one overhead
transparency to summarize their proposals.  Some of the drafts listed
below could get IESG approval prior to the BOF, in which case they
will be dropped from the agenda.  The purpose of including drafts in
last call on the list is that if they're not approved by the time the
BOF occurs, then the BOF may give review feedback to ADs which could
help speed approval.

Gzip tar file of documents on agenda:
   <http://www.innosoft.com/iii/persons/chris/mailrev.tgz>

AGENDA:

      Time Limit   Presenter  Pages    Draft Title
intro     5   Chair
review    8   Gunnar Lindburg  21  draft-lindberg-anti-spam-mta-04.txt!
concensus 2   Chair
review   10   Randy Gellens    14  draft-gellens-submit-11.txt!
concensus 2   Chair
review    5   John Myers       6   draft-myers-sasl-pop3-05.txt
concensus 2   Chair
review    5   Randy Gellens    17  draft-gellens-pop3ext-07.txt!
concensus 2   Chair
review    8   Jacob Palme      14? draft-ietf-mailext-new-fields-13.txt!
concensus 2   Chair
review    5   Chris Newman     6   draft-newman-msgheader-originfo-05.txt!
concensus 2   Chair
review    8   Jacob Palme      16? draft-ietf-drums-MHRegistry-03.txt
concensus 2   Chair
review    8   Randy Gellens    8   draft-gellens-on-demand-05.txt
concensus 2   Chair
review    5   Ned Freed        7   draft-freed-gatesec-02.txt
concensus 2   Chair
review    5   L. Lundblade     4   draft-lundblade-1pass-mult-alt-01.txt
concensus 2   Chair
review    8   Chris Newman     10  draft-newman-auth-resp-00.txt
concensus 2   Chair
review    5   Ned Freed        10  draft-newman-deliver-00.txt
concensus 2   Chair
review    3   Chris Newman     4   draft-newman-mime-cdisp-metadata-01.txt
concensus 2   Chair
review    5   Ned Freed        11  draft-freed-bsmtp-01.txt
concensus 2   Chair
review    5   Randy Gellens    7   draft-gellens-format-00.txt
concensus 2   Chair
conclude  15  Chair    What's missing from mail standards that
                       IETF could do next?

! - document is in last call
? - document lacks page numbers, estimate included



From owner-ietf-pop3ext  Tue Aug 18 15:17:06 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id PAA06489
	for ietf-pop3ext-bks; Tue, 18 Aug 1998 15:17:06 -0700 (PDT)
Received: from upm.edu.my (scc.upm.edu.my [202.184.17.1])
	by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA06485
	for <ietf-pop3ext@imc.org>; Tue, 18 Aug 1998 15:17:05 -0700 (PDT)
Received: from inet.upm.edu.my by scc.upm.edu.my (5.x/SMI-SVR4)
	id AA07190; Wed, 19 Aug 1998 06:21:19 -0800
Received: from admin.upm.edu.my by inet.upm.edu.my (5.x/SMI-SVR4)
	id AA16260; Wed, 19 Aug 1998 06:20:13 -0800
Received: from dcrocker by admin.upm.edu.my (SMI-8.6/SMI-SVR4)
	id GAA28666; Wed, 19 Aug 1998 06:19:49 -0800
Message-Id: <199808191419.GAA28666@admin.upm.edu.my>
X-Sender: dcrocker@mail.bayarea.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.44 (Beta)
Date: Tue, 18 Aug 1998 14:58:35 -0700
To: Chris Newman <Chris.Newman@INNOSOFT.COM>
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: Re: mailrev BOF
Cc: ietf-pop3ext@imc.org
In-Reply-To: <Pine.SOL.3.95.980818120248.24362O-100000@elwood.innosoft.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

At 12:05 PM 8/18/98 -0700, Chris Newman wrote:
>Thursday, August 27 at 0900-1130

Damn.  That's directly opposite the fax-over-email working group.  tsk. tsk.

>Timekeeper: volunteer needed who is willing to cut people off

at the knees?

d/ 

_________________________________________________________________________
Dave CROCKER                            <mailto:dcrocker@brandenburg.com>

Tel: +1 408 246 8253     BRANDENBURG CONSULTING      Tel: +60 19 3299 445
675 Spruce Drive                                      P. O.  Box 296, UPM
Sunnyvale, CA 94086       www.brandenburg.com     Serdang, Selangor 43400
United States            Fax:  +1 408 273 6464                   Malaysia

From owner-ietf-pop3ext  Tue Aug 18 21:14:43 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id VAA08739
	for ietf-pop3ext-bks; Tue, 18 Aug 1998 21:14:43 -0700 (PDT)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA08735
	for <ietf-pop3ext@imc.org>; Tue, 18 Aug 1998 21:14:43 -0700 (PDT)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9)
	id <RBC92HMS>; Tue, 18 Aug 1998 21:17:51 -0700
Message-ID: <2FBF98FC7852CF11912A0000000000010C992515@DINO>
From: "Mike Gahrns (Exchange)" <mikega@EXCHANGE.MICROSOFT.com>
To: "'Randall Gellens'" <randy@Qualcomm.Com>, ietf-pop3ext@imc.org
Subject: RE: draft-gellens-pop3ext-07.txt
Date: Tue, 18 Aug 1998 21:17:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

a minor comment on draft-07

Seems that LOGIN-DELAY is a parameter that one might reasonably want to set
on a per-user basis.  e.g. The common users might have a setting of 600
seconds, but the executives might be allowed to poll every minute.  I know
that we have a class of users that demand to get "instant" notification of
messages arriving.

Thus, under "possible differences" for LOGIN-DELAY, you might want to change
no to yes, and then add the spiel you have under "EXPIRE" about if the
server has a per-user setting. e.g.  it SHOULD announce the more accurate
version is in the transaction state and append the USER token to the
LOGIN-DELAY. The server should advertise maximum possible Login delay in the
AUTHORIZATION state.

The UIDL parameter may also fall in this category.  I have heard that some
servers don't allow the UIDL command, because they don't want to have
clients leave mail on the server.  The ability to leave mail on the server,
certainly could be a reasonable per-user setting.  Using just EXPIRE 0 to
indicate the client is not permitted to leave mail on the server won't work
in this case won't work, because you'd be falsing advertising that the
server supported UIDL. 

That said, unlike EXPIRE, where we currently have a per-user settings in our
server, we do not have  a per-user setting for LOGIN-DELAY and UIDL.  Thus I
don't feel strongly about the above.  Since the doc is already structured
for the per-user setting case of EXPIRE, it seemed that it would be simple
to treat LOGIN-DELAY and UIDL similiarly to EXPIRE without really adding any
more complexity to the doc.  I thought I would throw the comment out to the
list, since I could see these as being reasonable per-user settings.  I
definitely do not intend this to re-open the doc and re-start the design of
it. If you feel that these would be reasonable per-user settings, then it
may be worth doing a minor change to note that they might be.  I do not want
to open a pandora's box of new changes to the draft, so pls limit any
comments as to whether it is reasonable that these two parameters might be
settable per-user.

-----Original Message-----
From: Randall Gellens [mailto:randy@Qualcomm.Com]
Sent: Tuesday, August 04, 1998 6:26 PM
To: ietf-pop3ext@imc.org
Subject: draft-gellens-pop3ext-07.txt


Version -07 of the POP3 Extensions draft was just sent in; it should be
posted soon. If anyone wants it before then, let me know and I'll send
a copy by email.

From owner-ietf-pop3ext  Wed Aug 19 11:03:18 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id LAA00781
	for ietf-pop3ext-bks; Wed, 19 Aug 1998 11:03:18 -0700 (PDT)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA00777
	for <ietf-pop3ext@imc.org>; Wed, 19 Aug 1998 11:03:16 -0700 (PDT)
Received: from [129.46.219.133] (randy-mac.qualcomm.com [129.46.219.133]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA02505; Wed, 19 Aug 1998 11:06:17 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <v04101207b200c1b67390@[129.46.219.133]>
In-Reply-To: <2FBF98FC7852CF11912A0000000000010C992515@DINO>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Wed, 19 Aug 1998 10:56:27 -0700
To: "Mike Gahrns (Exchange)" <mikega@EXCHANGE.MICROSOFT.com>,
        "'Randall Gellens'" <randy@Qualcomm.Com>, ietf-pop3ext@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: RE: draft-gellens-pop3ext-07.txt
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:17 PM -0700 8/18/98, Mike Gahrns (Exchange) wrote:

>The UIDL parameter may also fall in this category.  I have heard that some
>servers don't allow the UIDL command, because they don't want to have
>clients leave mail on the server.

If a site doesn't want users to leave mail on the server, disabling
UIDL is a pretty crude way of doing it.  It also makes it harder for
clients to properly download and delete mail in the case of an aborted
session.

That said, I don't have strong feelings either way on per-user UIDL and
LOGIN-DELAY.

From owner-ietf-pop3ext  Sat Dec  5 16:44:05 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id QAA16815
	for ietf-pop3ext-bks; Sat, 5 Dec 1998 16:44:05 -0800 (PST)
Received: from Krill.EHSco.com (inetserv@[209.31.7.48])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA16809
	for <ietf-pop3ext@imc.org>; Sat, 5 Dec 1998 16:44:00 -0800 (PST)
Received: from ehsco.com (Ferret.EHSco.com [209.31.7.45])
          by Krill.EHSco.com (Netscape Messaging Server 3.5)  with ESMTP
          id AAA1D97 for <ietf-pop3ext@imc.org>;
          Sat, 5 Dec 1998 16:49:13 -0800
Message-ID: <3669D470.5473E385@ehsco.com>
Date: Sat, 05 Dec 1998 16:48:49 -0800
From: "Eric A. Hall" <ehall@ehsco.com>
Organization: EHS Company
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Vendors implementing RFC 2449
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk


Are there any shipping products that currently support RFC 2449?

Thanks

-- 
Eric A. Hall                                            ehall@ehsco.com
+1-650-685-0557                                    http://www.ehsco.com

From owner-ietf-pop3ext  Sat Dec  5 20:37:28 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id UAA18016
	for ietf-pop3ext-bks; Sat, 5 Dec 1998 20:37:28 -0800 (PST)
Received: from hexen.qualcomm.co.nz (hexen.qualcomm.co.nz [203.97.157.3])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA18012
	for <ietf-pop3ext@imc.org>; Sat, 5 Dec 1998 20:37:26 -0800 (PST)
Received: from [203.97.157.3] (203.97.157.3) by hexen.qualcomm.co.nz with ESMTP
 (Eudora Internet Mail Server 2.2.1b1); Sun, 6 Dec 1998 17:43:07 +1300
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: glenn@qualcomm.co.nz@mail.qualcomm.co.nz
Message-Id: <v04102f02b28fb9021986@[203.97.157.3]>
In-Reply-To: <3669D470.5473E385@ehsco.com>
Date: Sun, 6 Dec 1998 17:42:58 +1300
To: ietf-pop3ext@imc.org
From: Glenn Anderson <glenn@qualcomm.co.nz>
Subject: Re: Vendors implementing RFC 2449
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

> Are there any shipping products that currently support RFC 2449?

Eudora Internet Mail Server 1.3 and 2.2.

Glenn.
_____________________________________________________________
Glenn Anderson                           glenn@qualcomm.co.nz
Macintosh Internet Programmer    Phone (mobile) +64 25 518661
Eudora Internet Mail Server: http://eudora.qualcomm.com/eims/

From owner-ietf-pop3ext  Sun Dec  6 14:56:48 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id OAA28011
	for ietf-pop3ext-bks; Sun, 6 Dec 1998 14:56:48 -0800 (PST)
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 OAA28007
	for <ietf-pop3ext@imc.org>; Sun, 6 Dec 1998 14:56:47 -0800 (PST)
Received: from execmail.com (zappa.esys.ca [198.161.92.28])
	by rembrandt.esys.ca (2.0.4/SMS 2.0.4) with ESMTP id QAA25886;
	Sun, 6 Dec 1998 16:02:07 -0700
Message-Id: <199812062302.QAA25886@rembrandt.esys.ca>
Date: Sun, 6 Dec 1998 16:02:04 -0700
From: Lyndon Nerenberg <lyndon@execmail.com>
Subject: Re: Vendors implementing RFC 2449
To: ehall@ehsco.com
cc: ietf-pop3ext@imc.org
In-Reply-To: <3669D470.5473E385@ehsco.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

On  5 Dec, Eric A. Hall wrote:
 
> Are there any shipping products that currently support RFC 2449?

Execmail server release 2.1 has full support (including SASL PLAIN,
CRAM-MD5, and KERBEROS_V4). The production release hits the streets in a
week or two.
-- 
Finger lyndon@execmail.com for PGP key.
http://www.execmail.com/


From owner-ietf-pop3ext  Tue Dec  8 11:38:12 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id LAA25979
	for ietf-pop3ext-bks; Tue, 8 Dec 1998 11:38:12 -0800 (PST)
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 LAA25975
	for <ietf-pop3ext@imc.org>; Tue, 8 Dec 1998 11:38:12 -0800 (PST)
Received: from [129.46.219.101] (llundblade-mac.qualcomm.com [129.46.219.101]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA04053; Tue, 8 Dec 1998 11:43:05 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Sender: lgl@hotsun.qualcomm.com
Message-Id: <v04102e04b2933169cab6@[129.46.219.101]>
In-Reply-To: <3669D470.5473E385@ehsco.com>
Date: Tue, 8 Dec 1998 11:42:03 -0800
To: "Eric A. Hall" <ehall@ehsco.com>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: Vendors implementing RFC 2449
Cc: ietf-pop3ext@imc.org
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

Qpopper 3.0  should be out by the end of the year/month and supports it.

LL


At 4:48 PM -0800 12/5/98, Eric A. Hall wrote:
> Are there any shipping products that currently support RFC 2449?
>
> Thanks
>
> --
> Eric A. Hall                                            ehall@ehsco.com
> +1-650-685-0557                                    http://www.ehsco.com


From owner-ietf-pop3ext  Mon Dec 14 16:30:20 1998
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id QAA04161
	for ietf-pop3ext-bks; Mon, 14 Dec 1998 16:30:20 -0800 (PST)
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 QAA04157
	for <ietf-pop3ext@imc.org>; Mon, 14 Dec 1998 16:30:18 -0800 (PST)
Received: from elvira.innosoft.com ([192.160.253.135])
 by INNOSOFT.COM (PMDF V5.2-29 #30494)
 with ESMTPS id <01J5BY44FXXS8ZE1ZD@INNOSOFT.COM> for ietf-pop3ext@imc.org;
 Mon, 14 Dec 1998 14:42:41 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-29 #13579)
 with SMTP id <0F3Z009838CWTB@elvira.innosoft.com> for ietf-pop3ext@imc.org;
 Mon, 14 Dec 1998 14:41:21 -0800 (PST)
Date: Mon, 14 Dec 1998 14:42:43 -0800 (PST)
From: Chris Newman <Chris.Newman@INNOSOFT.COM>
Subject: Re: Vendors implementing RFC 2449
In-reply-to: <3669D470.5473E385@ehsco.com>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: "Eric A. Hall" <ehall@ehsco.com>
Cc: ietf-pop3ext@imc.org
Message-id: <Pine.SOL.3.95.981214144147.4566P-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk

On Sat, 5 Dec 1998, Eric A. Hall wrote:
> Are there any shipping products that currently support RFC 2449?

It is implemented in the shipping version of PMDF 5.2's POP server.  I
haven't done interoperability testing yet, but would be interested.

		- Chris


From owner-ietf-pop3ext  Fri Jan 15 09:56:19 1999
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id IAA23752
	for ietf-pop3ext-bks; Fri, 15 Jan 1999 08:44:17 -0800 (PST)
Received: (from phoffman@localhost)
	by mail.proper.com (8.8.8/8.8.5) id IAA23732;
	Fri, 15 Jan 1999 08:44:13 -0800 (PST)
Date: Fri, 15 Jan 1999 08:44:13 -0800 (PST)
Message-Id: <199901151644.IAA23732@mail.proper.com>
From: List Manager of ietf-pop3ext <ietf-pop3ext-request@imc.org>
To: ietf-pop3ext@imc.org
Subject: How to be removed from this list
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Greetings again. Occasionally, people will sign up for a mailing list and
forget how to be removed. This message is a reminder for those folks.

First off, when you subscribe to a mailing list, you almost always get a
first message from the list owner telling you about the mailing list, and
explaining how to unsubscribe. It is always a good idea to keep those
messages, since you never know when you will need to unsubscribe. This is
particularly useful when you change email addresses, because it is difficult
to unsubscribe from a list after you have a different mailing address.

In the case of this list, the method to unsubscribe is to send a message
to:
     ietf-pop3ext-request@imc.org
with the single word:
     unsubscribe
in the body of the message. This is the same as it always has been.

To make this easier for you, I have crafted this message so that you should
be able to simply reply to this message, and the reply address should be
ietf-pop3ext-request@imc.org (although some mail clients screw this up...).
Remove everything from the body of the reply, and put in the single word:
     unsubscribe

If you have tried this method, and the mailing list software won't let you
unsubscribe, it is probably because your address has changed. In that case,
please send a message to subs@imc.org stating which list (or lists) you
want to unsubscribe from, and what you think your previous address was.
There is a human (that's me!) who will then try to take care of your
request, often within a few days.

--Paul Hoffman, Director
--Internet Mail Consortium

From owner-ietf-pop3ext  Thu Feb 18 11:13:57 1999
Received: (from majordomo@localhost)
	by mail.proper.com (8.8.8/8.8.5) id LAA09468
	for ietf-pop3ext-bks; Thu, 18 Feb 1999 11:13:57 -0800 (PST)
Received: from alms1.fw.att.com (alms1.att.com [192.128.167.146])
	by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA09461
	for <ietf-pop3ext@imc.org>; Thu, 18 Feb 1999 11:13:56 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99])
	by alms1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id OAA18896
	for <ietf-pop3ext@imc.org>; Thu, 18 Feb 1999 14:17:54 -0500 (EST)
Received: from att.com (hansenpc.bl-els.att.com[135.25.111.58](may be forged))
          by maillennium.att.com (labmail) with SMTP
          id <19990218191810un128871eue>; Thu, 18 Feb 1999 19:18:10 +0000
Message-ID: <36CC6600.5D173F20@att.com>
Date: Thu, 18 Feb 1999 14:12:00 -0500
From: Tony Hansen <tony@att.com>
Reply-To: tony@att.com
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: unknown POP verbs: XSENDER and GURL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Does anyone know what the POP3 verbs "GURL" and "XSENDER #" are. They
are showing up in our pop logs.

	Tony Hansen
	tony@att.com

From owner-ietf-pop3ext  Mon Sep 13 11:23:36 1999
Received: by mail.proper.com (8.9.3/8.9.3) id LAA08667
	for ietf-pop3ext-bks; Mon, 13 Sep 1999 11:23:36 -0700 (PDT)
Received: from jade. ([164.124.96.60])
	by mail.proper.com (8.9.3/8.9.3) with SMTP id LAA08493;
	Mon, 13 Sep 1999 11:21:59 -0700 (PDT)
From: searchers@freeola.com
Received: from 164.124.96.60 by jade. (SMI-8.6/SMI-SVR4)
	id DAA15226; Tue, 14 Sep 1999 03:09:15 +0900
Message-Id: <199909131809.DAA15226@jade.>
To: Friend@public.com
Date: Mon, 13 Sep 99 18:21:07 EST
Subject: Missing Links
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Want to find your missing links ?

Want to get more Web Site traffic ?

Want the Secrets of the search Engines ?

Webmaster Free Business Links has them all.

Check it out on : http://209.234.163.159/

Webmaster Free Business Links





++++ Sender & Remove Instructions ++++
Free Business Links
Bevere Close
Worcester
Tel 121 643 2448
++++++++++++++++++++++++++++++++++++
To get removed from our email list please go to
http://www.domainname.com/cleanlist.html
++++++++++++++++++++++++++++++++++++


From owner-ietf-pop3ext  Thu Dec 16 15:21:48 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20189
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 15:21:48 -0800 (PST)
Received: from enterprise.home (IDENT:root@sdu169-200.ppp.algonet.se [195.163.200.169])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20184
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 15:21:45 -0800 (PST)
Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1])
	by enterprise.home (8.9.3/8.9.3) with ESMTP id AAA01533;
	Fri, 17 Dec 1999 00:23:24 +0100
Message-ID: <3859746C.3228F180@rundegren.com>
Date: Fri, 17 Dec 1999 00:23:24 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: POP3 "resume download" extension
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

I've had some thoughts about an extension to POP3 that will let you
resume a download of an interrupted transfer. These days people tend to
send each other messages with large attachment, 2-3Mb is not that
uncommon. Many clients connecting to their ISP, or even the ISP itself,
have their modems improperly setup which causes a flaky phoneline,
resulting in a premature disconnect.

At present, these messages will have to be re-downloaded from scratch
taking a lot of unnecessary bandwidth from the ISP, not to mention
resources within the system itself. Since a majority of the ISPs today
are still using POP3, as opposed to IMAP (mostly due to the reduced
diskspace required when serving a huge numbers of users), I think this
might be a good idea.

I've spent the last week discussing and developing the idea with a few
people, and they are all backing up the idea. I now felt it was time to
take it to this group in order to get a response from a larger group.

We all came to the conslusion that by giving the RETR command a second
argument specifying the offset of where to start downloading would
probably be the best idea. Also, there was a discussion on wheather an
octet range, (a third argument, specifying where the end of the download
should take place) would be appropriate now that we see a lot more
portable internet devices where bandwidth is scarce.

A breakdown on savings:

1) Less consumption of bandwidth
2) Less resources used on the servers
3) ISPs wishing to have this feature will not be forced to deploy an
IMAP server

Not to mention happier users getting their files faster and cheaper (in
Sweden, and most other countries in Europe, flatrates are just a mere
dream).

// Anders Rundegren

From owner-ietf-pop3ext  Thu Dec 16 15:19:40 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20147
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 15:19:40 -0800 (PST)
Received: from enterprise.home (IDENT:root@sdu169-200.ppp.algonet.se [195.163.200.169])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20143
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 15:19:36 -0800 (PST)
Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1])
	by enterprise.home (8.9.3/8.9.3) with ESMTP id AAA01533;
	Fri, 17 Dec 1999 00:23:24 +0100
Message-ID: <3859746C.3228F180@rundegren.com>
Date: Fri, 17 Dec 1999 00:23:24 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: POP3 "resume download" extension
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

I've had some thoughts about an extension to POP3 that will let you
resume a download of an interrupted transfer. These days people tend to
send each other messages with large attachment, 2-3Mb is not that
uncommon. Many clients connecting to their ISP, or even the ISP itself,
have their modems improperly setup which causes a flaky phoneline,
resulting in a premature disconnect.

At present, these messages will have to be re-downloaded from scratch
taking a lot of unnecessary bandwidth from the ISP, not to mention
resources within the system itself. Since a majority of the ISPs today
are still using POP3, as opposed to IMAP (mostly due to the reduced
diskspace required when serving a huge numbers of users), I think this
might be a good idea.

I've spent the last week discussing and developing the idea with a few
people, and they are all backing up the idea. I now felt it was time to
take it to this group in order to get a response from a larger group.

We all came to the conslusion that by giving the RETR command a second
argument specifying the offset of where to start downloading would
probably be the best idea. Also, there was a discussion on wheather an
octet range, (a third argument, specifying where the end of the download
should take place) would be appropriate now that we see a lot more
portable internet devices where bandwidth is scarce.

A breakdown on savings:

1) Less consumption of bandwidth
2) Less resources used on the servers
3) ISPs wishing to have this feature will not be forced to deploy an
IMAP server

Not to mention happier users getting their files faster and cheaper (in
Sweden, and most other countries in Europe, flatrates are just a mere
dream).

// Anders Rundegren

From owner-ietf-pop3ext  Thu Dec 16 16:02:56 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20838
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 16:02:56 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20829
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 16:02:54 -0800 (PST)
Received: from messagingdirect.com (2-018-edm.dial.worldgate.ca [207.167.2.18])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id RAA06648;
	Thu, 16 Dec 1999 17:06:16 -0700
Message-ID: <38597DC0.E4AD59B9@messagingdirect.com>
Date: Thu, 16 Dec 1999 17:03:12 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundegren <anders@rundegren.com>
CC: ietf-pop3ext@imc.org
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Anders Rundegren wrote:
> 
> I've had some thoughts about an extension to POP3 that will let you
> resume a download of an interrupted transfer. These days people tend to
> send each other messages with large attachment, 2-3Mb is not that
> uncommon. Many clients connecting to their ISP, or even the ISP itself,
> have their modems improperly setup which causes a flaky phoneline,
> resulting in a premature disconnect.
...

I understand the reasons for proposing such extension, but the
functionality is already in IMAP4 protocol. My question is : do you want
to make IMAP4 from POP3?

Alexey

From owner-ietf-pop3ext  Thu Dec 16 17:09:08 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21918
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 17:09:08 -0800 (PST)
Received: from enterprise.home (IDENT:root@sdu166-203.ppp.algonet.se [195.163.203.166])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21913
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 17:09:05 -0800 (PST)
Received: from rundegren.com (IDENT:sarek@localhost.localdomain [127.0.0.1])
	by enterprise.home (8.9.3/8.9.3) with ESMTP id CAA00676;
	Fri, 17 Dec 1999 02:12:39 +0100
Message-ID: <38598E07.1230EA61@rundegren.com>
Date: Fri, 17 Dec 1999 02:12:39 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Alexey Melnikov <mel@messagingdirect.com>
CC: ietf-pop3ext@imc.org
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com> <38597DC0.E4AD59B9@messagingdirect.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> Anders Rundegren wrote:
> >
> > I've had some thoughts about an extension to POP3 that will let you
> > resume a download of an interrupted transfer. These days people tend to
> > send each other messages with large attachment, 2-3Mb is not that
> > uncommon. Many clients connecting to their ISP, or even the ISP itself,
> > have their modems improperly setup which causes a flaky phoneline,
> > resulting in a premature disconnect.
> ...
> 
> I understand the reasons for proposing such extension, but the
> functionality is already in IMAP4 protocol. My question is : do you want
> to make IMAP4 from POP3?
> 
> Alexey

Not at all, this feature wouldn't break POP3's download-and-delete
model, it doesn't change any states on the server either. It's in its
own simplicity just an extension to the RETR command. I don't think
adding this feature would make POP3 close in on the IMAP model.

// Anders

From owner-ietf-pop3ext  Thu Dec 16 21:19:46 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA18042
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 21:19:46 -0800 (PST)
Received: from ns.hyd.rampnet.com ([208.247.183.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18038
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 21:19:41 -0800 (PST)
Received: from ns.hyd.rampnet.com ([208.247.183.98])
	by ns.hyd.rampnet.com (8.8.7/8.8.5) with ESMTP id KAA00694;
	Fri, 17 Dec 1999 10:43:15 +0530
Message-ID: <385A12D2.3BDD279E@rampnet.com>
Date: Fri, 17 Dec 1999 05:09:14 +0000
From: "R.Srinivasan" <vrs@rampnet.com>
Reply-To: vrs@rampnet.com
Organization: Ramp Network (p) Ltd
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundegren <anders@rundegren.com>
CC: "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Anders Rundegren wrote:

> I've had some thoughts about an extension to POP3 that will let you
> resume a download of an interrupted transfer. These days people tend to
> send each other messages with large attachment, 2-3Mb is not that
> uncommon. Many clients connecting to their ISP, or even the ISP itself,
> have their modems improperly setup which causes a flaky phoneline,
> resulting in a premature disconnect.
>
> At present, these messages will have to be re-downloaded from scratch
> taking a lot of unnecessary bandwidth from the ISP, not to mention
> resources within the system itself. Since a majority of the ISPs today
> are still using POP3, as opposed to IMAP (mostly due to the reduced
> diskspace required when serving a huge numbers of users), I think this
> might be a good idea.
>
> I've spent the last week discussing and developing the idea with a few
> people, and they are all backing up the idea. I now felt it was time to
> take it to this group in order to get a response from a larger group.
>
> We all came to the conslusion that by giving the RETR command a second
> argument specifying the offset of where to start downloading would
> probably be the best idea. Also, there was a discussion on wheather an
> octet range, (a third argument, specifying where the end of the download
> should take place) would be appropriate now that we see a lot more
> portable internet devices where bandwidth is scarce.
>
> A breakdown on savings:
>
> 1) Less consumption of bandwidth
> 2) Less resources used on the servers
> 3) ISPs wishing to have this feature will not be forced to deploy an
> IMAP server
>
> Not to mention happier users getting their files faster and cheaper (in
> Sweden, and most other countries in Europe, flatrates are just a mere
> dream).
>
> // Anders Rundegren

Yes, i guess this would be a good idea to have this option in POP3. I agree
with
Anders that it would not be like IMAP4. Probably i guess we should go ahead
and propose this feature.

Srinivasan



From owner-ietf-pop3ext  Thu Dec 16 22:19:22 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21461
	for ietf-pop3ext-bks; Thu, 16 Dec 1999 22:19:22 -0800 (PST)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21457
	for <ietf-pop3ext@imc.org>; Thu, 16 Dec 1999 22:19:21 -0800 (PST)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA02584;
        Fri, 17 Dec 1999 01:22:26 -0500 (EST)
Message-Id: <199912170622.BAA02584@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: vrs@rampnet.com
cc: Anders Rundegren <anders@rundegren.com>,
        "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension 
In-reply-to: Your message of "Fri, 17 Dec 1999 05:09:14 GMT."
             <385A12D2.3BDD279E@rampnet.com> 
X-SUBJECT-MSG-FROM: "R.Srinivasan" <vrs@rampnet.com> 
Date: Fri, 17 Dec 1999 01:22:26 -0500
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

fwiw, a lot of folks are likely to push back on defining any new extension
to pop.  there is a feeling that two mail access protocols are too many,
and that new effort should be invested into imap rather than pop.
but that doesn't mean you shouldn't try, just be aware that you may get
some pushback, perhaps enough that it doesn't fly.

if you do define an extension for partial message retrieval I think it 
should allow partial message retrieval (e.g. byte count) rather than 
just resume.  that way, you don't have to drop a connection to 
get the server to stop sending you a message.  I also suspect it should 
be a different command rather than an extension to RETR - with the latter 
approach my guess is you're likely to run into some compatibility problems 
with old servers.   

but something like 

PRET <msgno> <start> <max-length>

(PRET = "partial retrieve")

where <start> is not a byte offset but a cookie that is returned
from a previous PRET command (if you want to resume here, use this cookie
in the next PRET command)...that would allow for different back-end 
representations.  only problem is it doesn't work well for pipelining -
you can't send request #N until  you've received response #N-1 -
but maybe someone will think of something.

Keith

From owner-ietf-pop3ext  Fri Dec 17 00:14:48 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id AAA28604
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 00:14:48 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA28599
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 00:14:46 -0800 (PST)
Received: from messagingdirect.com (2-109-edm.dial.worldgate.ca [207.167.2.109])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id BAA07884;
	Fri, 17 Dec 1999 01:18:34 -0700
Message-ID: <3859F120.434073C2@messagingdirect.com>
Date: Fri, 17 Dec 1999 01:15:28 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: vrs@rampnet.com
CC: anders@rundegren.com, ietf-pop3ext@imc.org
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com> <385A12D2.3BDD279E@rampnet.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> Yes, i guess this would be a good idea to have this option in POP3. I agree
> with Anders that it would not be like IMAP4. Probably i guess we should go ahead
> and propose this feature.

Don't get me wrong : I agree that proposed extension is useful. (And it
would be dead easy to implement the extended RETR in our server, for
example.) I just concerned about adding too much advanced functionality
to POP3.
IMAP community spent several years convincing client writers to do this
right. You have to convince POP3 server and client writers that they
must add such functionality to their products. 

Alexey

From owner-ietf-pop3ext  Fri Dec 17 06:01:05 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07237
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:01:05 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07233
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 06:01:03 -0800 (PST)
Received: from ieca.com (mva-aa-119.capu.net [207.226.159.119])
	by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA10573;
	Fri, 17 Dec 1999 09:04:46 -0500
Message-ID: <3859B650.BDB07B0C@ieca.com>
Date: Fri, 17 Dec 1999 19:04:32 +0500
From: "Bonatti, Chris" <bonattic@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>, Anders Rundegren <anders@rundegren.com>,
        Alexey Melnikov <mel@messagingdirect.com>
CC: "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension
References: <199912170622.BAA02584@astro.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Anders Rundegren wrote:

> Not at all, this feature wouldn't break POP3's download-and-delete
> model, it doesn't change any states on the server either. It's in its
> own simplicity just an extension to the RETR command. I don't think
> adding this feature would make POP3 close in on the IMAP model.
>

Anders,

    I agree that this would be a very useful and simple extension.  I would
support it's definition.


Later, Keith Moore wrote:

> if you do define an extension for partial message retrieval I think it
> should allow partial message retrieval (e.g. byte count) rather than
> just resume.  that way, you don't have to drop a connection to
> get the server to stop sending you a message.  I also suspect it should
> be a different command rather than an extension to RETR - with the latter
> approach my guess is you're likely to run into some compatibility problems
> with old servers.
>

Keith,

    This also sounds okay, but it certainly could complicate deployment.  What
would the benefit be if the assumption (for a large message) is a binary
attachment?  Half a message just wouldn't do anybody much good.


Later still, Alexey Melnikov wrote:

> IMAP community spent several years convincing client writers to do this
> right. You have to convince POP3 server and client writers that they
> must add such functionality to their products.
>

Alexey,

    Yes, this is likely to be necessary, but it will either sell or it won't.
I don't think that should be a barrier to *defining* the extension.  Our
servers are full of RFCs and drafts that went nowhere in the final analysis.
Personally, I think that this will sell.  It provides a measure of
"robustness" in a simple package, and there is a great interest in buying
stronger, better, etc.

Chris



 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti             15309 Turkey Foot Road  |
 |  Principal Engineer              Darnestown, Md 20878-3640  |
 |  bonattic@ieca.com   Tel: 301-208-2349   Fax: 301-208-2379  |
 ---------------------------------------------------------------




From owner-ietf-pop3ext  Fri Dec 17 06:07:50 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07360
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:07:50 -0800 (PST)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07356
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 06:07:49 -0800 (PST)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA18906;
        Fri, 17 Dec 1999 09:10:43 -0500 (EST)
Message-Id: <199912171410.JAA18906@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Bonatti, Chris" <bonattic@ieca.com>
cc: Keith Moore <moore@cs.utk.edu>, Anders Rundegren <anders@rundegren.com>,
        Alexey Melnikov <mel@messagingdirect.com>,
        "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension 
In-reply-to: Your message of "Fri, 17 Dec 1999 19:04:32 +0500."
             <3859B650.BDB07B0C@ieca.com> 
Date: Fri, 17 Dec 1999 09:10:43 -0500
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> > if you do define an extension for partial message retrieval I think it
> > should allow partial message retrieval (e.g. byte count) rather than
> > just resume.  that way, you don't have to drop a connection to
> > get the server to stop sending you a message.  I also suspect it should
> > be a different command rather than an extension to RETR - with the latter
> > approach my guess is you're likely to run into some compatibility problems
> > with old servers.
> >
> 
> Keith,
> 
>     This also sounds okay, but it certainly could complicate deployment.  What
> would the benefit be if the assumption (for a large message) is a binary
> attachment?  Half a message just wouldn't do anybody much good.

what I had in mind was being able to download a message in chunks with a 
fairly easy way for the client to say 'stop sending any more chunks'.  
having the client close and reopen the connection is slow and wasteful.
so if the client can ask for (say) the first 50k, then the second 50k,
etc. and the user wants to stop downloading after a few seconds, then
all the client has to do is stop asking for more chunks.  but it seems
like you do want to be able to pipeline it.

Keith

From owner-ietf-pop3ext  Fri Dec 17 06:28:36 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07661
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 06:28:36 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07657
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 06:28:34 -0800 (PST)
Received: from ieca.com (mva-aa-033.capu.net [207.226.159.33])
	by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id JAA11050;
	Fri, 17 Dec 1999 09:32:26 -0500
Message-ID: <3859BCD9.D41719E7@ieca.com>
Date: Fri, 17 Dec 1999 19:32:26 +0500
From: "Bonatti, Chris" <bonattic@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
CC: "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension
References: <199912171410.JAA18906@astro.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>



Keith Moore wrote:

> what I had in mind was being able to download a message in chunks with a
> fairly easy way for the client to say 'stop sending any more chunks'.
> having the client close and reopen the connection is slow and wasteful.
> so if the client can ask for (say) the first 50k, then the second 50k,
> etc. and the user wants to stop downloading after a few seconds, then
> all the client has to do is stop asking for more chunks.  but it seems
> like you do want to be able to pipeline it.
>

Yes, I see what you mean.  I agree that punting the connection seems inefficient.
You could also do such a thing as a RETR extension, but it would be sufficiently
incompatible that it wouldn't really be any different from a separate command.

Pipelining this sounds hard.  It would be cleaner to check the size of the messages
before beginning the RETR, thereby deciding what exceed your threshold.  However, I
suspect that a user wouldn't always see it that way.  Sometimes you end up on a
clogged channel or a slow connection that you don't expect.  So we need to look at
the problem strictly from the user abort point of view.

Thinking about pipelining, though, how does this sound: POP3 is normally a
half-duplex-like dialog.  Suppose we allow an allowed a received command sequence
(like maybe "!NEXT") to queue an interrupt of the download at the next chunk.  This
would require the server to at least nominally *listen* while sending, but since it
would not have to process it until the next chunk-boundary was reached the listening
would not be too onerous.  How difficult would something like this be to implement?

Chris




From owner-ietf-pop3ext  Fri Dec 17 07:03:27 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08196
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 07:03:27 -0800 (PST)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08192
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 07:03:26 -0800 (PST)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA19276;
        Fri, 17 Dec 1999 10:06:22 -0500 (EST)
Message-Id: <199912171506.KAA19276@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Bonatti, Chris" <bonattic@ieca.com>
cc: Keith Moore <moore@cs.utk.edu>,
        "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension 
In-reply-to: Your message of "Fri, 17 Dec 1999 19:32:26 +0500."
             <3859BCD9.D41719E7@ieca.com> 
Date: Fri, 17 Dec 1999 10:06:22 -0500
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> Thinking about pipelining, though, how does this sound: POP3 is normally a
> half-duplex-like dialog.  Suppose we allow an allowed a received command 
> sequence (like maybe "!NEXT") to queue an interrupt of the download at 
> the next chunk.  

If you're suggesting that servers do out-of-order command processing, 
I don't think that's the way to go.

The goal of pipelining chunk requests is to get maximum download speed
while still having an early abort capability.  Say a client is trying
to download a 1MB message in 100K chunks.  If it has to get the response 
from each chunk request before asking for the next the next chunk,
there's a round-trip delay after every chunk which could take as long
as downloading 100K of data.  So having partial retrieve could make the
overall download take twice as long.  OTOH, if the client can queue 
ahead several PRET requests then it can make sure that there is always
a request outstanding in the server's queue...so there is no waiting.
but it can still abort a download within the time it takes for the 
server to deal with the number of queued-ahead requests ... which is
much better than waiting for the entire message and (if tuned right)
also better than closing and reopening the connection.

maybe what is needed are two "special cookies" for PRET:

cookie # means "start at beginning of message"
cookie @ means "continue transfer following the last PRET"

however, this adds some state to the server.  what happens if a client
is displaying multiple messages from the same server in different windows,
and the user keeps scrolling the windows around?  the client (having 
initially only downloaded enough of each message to display the first
page or two of each) might then want to interleave PRETs from one message 
with PRETs from another.  

Keith

Keith

From owner-ietf-pop3ext  Fri Dec 17 08:02:45 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09232
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 08:02:45 -0800 (PST)
Received: from smtp-a.capu.net (IDENT:root@smtp-a.capu.net [205.177.76.122])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09228
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 08:02:43 -0800 (PST)
Received: from ieca.com (mva-aa-029.capu.net [207.226.159.29])
	by smtp-a.capu.net (8.9.3/8.9.3) with ESMTP id LAA16035;
	Fri, 17 Dec 1999 11:06:35 -0500
Message-ID: <3859D2E4.2B02DDA9@ieca.com>
Date: Fri, 17 Dec 1999 21:06:28 +0500
From: "Bonatti, Chris" <bonattic@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Moore <moore@cs.utk.edu>
CC: "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension
References: <199912171506.KAA19276@astro.cs.utk.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>



Keith Moore wrote:

> > Thinking about pipelining, though, how does this sound: POP3 is normally a
> > half-duplex-like dialog.  Suppose we allow an allowed a received command
> > sequence (like maybe "!NEXT") to queue an interrupt of the download at
> > the next chunk.
>
> If you're suggesting that servers do out-of-order command processing,
> I don't think that's the way to go.
>

No, I didn't really mean out-of-order command processing.  What I meant is that
there would be a recurring state at the end of every chunk in which the server
checks to see whether it has received an "interrupt" command.  If it has, it
could skip to the start of the next message.  If it hasn't, it would continue
with the next chunk.

This approach has the advantage that both the client and server need do nothing
at all if the download is to continue.  I just don't know how hard the
"listenening" is for most server implementations.

Chris




From owner-ietf-pop3ext  Fri Dec 17 09:48:56 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10959
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 09:48:56 -0800 (PST)
Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10955
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 09:48:54 -0800 (PST)
Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id JAA01864; Fri, 17 Dec 1999 09:52:25 -0800 (PST)
Message-Id: <4.2.2.19991217095326.00c04230@hotsun.qualcomm.com>
X-Sender: lgl@hotsun.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 17 Dec 1999 09:59:41 -0800
To: Alexey Melnikov <mel@messagingdirect.com>,
        Anders Rundegren <anders@rundegren.com>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: POP3 "resume download" extension
Cc: ietf-pop3ext@imc.org
In-Reply-To: <38597DC0.E4AD59B9@messagingdirect.com>
References: <3859746C.3228F180@rundegren.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

At 05:03 PM 12/16/99 -0700, Alexey Melnikov wrote:

>I understand the reasons for proposing such extension, but the
>functionality is already in IMAP4 protocol. My question is : do you want
>to make IMAP4 from POP3?
>
>Alexey

We clearly don't want to make POP3 into IMAP4 for many many reasons :-)

One thing Chris Newman and myself were discussing a bit was a profile of 
IMAP that just supported the features needed to do off-line mode in IMAP. 
The idea is that these servers would address the problems ISP's have with 
deploying full IMAP (performance and resource issues, and complexity for 
set up, the end user and customer support).

Then we could create a pop extension that means "don't use POP, offline 
IMAP supported at port XXX" and make the transition seamless for the user.

LL


From owner-ietf-pop3ext  Fri Dec 17 10:03:02 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11177
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 10:03:02 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11173
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 10:03:01 -0800 (PST)
Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id LAA08561;
	Fri, 17 Dec 1999 11:06:46 -0700
Message-ID: <385A7AFD.A8B6718B@messagingdirect.com>
Date: Fri, 17 Dec 1999 11:03:42 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Laurence Lundblade <lgl@Qualcomm.Com>
CC: ietf-pop3ext@imc.org
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com> <4.2.2.19991217095326.00c04230@hotsun.qualcomm.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Laurence Lundblade wrote:
> We clearly don't want to make POP3 into IMAP4 for many many reasons :-)
> 
> One thing Chris Newman and myself were discussing a bit was a profile of
> IMAP that just supported the features needed to do off-line mode in IMAP.
> The idea is that these servers would address the problems ISP's have with
> deploying full IMAP (performance and resource issues, and complexity for
> set up, the end user and customer support).

I will vote in favour of this proposal!

> Then we could create a pop extension that means "don't use POP, offline
> IMAP supported at port XXX" and make the transition seamless for the user.

Alexey

From owner-ietf-pop3ext  Fri Dec 17 10:05:35 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11202
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 10:05:35 -0800 (PST)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11198
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 10:05:33 -0800 (PST)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA19725;
        Fri, 17 Dec 1999 13:08:30 -0500 (EST)
Message-Id: <199912171808.NAA19725@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: "Bonatti, Chris" <bonattic@ieca.com>
cc: Keith Moore <moore@cs.utk.edu>,
        "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Subject: Re: POP3 "resume download" extension 
In-reply-to: Your message of "Fri, 17 Dec 1999 21:06:28 +0500."
             <3859D2E4.2B02DDA9@ieca.com> 
Date: Fri, 17 Dec 1999 13:08:30 -0500
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> > > Thinking about pipelining, though, how does this sound: POP3 is normally a
> > > half-duplex-like dialog.  Suppose we allow an allowed a received command
> > > sequence (like maybe "!NEXT") to queue an interrupt of the download at
> > > the next chunk.
> >
> > If you're suggesting that servers do out-of-order command processing,
> > I don't think that's the way to go.
> >
> 
> No, I didn't really mean out-of-order command processing.  What I meant is 
> that there would be a recurring state at the end of every chunk in 
> which the server checks to see whether it has received an "interrupt" 
> command.  

I think there would be significant pushback against changes to the basic
POP request-response command structure...it would be difficult to retro-fit
existing servers to support it and once you get away from simple 
request-response it's fairly easy to introduce silly states.

(e.g.: suppose a client wants to issue several commands at once without
waiting for a response, and then later on needs to interrupt a transfer.
by the time the server gets the interrupt, it's working on a different
transfer already, and it interrupts the wrong one.) 

Keith

From owner-ietf-pop3ext  Fri Dec 17 13:40:10 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13858
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 13:40:10 -0800 (PST)
Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA13852
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 13:40:09 -0800 (PST)
Received: from lombok (llundbla.qualcomm.com [129.46.219.60]) by jittlov.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id NAA01386; Fri, 17 Dec 1999 13:43:53 -0800 (PST)
Message-Id: <4.2.2.19991217133728.00b51710@hotsun.qualcomm.com>
X-Sender: lgl@hotsun.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Fri, 17 Dec 1999 13:50:07 -0800
To: "Bonatti, Chris" <bonattic@ieca.com>, Keith Moore <moore@cs.utk.edu>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: POP3 "resume download" extension
Cc: "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
In-Reply-To: <3859D2E4.2B02DDA9@ieca.com>
References: <199912171506.KAA19276@astro.cs.utk.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

At 09:06 PM 12/17/99 +0500, Bonatti, Chris wrote:


>Keith Moore wrote:
>
> > > Thinking about pipelining, though, how does this sound: POP3 is 
> normally a
> > > half-duplex-like dialog.  Suppose we allow an allowed a received command
> > > sequence (like maybe "!NEXT") to queue an interrupt of the download at
> > > the next chunk.
> >
> > If you're suggesting that servers do out-of-order command processing,
> > I don't think that's the way to go.
> >
>
>No, I didn't really mean out-of-order command processing.  What I meant is 
>that
>there would be a recurring state at the end of every chunk in which the server
>checks to see whether it has received an "interrupt" command.  If it has, it
>could skip to the start of the next message.  If it hasn't, it would continue
>with the next chunk.

So the client wouldn't request the chunks. The server would just send in 
chunks and look for aborts every once in a while.

If you're doing one RETR after another and you're pipelining you're going 
to have at least one command (a RETR) waiting at the in queue on the server 
to be processed. If you send an ABORT it will be behind the RETR in the 
queue so you'd have to process it out of order.

Processing out of order would be bad because it would make the server much 
more difficult to implement. POP servers can be very simple now.

Being able to request chunks with a RETR command would help aborts for long 
messages. It seems in an ideal chunked implementation the client would have 
some idea of the bytes/sec capacity of pipe is and only have requests for 
enough bytes to fill the pipe outstanding. That way you only wait on the 
order of one round trip for an abort. Since the size of a message is 
typically much larger than the number of bytes to fill the byte, chunking 
requests win.

How easy it would be to get to an ideal implementation is another matter. 
Pipes are very bursty and through put is hard to characterize. I suspect 
one would still be able to get much faster abort times with chunked 
requests without compromising overall download speed though.

LL



From owner-ietf-pop3ext  Fri Dec 17 14:48:50 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA15005
	for ietf-pop3ext-bks; Fri, 17 Dec 1999 14:48:50 -0800 (PST)
Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA15000
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 14:48:49 -0800 (PST)
Received: from dns.maillennium.att.com ([135.25.114.99])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA29737
	for <ietf-pop3ext@imc.org>; Fri, 17 Dec 1999 17:51:53 -0500 (EST)
Received: from att.com ([135.197.90.137])
          by maillennium.att.com (labmail) with SMTP
          id <1999121722492909920993bpe>; Fri, 17 Dec 1999 22:49:29 +0000
Message-ID: <385ABE3A.9043126B@att.com>
Date: Fri, 17 Dec 1999 17:50:34 -0500
From: Tony Hansen <tony@att.com>
Organization: AT&T Laboratories
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundegren <anders@rundegren.com>
CC: ietf-pop3ext@imc.org
Subject: Re: POP3 "resume download" extension
References: <3859746C.3228F180@rundegren.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Anders Rundegren wrote:
> 
> I've had some thoughts about an extension to POP3 that will let you
> resume a download of an interrupted transfer. These days people tend to
> send each other messages with large attachment, 2-3Mb is not that
> uncommon. Many clients connecting to their ISP, or even the ISP itself,
> have their modems improperly setup which causes a flaky phoneline,
> resulting in a premature disconnect.
> 
> At present, these messages will have to be re-downloaded from scratch
> taking a lot of unnecessary bandwidth from the ISP, not to mention
> resources within the system itself. Since a majority of the ISPs today
> are still using POP3, as opposed to IMAP (mostly due to the reduced
> diskspace required when serving a huge numbers of users), I think this
> might be a good idea.

An interesting thing about IMAP is that is fully supports the model of
message management that POP provides where messages are moved from the
server to the local machine and deleted from the server. However, very
few clients are built to support using IMAP in that fashion. They almost
all assume that if you're using IMAP, you only want to keep your
messages remotely. If an IMAP server were to disallow remote folders,
you'd have essentially the equivalent of a fancy POP server. And it
would have no higher diskspace requirements than any POP server would
require.

	Tony Hansen
	tony@att.com

From owner-ietf-pop3ext  Sun Dec 19 14:03:56 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18366
	for ietf-pop3ext-bks; Sun, 19 Dec 1999 14:03:56 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18362
	for <ietf-pop3ext@imc.org>; Sun, 19 Dec 1999 14:03:55 -0800 (PST)
Received: from messagingdirect.com (2-042-edm.dial.worldgate.ca [207.167.2.42])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id PAA12636;
	Sun, 19 Dec 1999 15:07:58 -0700
Message-ID: <385D5287.23558E0@messagingdirect.com>
Date: Sun, 19 Dec 1999 14:47:51 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: POP3 Extensions Mailing List <ietf-pop3ext@imc.org>
Subject: Survey : What clients/servers support CAPA?
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

I am going to create another web page, that list POP3 extensions
supported by different clients/servers.

The starting list:

Clients that supports CAPA:

Eudora,
Execmail

Servers that supports CAPA:

QPopper,
CMU POP3,
M-Store POP3 (formerly SMS)

Alexey



From owner-ietf-pop3ext  Sun Dec 19 14:33:44 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18654
	for ietf-pop3ext-bks; Sun, 19 Dec 1999 14:33:44 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18650
	for <ietf-pop3ext@imc.org>; Sun, 19 Dec 1999 14:33:42 -0800 (PST)
Received: from messagingdirect.com (2-042-edm.dial.worldgate.ca [207.167.2.42])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id PAA12756;
	Sun, 19 Dec 1999 15:37:46 -0700
Message-ID: <385D5D7E.E758698E@messagingdirect.com>
Date: Sun, 19 Dec 1999 15:34:38 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: POP3 Extensions Mailing List <ietf-pop3ext@imc.org>
Subject: Re: Survey : What clients/servers support CAPA?
References: <385D5287.23558E0@messagingdirect.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

The information that particular product DOESN'T support CAPA command is
also welcomed.

Alexey Melnikov wrote:
> 
> I am going to create another web page, that list POP3 extensions
> supported by different clients/servers.
> 
> The starting list:
> 
> Clients that supports CAPA:
> 
> Eudora,
> Execmail
> 
> Servers that supports CAPA:
> 
> QPopper,
> CMU POP3,
> M-Store POP3 (formerly SMS)
> 
> Alexey

From owner-ietf-pop3ext  Mon Dec 20 10:31:39 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24693
	for ietf-pop3ext-bks; Mon, 20 Dec 1999 10:31:39 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA24688
	for <ietf-pop3ext@imc.org>; Mon, 20 Dec 1999 10:31:38 -0800 (PST)
Received: from messagingdirect.com (dhcp198-53.esys.ca [198.161.92.53])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id LAA14679;
	Mon, 20 Dec 1999 11:35:46 -0700
Message-ID: <385E7645.A14EB093@messagingdirect.com>
Date: Mon, 20 Dec 1999 11:32:37 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: POP3 Extensions Mailing List <ietf-pop3ext@imc.org>
Subject: Re: Survey : What clients/servers support CAPA?
References: <385D5287.23558E0@messagingdirect.com> <v04220801b483a66b9142@[203.97.196.100]>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

UW-2000 will support CAPA according to Mark Crispin

Alexey

From owner-ietf-pop3ext  Fri Dec 24 04:30:17 1999
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA24734
	for ietf-pop3ext-bks; Fri, 24 Dec 1999 04:30:17 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA24730
	for <ietf-pop3ext@imc.org>; Fri, 24 Dec 1999 04:30:15 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id GAA03005 for <ietf-pop3ext@imc.org>; Fri, 24 Dec 1999 06:34:16 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id PAA03404 for ietf-pop3ext@imc.org; Fri, 24 Dec 1999 15:24:32 +0300
From: Solar Designer <solar@false.com>
Message-Id: <199912241224.PAA03404@false.com>
Subject: RFC 2449: clarifications needed
To: ietf-pop3ext@imc.org
Date: Fri, 24 Dec 1999 15:24:31 +0300 (MSK)
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Hi,

As this list is once again active, I've decided to post my thoughts
and a few questions on the changes to POP3 defined by RFC 2449.

1. "This specification increases the length restrictions on commands
and parameters imposed by RFC 1939.

   The maximum length of a command is increased from 47 characters (4
   character command, single space, 40 character argument, CRLF) to 255
   octets, including the terminating CRLF."

This looks like a misinterpretation of RFC 1939 to me.  Here's what
it used to say:

"  Commands in the POP3 consist of a case-insensitive keyword, possibly
   followed by one or more arguments.  All commands are terminated by a
   CRLF pair.  Keywords and arguments consist of printable ASCII
   characters.  Keywords and arguments are each separated by a single
   SPACE character.  Keywords are three or four characters long. Each
   argument may be up to 40 characters long."

Even if POP3 commands defined by RFC 1939 accepted at most one
argument (which isn't the case: TOP has two arguments), this doesn't
imply that POP3 servers were allowed not to parse longer commands
correctly.  In particular, I consider a server that processes one
long command as two or more short ones not fully RFC 1939 compliant.
I was specifically looking for a command length limit in RFC 1939
when developing my POP3 server, and came to the conclusion that
there's none, even though this may require extra code.

Basically, while I like the fact that a length limit is now defined,
I believe that our new RFC is wrong in saying that it "increases" the
length restrictions.  In reality, RFC 2449 compliant servers are not
necessarily fully compliant to RFC 1939: they are now allowed to not
process commands longer than 255 octets correctly (in the 1939 sense).

2. RFC 1939 didn't specify that POP3 clients are required to wait for
a response before issuing another command.  It only said that the
client and server exchange commands and responses.  The "exchange"
doesn't sound like a permission to not support pipelined commands to
me, even though there're many (broken) servers that don't and this
can be tricky to implement if AUTHORIZATION and TRANSACTION states
are implemented with different processes or even physical servers.

The addition of the PIPELINING capability effectively makes these old
POP3 servers (which didn't support pipelining) RFC compliant.

I admit that this one issue isn't very clear.  Some might say that
"exchange" implies waiting for a response.  I would prefer a MUST,
though.

3. This requirement with PIPELINING seems to be too strict: "If
either the client or server uses blocking writes, it MUST not exceed
the window size of the underlying transport layer."

Here's my understanding of the related issues:

3.1. Both the server and the client process commands and responses in
order, so I don't see any harm in a write blocking on just one end.
Implementations may want not to block for some reason, but this is an
implementation issue and has nothing to do with the protocol.

3.2. Simply not exceeding the window size doesn't guarantee that a
blocking write won't block.  There're often more requirements, and
these depend on both the underlying protocols (currently, TCP with
some security layer on top of it), their implementations, and the OS.

3.3. It is often not possible for an application to know if a write
would exceed the window size.  POP3 clients can assume that a write
would likely not block if it doesn't exceed a certain size after all
responses to a previous group of commands have been received.  I
don't know of a way to use such an approach for POP3 servers, as
command responses don't get acknowledged on the application layer.

RFC 2197 ("SMTP Service Extension for Command Pipelining") explains
the real reason behind a similar requirement: avoiding a deadlock
condition.  If the client blocks on a command write, it won't be able
to read responses off the socket, so, once the kernel buffer fills
up, it may not acknowledge new responses coming from the server.  The
write on the server may then block as well.

To solve this problem, it seems to be enough to ensure that writes
don't block on the client end only.  This is what RFC 2197 requires.

Besides, is there any useful work for a POP3 server to be done if it
would otherwise block on a write of a response?  Reading all commands
off the socket immediately (to be reasonably sure the client won't
have a need to block) would potentially require an unlimited storage.
This is not good anyway.

Finally, it is not blocking writes that cause the problem -- it is
blocking _anywhere_ and not reading responses off the socket in time
that does.  The fact that a client doesn't use blocking writes or
makes sure they don't block doesn't yet imply that it doesn't have
the deadlock problem.

I suggest that the requirement be relaxed to apply to POP3 clients
only, and the reasoning behind it explained in the RFC.

I'll appreciate any comments on the thoughts above.  I am going to
add CAPA support into my POP3 server, but would like to make these
issues clear first.  Current version of the server can be found at:

	http://www.openwall.com/popa3d/

Signed,
Solar Designer

From owner-ietf-pop3ext  Tue Dec 28 09:16:45 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28192
	for ietf-pop3ext-bks; Tue, 28 Dec 1999 09:16:45 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28188
	for <ietf-pop3ext@imc.org>; Tue, 28 Dec 1999 09:16:43 -0800 (PST)
Received: from galileo.esys.ca (c12933-001.powersurfr.com [24.108.1.109])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id KAA26781;
	Tue, 28 Dec 1999 10:21:21 -0700
From: Steve Hole <steve.hole@messagingdirect.com>
Date: Tue, 28 Dec 1999 10:22:19 -0700
To: Alexey Melnikov <mel@messagingdirect.com>
Subject: Re: Survey : What clients/servers support CAPA?
Cc: POP3 Extensions Mailing List <ietf-pop3ext@imc.org>
In-Reply-To: <385D5287.23558E0@messagingdirect.com>
References: <385D5287.23558E0@messagingdirect.com>
Message-ID: <EXECMAIL.9912281019.A634@galileo.esys.ca>
X-Mailer: Execmail for Linux 5.3 b1 Build (1)  -- Evaluation Copy
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

On Sun, 19 Dec 1999 14:47:51 -0700 Alexey Melnikov 
<mel@messagingdirect.com> wrote:

> I am going to create another web page, that list POP3 extensions
> supported by different clients/servers.
> 
> The starting list:
> 
> Clients that supports CAPA:
> 
> Eudora,
> Execmail
> 
> Servers that supports CAPA:
> 
> QPopper,
> CMU POP3,
> M-Store POP3 (formerly SMS)

I believe that a subset of this information may be available on the IMC 
website.    Anything new that is collected in this forum should actually 
be posted to the IMC website so that we maintain the "one true location" 
for information.

Cheers.

---
Steve Hole
Messaging Direct
Mailto:Steve.Hole@MessagingDirect.com
Phone: 780-424-4922

From owner-ietf-pop3ext  Sun Jan  9 12:32:04 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA14532
	for ietf-pop3ext-bks; Sun, 9 Jan 2000 12:32:04 -0800 (PST)
Received: from eljefe.innosoft.com (ELJEFE.INNOSOFT.COM [192.160.253.137])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14528
	for <ietf-pop3ext@imc.org>; Sun, 9 Jan 2000 12:32:03 -0800 (PST)
Received: from nifty-jr.innosoft.com ([192.160.253.35])
 by mail.eljefe.innosoft.com (PMDF V6.0-17 #4409)
 with ESMTPA id <0FO3001654LYAJ@mail.eljefe.innosoft.com> for
 ietf-pop3ext@imc.org; Sun,  9 Jan 2000 12:22:50 -0800 (PST)
Date: Sun, 09 Jan 2000 12:30:58 -0800
From: Chris Newman <chris.newman@INNOSOFT.COM>
Subject: Re: POP3 "resume download" extension
In-reply-to: <199912170622.BAA02584@astro.cs.utk.edu>
To: Keith Moore <moore@cs.utk.edu>, vrs@rampnet.com
Cc: Anders Rundegren <anders@rundegren.com>,
        "ietf-pop3ext@imc.org" <ietf-pop3ext@imc.org>
Message-id: <365737.3156409858@nifty-jr.innosoft.com>
MIME-version: 1.0
X-Mailer: Mulberry (MacOS) [2.0.0b5, s/n S-100003]
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7bit
Content-disposition: inline
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

--On Friday, December 17, 1999 1:22 -0500 Keith Moore <moore@cs.utk.edu> 
wrote:
> fwiw, a lot of folks are likely to push back on defining any new extension
> to pop. there is a feeling that two mail access protocols are too many,

Let me explain my theory for why we can't get rid of POP easily.  The 
primary customer for POP servers is large ISPs providing individual user 
service.  These ISPs need to put as many mail users on a server as possible 
in order to keep management costs to a minimum so the per-user margin is 
profitable.  Most of the server operating systems which can scale large 
enough with enough reliability and performance are based on the BSD-socket 
API.  When machines get that big, two major limiting factors on scalability 
are a small fixed limit on TCP/IP connections (max file descriptors) and 
the exponential performance cost of select and poll.  In this scenario, 
TCP/IP connections are expensive and need to be kept as short lived as 
possible.  IMAP is anethema, as would be any extension to POP which might 
result in longer-running connections.

The excessively ugly /dev/poll interface in Solaris 8 (pre-release) fixes 
half the problem but that OS still has a small hard-coded limit on the 
number of file descriptors instead of making RAM the only limiting factor 
as it should.  So we have to live with protocols that use short-lived 
TCP/IP connections like POP and HTTP 1.0 (with the shared Internet 
suffering as a result).

> if you do define an extension for partial message retrieval I think it 
> should allow partial message retrieval (e.g. byte count) rather than 
> just resume.  that way, you don't have to drop a connection to 
> get the server to stop sending you a message.

I happen to support the idea of a resume download extension, but I'm 
opposed to adding a partial message retrieval extension to POP.  My reasons 
are subtle (mostly gut reaction), but I'll attempt to explain:

First, I don't believe most clients would bother to do a pipelined chunking 
download of POP mail.  It simply adds too much complexity to the common 
case (download all mail and delete from server) in order to optimize an 
uncommon case (user cancel of large message).  Simply closing the socket 
and re-opening is much less error prone, and wasting a few round-trips 
simply isn't a performance concern when you're interacting with the user. 
In IMAP, connections are usually long-lived so a pipelined chunking 
download makes more sense, but even though the facility is present in the 
protocol it's largely unused.  Furthermore, the interactions between 
dot-stuffing and byte ranges would make the POP3 version tricker to 
implement than the IMAP version.  That's far too much complexity to save a 
few round trips.

Second, I don't think POP3 is the right protocol to start experimenting 
with new user cancel facilities.  Most of the times the IETF has tried an 
explicit user cancel facility in a protocol, the result has largely failed 
(e.g., telnet TCP urgent data & IMAP pipelined/chunked partial fetch).  A 
largely stable full standard protocol is the wrong place to experiment.

Finally, I think a byte-range fetch could be abused.  In particular, some 
clients will try to use it to fetch pieces of a large message (something 
which IMAP does far better).  This would require a series of round trips to 
see if enough data has been fetched.  So if you're going to add a 
byte-range fetch, you also need to add a separate facility to at least 
fetch to the end of the first text part (possibly with a size limit as 
well) at the same time to minimize the potential for abuse.  But now the 
extension adds one or two commands and a bit of server-side MIME parsing 
which is really pushing the complexity barrier for a POP extension.

A "resume download" extension is simpler and doesn't have the above issues. 
About all it can be used for is to reduce retransmission of data after a 
user cancel or network failure -- thus making a POP client signficantly 
more likely to succeed at downloading a large message over a flaky 
connection.  That has an acceptable complexity:benefit ratio in my book, 
byte-range fetch does not.

		- Chris


From owner-ietf-pop3ext  Sat Jan 29 04:32:51 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13788
	for ietf-pop3ext-bks; Sat, 29 Jan 2000 04:32:51 -0800 (PST)
Received: from musse.tninet.se (musse.tninet.se [195.100.94.12])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA13784
	for <ietf-pop3ext@imc.org>; Sat, 29 Jan 2000 04:32:49 -0800 (PST)
Received: (qmail 20401 invoked from network); 29 Jan 2000 13:34:48 +0100
Received: from garibaldi.tninet.se (195.100.94.103)
  by musse.tninet.se with SMTP; 29 Jan 2000 13:34:48 +0100
Received: from  rundegren.com (sdu252-203.ppp.algonet.se [195.163.203.252])
 by tninet.se (BLUETAIL Mail Robustifier1.1.7) with ESMTP
 id s2846419t372929-bmr-garibaldi
 ; Sat, 29 Jan 2000 13:34:46 +0100
Message-ID: <3892DE6A.CD19311@rundegren.com>
Date: Sat, 29 Jan 2000 13:34:50 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Extended RETR - Draft posted
References: <182081.3157782802@nifty-jr.innosoft.com> <p04301201b4b534e47b7b@129.46.218.34>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

The draft for the extended RETR command has now been posted. Feedback
is, as always, very appreciated. I'm not sure about the section dealing
with extended response codes, it definitely needs some more work. Since
English is not my native language I ask you to look over this too.

http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt

Thanks!

// Anders Rundegren

From owner-ietf-pop3ext  Sat Jan 29 19:45:34 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id TAA28135
	for ietf-pop3ext-bks; Sat, 29 Jan 2000 19:45:34 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA28131
	for <ietf-pop3ext@imc.org>; Sat, 29 Jan 2000 19:45:32 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id VAA04905; Sat, 29 Jan 2000 21:47:23 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id GAA04323; Sun, 30 Jan 2000 06:44:35 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200001300344.GAA04323@false.com>
Subject: Re: Extended RETR - Draft posted
In-Reply-To: <3892DE6A.CD19311@rundegren.com> from Anders Rundegren at "Jan 29, 0 01:34:50 pm"
To: anders@rundegren.com (Anders Rundegren)
Date: Sun, 30 Jan 2000 06:44:35 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> The draft for the extended RETR command has now been posted. Feedback
> is, as always, very appreciated. I'm not sure about the section dealing
> with extended response codes, it definitely needs some more work. Since
> English is not my native language I ask you to look over this too.
> 
> http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt

The initial impression is that this clearly needs more work, perhaps
resulting in a different approach to define offsets within a message.

"The offset is given in octets. Everything transferred with a standard
RETR command should be accounted for."

I am assuming the "everything" applies to byte-stuffing.  Now, let's
assume a transfer got interrupted right before a dot in the message.
The client requests that the transfer is continued from that offset,
and the operation succeeds.  The server byte-stuffs that dot (as it
is now at the beginning of a line being transferred), and transfers
more of the message to the client.  Unfortunately, the client gets
disconnected once again.  It wants to recover the transfer.

The question: what offset should it request this time?  It could have
stored the amount of data it has received, along with the incomplete
message.  However, that amount is one octet larger than what it would
be if the transfer wasn't interrupted the first time.  Obviously, the
server, according to this definition of the extension, expects to see
offsets into the data that would be "transferred with a standard RETR
command" -- that is, without any previously recovered transfers.

With this definition of the RETR extension, the client would have to
detect if the first character it receives after a transfer continues
is a dot _and_ it is not at the beginning of a _message_ line.  It
should then subtract one from the data size it is calculating, for
the case of having to continue the transfer once again.  This should
be at least documented in the same RFC, but I suggest that we better
avoid this extra complexity somehow.

A more obvious requirement of this definition is that the client
either stores the amount of data it has received for each incomplete
message, or re-calculates that amount once it wants to finish the
transfer.  The former is fine if we only want to recover transfers
while the client process is running, but might require extending
mailbox format for some clients if we want that functionality even
after an OS restart.  The latter puts some code from POP3 servers,
which used to be server-specific, into clients as well.

Finally, speaking of your reasoning for the extension --

"       a) Less consumption of bandwidth
        b) Less resources used on the server-side
        c) Less time used online for the client"

I would consider (c) the most important reason.  Bandwidth isn't that
important here, as POP3 transfers are typically within one ISP, from
a mailbox at the ISP to the ISP's dialup line, which is busy anyway.
(b) is not fully achieved with your definition of the offsets, as the
server has to read the entire message from the mailbox to account for
byte-stuffing.

Signed,
Solar Designer

From owner-ietf-pop3ext  Sun Jan 30 19:15:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24770
	for ietf-pop3ext-bks; Sun, 30 Jan 2000 19:15:54 -0800 (PST)
Received: from musse.tninet.se (musse.tninet.se [195.100.94.12])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA24766
	for <ietf-pop3ext@imc.org>; Sun, 30 Jan 2000 19:15:52 -0800 (PST)
Received: (qmail 8166 invoked from network); 31 Jan 2000 04:17:59 +0100
Received: from garibaldi.tninet.se (195.100.94.103)
  by musse.tninet.se with SMTP; 31 Jan 2000 04:17:59 +0100
Received: from  rundegren.com (sdu52-203.ppp.algonet.se [195.163.203.52])
 by tninet.se (BLUETAIL Mail Robustifier1.1.7) with ESMTP
 id s3274763t423128-bmr-garibaldi
 ; Mon, 31 Jan 2000 04:17:57 +0100
Message-ID: <3894FEF4.1D61AFF7@rundegren.com>
Date: Mon, 31 Jan 2000 04:18:12 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Solar Designer <solar@false.com>
CC: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - Draft posted
References: <200001300344.GAA04323@false.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> "The offset is given in octets. Everything transferred with a standard
> RETR command should be accounted for."

The sentence following the above sentence in the draft states:

"This means that top headers, followed by messageparts will be
transferred, in that order."

> I am assuming the "everything" applies to byte-stuffing.

Read the above quote.

> The question: what offset should it request this time?  It could have
> stored the amount of data it has received, along with the incomplete
> message.  However, that amount is one octet larger than what it would
> be if the transfer wasn't interrupted the first time.  Obviously, the
> server, according to this definition of the extension, expects to see
> offsets into the data that would be "transferred with a standard RETR
> command" -- that is, without any previously recovered transfers.

OK, this is something I thought about when I was drafting the memo. I
decided not to include an explanation because I saw it as obvious.
Having given it some more thought, I think a more thorough explanation
and an example might be in order. I will probably add a section
explaining how byte-stuffing and calculation of offsets should be done.

The model should be very simple, please correct me if I'm wrong:

msg-offset-bytestuff-server-client-bytedestuff-msg

Example:

Message number is '1'.
Message size is 217,743 bytes.
Offset 113,435 starts with a '.'.

Lets assume our transfer got interrupted after 113,434 bytes. Now, the
received data has been bytedestuffed and saved, thus the client executes
'RETR 1 113435'. The server opens the message and jumps to this offset.
It now bytestuffs the '.' as usual and transmits the data to the client
who bytedestuff the data and adds it to the incomplete data it received
earlier.

> "       a) Less consumption of bandwidth
>         b) Less resources used on the server-side
>         c) Less time used online for the client"
> 
> I would consider (c) the most important reason.  Bandwidth isn't that
> important here, as POP3 transfers are typically within one ISP, from
> a mailbox at the ISP to the ISP's dialup line, which is busy anyway.

You have a point about bandwidth, in some cases, not being a problem.
However, taking in account the fast evolution on the internet, this
might in the future apply to other connections than modems, i.e. a
company's internal network, since attachments might be much larger than
they are today.

> (b) is not fully achieved with your definition of the offsets, as the
> server has to read the entire message from the mailbox to account for
> byte-stuffing.

Well, this shouldn't be a problem with the above explained model. The
server just need to do an fseek() to the specified offset.

// Anders

From owner-ietf-pop3ext  Sun Jan 30 20:18:54 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id UAA29522
	for ietf-pop3ext-bks; Sun, 30 Jan 2000 20:18:54 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA29515
	for <ietf-pop3ext@imc.org>; Sun, 30 Jan 2000 20:18:53 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id WAA23913; Sun, 30 Jan 2000 22:20:57 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id HAA05533; Mon, 31 Jan 2000 07:19:30 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200001310419.HAA05533@false.com>
Subject: Re: Extended RETR - Draft posted
In-Reply-To: <3894FEF4.1D61AFF7@rundegren.com> from Anders Rundegren at "Jan 31, 0 04:18:12 am"
To: anders@rundegren.com (Anders Rundegren)
Date: Mon, 31 Jan 2000 07:19:29 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> > "The offset is given in octets. Everything transferred with a standard
> > RETR command should be accounted for."
> 
> The sentence following the above sentence in the draft states:
> 
> "This means that top headers, followed by messageparts will be
> transferred, in that order."

Yes, but I didn't read it as "byte-stuffing will not affect offsets",
the "everything" seemed to imply the opposite.

> > I am assuming the "everything" applies to byte-stuffing.
> 
> Read the above quote.

So it needs to be clearer.

> > The question: what offset should it request this time?  It could have
> > stored the amount of data it has received, along with the incomplete
> > message.  However, that amount is one octet larger than what it would
> > be if the transfer wasn't interrupted the first time.  Obviously, the
> > server, according to this definition of the extension, expects to see
> > offsets into the data that would be "transferred with a standard RETR
> > command" -- that is, without any previously recovered transfers.
> 
> OK, this is something I thought about when I was drafting the memo. I
> decided not to include an explanation because I saw it as obvious.
> Having given it some more thought, I think a more thorough explanation
> and an example might be in order. I will probably add a section
> explaining how byte-stuffing and calculation of offsets should be done.

Yes, it seems we need that.  There's one more issue that you'd need
to decide on -- are we calculating CRLF's the way they're transferred
over POP3 (would be more essential for the protocol), or the way line
separators are typically stored on a UNIX-based server (to allow for
a simple seek).

> The model should be very simple, please correct me if I'm wrong:
> 
> msg-offset-bytestuff-server-client-bytedestuff-msg

Unfortunately, there may be a few more conversions:

server_mailbox -> skip(*)_to_offset -> bytestuff -> LF_to_CRLF -> ...
... transfer -> bytedestuff -> convert_to_client_mailbox_format

(*) we haven't defined the "skip" for the server_mailbox "layer", yet.

> Example:
> 
> Message number is '1'.
> Message size is 217,743 bytes.
> Offset 113,435 starts with a '.'.
> 
> Lets assume our transfer got interrupted after 113,434 bytes. Now, the

To illustrate the case of having to byte-stuff, you'd want the
transfer to be interrupted after 113,435 bytes.

> received data has been bytedestuffed and saved, thus the client executes
> 'RETR 1 113435'. The server opens the message and jumps to this offset.
> It now bytestuffs the '.' as usual and transmits the data to the client
> who bytedestuff the data and adds it to the incomplete data it received
> earlier.
> 
> > "       a) Less consumption of bandwidth
> >         b) Less resources used on the server-side
> >         c) Less time used online for the client"
> > 
> > I would consider (c) the most important reason.  Bandwidth isn't that
> > important here, as POP3 transfers are typically within one ISP, from
> > a mailbox at the ISP to the ISP's dialup line, which is busy anyway.
> 
> You have a point about bandwidth, in some cases, not being a problem.
> However, taking in account the fast evolution on the internet, this
> might in the future apply to other connections than modems, i.e. a
> company's internal network, since attachments might be much larger than
> they are today.

Yes, that's a valid point as well, but, in my opinion, (c) is more
important.

> > (b) is not fully achieved with your definition of the offsets, as the
> > server has to read the entire message from the mailbox to account for
> > byte-stuffing.
> 
> Well, this shouldn't be a problem with the above explained model. The
> server just need to do an fseek() to the specified offset.

I wish it was that simple.

To allow for a simple seek, we would need to define that offsets are
into the message as stored in a BSD-style mailbox.  (I am assuming
that performance is less critical on non-UNIX servers, and that they
can choose the mailbox format that allows for better performance if
they care.)  The calculation of offsets on the client end would get
more complicated, then -- unless the client uses single LF's for its
mailboxes as well.  Maybe it's not that bad, after all.

Signed,
Solar Designer

From owner-ietf-pop3ext  Mon Jan 31 23:35:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA12691
	for ietf-pop3ext-bks; Mon, 31 Jan 2000 23:35:54 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12687
	for <ietf-pop3ext@imc.org>; Mon, 31 Jan 2000 23:35:52 -0800 (PST)
Received: from messagingdirect.com (2-028-edm.dial.worldgate.ca [207.167.2.28])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id AAA00706;
	Tue, 1 Feb 2000 00:37:54 -0700
Message-ID: <38967A3D.948E6851@messagingdirect.com>
Date: Mon, 31 Jan 2000 23:16:29 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundegren <anders@rundegren.com>,
        POP3 Extensions Mailing List <ietf-pop3ext@imc.org>
Subject: Re: Extended RETR - Draft posted
References: <182081.3157782802@nifty-jr.innosoft.com> <p04301201b4b534e47b7b@129.46.218.34> <3892DE6A.CD19311@rundegren.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Anders Rundegren wrote:
> 
> The draft for the extended RETR command has now been posted. Feedback
> is, as always, very appreciated. I'm not sure about the section dealing
> with extended response codes, it definitely needs some more work. Since
> English is not my native language I ask you to look over this too.
> 
> http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt

Few comments:

1). 1. Introduction:

>Many clients connecting to an ISP, or even ISP itself,
>***have their modems improperly setup*** ...

I am not sure why you want to blame modem configuration for all
problems.
I use to have 19200 dialup connection to my ISP and a very noisy phone
line.
Sometimes connection was dropped every 5 minutes.

2). 2.2 The offset argument

        If the specified offset is beyond the size of the message being
        retrieved, or in any other way erroneous in its syntax, 
        ***the response from the server should start with "-ERR".****

I suggest to change the ending to something like the following:
        the server should send negative response code.


3). 3. Extended Response Codes

Change
  -ERR message exists [OFFSET-OVERRUN]
and
  -ERR no such message [NON-EXISTENT]

to 
  -ERR [OFFSET-OVERRUN] message exists
and
  -ERR [NON-EXISTENT] no such message 
respectively

This is according to ABNF in RFC 2449.

I also doubt the usefulness of [NON-EXISTENT] response.
Good behaving client must check the validity of the message number when
it reconnects.
Also if another client deleted the interrupted message while the client
reconnects, the client is risking to resume downloading the next
message. This is not what you expect from the client. In this case some
persistent message Id should be used (UIDL?).

Alexey


From owner-ietf-pop3ext  Mon Jan 31 23:58:49 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA13415
	for ietf-pop3ext-bks; Mon, 31 Jan 2000 23:58:49 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA13411
	for <ietf-pop3ext@imc.org>; Mon, 31 Jan 2000 23:58:48 -0800 (PST)
Received: from messagingdirect.com (2-028-edm.dial.worldgate.ca [207.167.2.28])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id BAA00729;
	Tue, 1 Feb 2000 01:00:58 -0700
Message-ID: <389691B7.98B12E09@messagingdirect.com>
Date: Tue, 01 Feb 2000 00:56:39 -0700
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Solar Designer <solar@false.com>
CC: Anders Rundegren <anders@rundegren.com>, ietf-pop3ext@imc.org
Subject: Re: Extended RETR - Draft posted
References: <200001310419.HAA05533@false.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Solar Designer wrote:

> Yes, it seems we need that.  There's one more issue that you'd need
> to decide on -- are we calculating CRLF's the way they're transferred
> over POP3 (would be more essential for the protocol), or the way line
> separators are typically stored on a UNIX-based server (to allow for
> a simple seek).

There are servers that 
1). construct message on the flight, storing it in some different
format.
2). store headers separately from body.
3). store message with CRLF even if they run on Unix
4). store message in bytestuffed form (as received from SMTP)

Whatever rule you choose for calculation of offset you will not satisfy
ALL implementations, 
so there is no point doing that.

BTW, ESMTP Checkpoint/Restart extension (RFC 1845) that does exactly the
same thing for SMTP (and suffers from the same dot stuffing problem)
says:

   Any octets added by any SMTP data-stuffing algorithm do
   not count as part of this offset. In the case of data transferred
   with the DATA command the offset must also correspond to the
   beginning of a line.

In checkpoint/restart offset starts from 0.
I would suggest to use the same for consistency.

> > The model should be very simple, please correct me if I'm wrong:
> >
> > msg-offset-bytestuff-server-client-bytedestuff-msg
> 
> Unfortunately, there may be a few more conversions:
> 
> server_mailbox -> skip(*)_to_offset -> bytestuff -> LF_to_CRLF -> ...
> ... transfer -> bytedestuff -> convert_to_client_mailbox_format
> 
> (*) we haven't defined the "skip" for the server_mailbox "layer", yet.
> 
> > Example:
> >
> > Message number is '1'.
> > Message size is 217,743 bytes.
> > Offset 113,435 starts with a '.'.
> >
> > Lets assume our transfer got interrupted after 113,434 bytes. Now, the
> 
> To illustrate the case of having to byte-stuff, you'd want the
> transfer to be interrupted after 113,435 bytes.

Would it be easier to use TOP-like command? Something like

   TOP <msgnum> <lines> <start_from_line>
  
Alexey

From owner-ietf-pop3ext  Wed Feb  2 04:05:53 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08626
	for ietf-pop3ext-bks; Wed, 2 Feb 2000 04:05:53 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA08603
	for <ietf-pop3ext@imc.org>; Wed, 2 Feb 2000 04:05:50 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id GAA08441; Wed, 2 Feb 2000 06:07:42 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id NAA09085; Wed, 2 Feb 2000 13:55:57 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200002021055.NAA09085@false.com>
Subject: Re: Extended RETR - Draft posted
In-Reply-To: <389691B7.98B12E09@messagingdirect.com> from Alexey Melnikov at "Feb 1, 0 00:56:39 am"
To: mel@messagingdirect.com (Alexey Melnikov)
Date: Wed, 2 Feb 2000 13:55:57 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> 
> > Yes, it seems we need that.  There's one more issue that you'd need
> > to decide on -- are we calculating CRLF's the way they're transferred
> > over POP3 (would be more essential for the protocol), or the way line
> > separators are typically stored on a UNIX-based server (to allow for
> > a simple seek).
> 
> There are servers that 
> 1). construct message on the flight, storing it in some different
> format.
> 2). store headers separately from body.
> 3). store message with CRLF even if they run on Unix
> 4). store message in bytestuffed form (as received from SMTP)
> 
> Whatever rule you choose for calculation of offset you will not satisfy
> ALL implementations, 

Yes, indeed.

> so there is no point doing that.

Not necessarily: it might make sense to make life easier for those
servers for which it would be harder to switch to a more efficient
(for our POP3 extension) mailbox format.

I agree that this is probably not worth the extra complexity this
would bring into the specification of such a POP3 extension.

> BTW, ESMTP Checkpoint/Restart extension (RFC 1845) that does exactly the
> same thing for SMTP (and suffers from the same dot stuffing problem)
> says:
> 
>    Any octets added by any SMTP data-stuffing algorithm do
>    not count as part of this offset. In the case of data transferred
>    with the DATA command the offset must also correspond to the
>    beginning of a line.
> 
> In checkpoint/restart offset starts from 0.
> I would suggest to use the same for consistency.

> Would it be easier to use TOP-like command? Something like
> 
>    TOP <msgnum> <lines> <start_from_line>

TOP would be more consistent with current POP3, as we already have
line number arguments, but don't have octet ones, yet.

However, as you have pointed out, it would be inconsistent with the
SMTP extension.

Signed,
Solar Designer

From owner-ietf-pop3ext  Fri Feb  4 08:53:05 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA10988
	for ietf-pop3ext-bks; Fri, 4 Feb 2000 08:53:05 -0800 (PST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10982
	for <ietf-pop3ext@imc.org>; Fri, 4 Feb 2000 08:53:03 -0800 (PST)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2])
	by internal.mail.demon.net with ESMTP id QAA26512;
	Fri, 4 Feb 2000 16:55:33 GMT
Message-ID: <Rrv18KAyPwm4QARG@turnpike.com>
Date: Fri, 4 Feb 2000 16:53:06 +0000
To: ietf-pop3ext@imc.org
From: Paul Overell <paulo@turnpike.com>
Subject: RFC2449 syntax
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.00 alpha 3M <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Some comments on the syntax given in RFC2449.

In RFC2449 para 3.  General Command and Response Grammar


>
>     greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF                          
>

This fails to require a space after the +OK, I suggest

      greeting     =  "+OK" [SP [resp-code] *gchar [timestamp] *gchar] CRLF                          




>
>     text         =  *schar / resp-code *CHAR 
>

This syntax is correct if the server supports RESP-CODES but is otherwise overly
restrictive, I suggest either

     text         =  (*schar / resp-code *CHAR) /       ; if RESP-CODES supported
                     *CHAR                              ; otherwise




More controversial:

>
>      dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed
>

This prohibits downloading messages containing 8 bit characters.  RFC1939 does not
explicitly outlaw 8bit characters, however, it does say messages "are assumed to
conform to ... [RFC822]", which could be interpreted as an implicitly outlawing
8bit characters.  

As ESMTP permits the transmission of 8bit MIME messages (and it is not unknown
using SMTP) are we to prevent users from collecting them via POP3?  I suggest:


        dot-stuffed = *OCTET CRLF               ; must be dot-stuffed



Regards
-- 
Paul Overell                                             T U R N P I K E

From owner-ietf-pop3ext  Sat Feb  5 16:15:25 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA11035
	for ietf-pop3ext-bks; Sat, 5 Feb 2000 16:15:25 -0800 (PST)
Received: from musse.tninet.se (musse.tninet.se [195.100.94.12])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA11031
	for <ietf-pop3ext@imc.org>; Sat, 5 Feb 2000 16:15:23 -0800 (PST)
Received: (qmail 2337 invoked from network); 6 Feb 2000 01:17:58 +0100
Received: from garibaldi.tninet.se (195.100.94.103)
  by musse.tninet.se with SMTP; 6 Feb 2000 01:17:58 +0100
Received: from  rundegren.com (sdu43-200.ppp.algonet.se [195.163.200.43])
 by tninet.se (BLUETAIL Mail Robustifier1.1.7) with ESMTP
 id s362601t63614-bmr-garibaldi
 ; Sun, 06 Feb 2000 01:17:57 +0100
Message-ID: <389CBDD0.E9C8DE4B@rundegren.com>
Date: Sun, 06 Feb 2000 01:18:24 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Solar Designer <solar@false.com>,
        Alexey Melnikov <mel@messagingdirect.com>
CC: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - Draft posted
References: <200001310419.HAA05533@false.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Is there anyone having additional comments except what has already been
said?

I will revise the draft based on the feedback I've been getting so far.
However, this will not happen until next weekend due to extreme workload
at work.

> > Example:
> >
> > Message number is '1'.
> > Message size is 217,743 bytes.
> > Offset 113,435 starts with a '.'.
> >
> > Lets assume our transfer got interrupted after 113,434 bytes. Now, the
> 
> To illustrate the case of having to byte-stuff, you'd want the
> transfer to be interrupted after 113,435 bytes.

Yes, true, sorry about that...

> > > "       a) Less consumption of bandwidth
> > >         b) Less resources used on the server-side
> > >         c) Less time used online for the client"

I didn't put them in any specific order though.

> To allow for a simple seek, we would need to define that offsets are
> into the message as stored in a BSD-style mailbox.

I guess I should explore other systems. ;)

// Anders

From owner-ietf-pop3ext  Tue Feb  8 11:28:34 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17291
	for ietf-pop3ext-bks; Tue, 8 Feb 2000 11:28:34 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA17287
	for <ietf-pop3ext@imc.org>; Tue, 8 Feb 2000 11:28:33 -0800 (PST)
Received: from 172.30.236.230 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Feb 2000 11:15:08 -0800 (Pacific Standard Time)
Received: from MIKEGA9 ([157.59.255.155]) by popdog.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 12F8BZ9G; Tue, 8 Feb 2000 11:15:02 -0800
Message-ID: <000101bf7268$f0942870$9bff3b9d@redmond.corp.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Anders Rundegren" <anders@rundegren.com>, <ietf-pop3ext@imc.org>
References: <3892DE6A.CD19311@rundegren.com>
Subject: Re: Extended RETR - Draft posted
Date: Tue, 8 Feb 2000 11:16:02 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Extended RETR - Draft postedIn general, there has been a strong opposition
to extending POP, in an attempt to keep it as simple as possible.  I think
to get wide spread support for a POP extension proposal such as this, it
would need to solve a very wide spread problem.  I don't have any problems
with the concept proposed in the draft, and it is clearly a nicer way to
implement what POP originally did, but from my own personal experience, the
problem of dropping a download partway through a message is relatively rare.
If this hold true for many others, I suspect it may be hard to garner wide
spread support for any POP extension.

Perhaps line qualities in different parts of the world may make this a wider
spread problem for others.
----- Original Message -----
From: Anders Rundegren
To: ietf-pop3ext@imc.org
Sent: Saturday, January 29, 2000 4:34 AM
Subject: Extended RETR - Draft posted


The draft for the extended RETR command has now been posted. Feedback
is, as always, very appreciated. I'm not sure about the section dealing
with extended response codes, it definitely needs some more work. Since
English is not my native language I ask you to look over this too.
http://www.ietf.org/internet-drafts/draft-rundegren-pop3-00.txt
Thanks!
// Anders Rundegren


From owner-ietf-pop3ext  Mon Feb 14 03:54:01 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03233
	for ietf-pop3ext-bks; Mon, 14 Feb 2000 03:54:01 -0800 (PST)
Received: from demo.esys.ca (demo.esys.ca [207.167.22.130])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03229
	for <ietf-pop3ext@imc.org>; Mon, 14 Feb 2000 03:53:59 -0800 (PST)
Received: from messagingdirect.com (2-086-edm.dial.worldgate.ca [207.167.2.86])
	by demo.esys.ca (2.0.4/SMS 2.0.4-beta-5) with ESMTP id EAA23225;
	Mon, 14 Feb 2000 04:57:07 -0700
Message-ID: <38A7EC78.3C3A8D1C@messagingdirect.com>
Date: Mon, 14 Feb 2000 11:52:24 +0000
From: Alexey Melnikov <mel@messagingdirect.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Gahrns <mikega@microsoft.com>
CC: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - Draft posted
References: <3892DE6A.CD19311@rundegren.com> <000101bf7268$f0942870$9bff3b9d@redmond.corp.microsoft.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> I don't have any problems
> with the concept proposed in the draft, and it is clearly a nicer way to
> implement what POP originally did, but from my own personal experience, the
> problem of dropping a download partway through a message is relatively rare.
> If this hold true for many others, I suspect it may be hard to garner wide
> spread support for any POP extension.
> 
> Perhaps line qualities in different parts of the world may make this a wider
> spread problem for others.

This is very true for some country I use to live in :-).

Alexey

From owner-ietf-pop3ext  Wed Feb 16 16:22:34 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id QAA16740
	for ietf-pop3ext-bks; Wed, 16 Feb 2000 16:22:34 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.51])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA16736
	for <ietf-pop3ext@imc.org>; Wed, 16 Feb 2000 16:22:32 -0800 (PST)
Received: (qmail 26327 invoked from network); 17 Feb 2000 01:26:02 +0100
Received: from garibaldi.tninet.se (195.100.94.103)
  by hromeo.algonet.se with SMTP; 17 Feb 2000 01:26:02 +0100
Received: from  rundegren.com (sdu70-204.ppp.algonet.se [195.163.204.70])
 by tninet.se (BLUETAIL Mail Robustifier1.1.9) with ESMTP
 id s1225883t154230-bmr2-garibaldi
 ; Thu, 17 Feb 2000 01:25:56 +0100
Message-ID: <38AB404D.E9E77193@rundegren.com>
Date: Thu, 17 Feb 2000 01:26:53 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
CC: Alexey Melnikov <mel@messagingdirect.com>,
        Solar Designer <solar@false.com>
Subject: Extended RETR - version 2
References: <200001310419.HAA05533@false.com> <389691B7.98B12E09@messagingdirect.com>
Content-Type: multipart/mixed;
 boundary="------------BB1DF73CF35D8C026969FE38"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------BB1DF73CF35D8C026969FE38
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm attaching the revised version of the draft (I haven't uploaded it to
IETF since I thought you might have more comments, which I hope). I've
done some changes based on your feedback and the one thing that struck
me was Alexey's comment below:

> BTW, ESMTP Checkpoint/Restart extension (RFC 1845) that does exactly the
> same thing for SMTP (and suffers from the same dot stuffing problem)
> says:
> 
>    Any octets added by any SMTP data-stuffing algorithm do
>    not count as part of this offset. In the case of data transferred
>    with the DATA command the offset must also correspond to the
>    beginning of a line.

This is a very good point. I've added a section explaining bytestuffing,
in which I also added a sentence that clarifies that offsets are
calculated "unstuffed".

// Anders
--------------BB1DF73CF35D8C026969FE38
Content-Type: text/plain; charset=us-ascii;
 name="extended-retr-draft-v2.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="extended-retr-draft-v2.txt"

INTERNET-DRAFT                                            INTERNET-DRAFT
                                                            A. Rundegren
                                                       17 February, 2000


                  Extended RETR - Extension to POP3
                    <draft-rundegren-pop3-01.txt>           


Status of this Memo

        This document is an Internet-Draft and is in full
        conformance with all provisions of Section 10 of RFC2026.

        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups. Note that other groups may also distribute working
        documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be
        accessed at http://www.ietf.org/shadow.html.

        Distribution of this document is unlimited. Please send
        comments to the author.


Abstract

        This memo introduces an extension to the RETR command in the
        POP3 protocol. The extension makes it possible for an
        interrupted RETR command to be continued. This is
        particularly useful when downloading large messages over
        unstable connections.














A. Rundegren                                                    [page 1]
-- LINE -- 58 --
INTERNET-DRAFT                                         17 February, 2000


Table of Contents
        1.  Introduction  ...........................................  2
        2.  The Extended RETR Command  ..............................  2
          2.1  RFC 1939 Specification  ..............................  2
          2.2  The Offset Argument  .................................  3
	  2.3  Bytestuffing  ........................................  4
        3.  Extended Response Codes  ................................  4
        4.  The CAPA Tag  ...........................................  5
        5.  Security Considerations  ................................  6
        6.  Acknowledgements  .......................................  6
        7.  References  .............................................  6
        8.  Author's Address  .......................................  6


1. Introduction

        When email was first developed it was intended to transfer
        readable text messages. Since the introduction of MIME (RFC
        2045) it has become more common to transfer other message
        parts, more commonly known as attachments. These attachments
        are often much larger than the readable textparts.

        Many clients connecting to an ISP, or even the ISP itself,
        have their modems setup in a way that doesn't handle a noisy
        phoneline very well. When line-quality isn't high enough, this
        often results in a premature disconnect.

        Using commands currently found in the the POP3 protocol, these
        messages will have to be re-downloaded from scratch taking a
        lot of unnecessary bandwidth from the ISP, not to mention
        resources within the system itself.

        By extending the RETR command, the download-and-delete model
        that characterizes the POP3 protocol becomes more complete in
        handling todays requirements of email. Consider the benefits:

        a) Less resources used on the server-side
        b) Less time used online for the client
        c) Less consumption of bandwidth


2. The Extended RETR Command

        This section will give a detailed view on how the second
        argument of the extended RETR command should be implemented.

2.1 RFC 1939 Specification

        The RETR command (as specified by RFC 1939), takes one argument
        which specifies the message to be retrieved by the client. The
        possible responses are "+OK" and "-ERR", without the quotes.


A. Rundegren                                                    [page 2]
-- LINE -- 116 --
INTERNET-DRAFT                                         17 February, 2000


2.2 The Offset Argument

        The second argument to the extended RETR command specifies the
        offset in the message of where the transfer should start. The
        offset is given in octets. All data that is transferred with a
        standard RETR command should be accounted for. This means that
        top headers, followed by messageparts will be transferred, in
        that order. As specified by RFC 1939, responses can not be more
        than 512 characters long, including the terminating CRLF.

        The syntax of the extended RETR command would be:

            RETR msg offset

        Arguments:
            A message-number (required) which may NOT refer to a
            message marked as deleted. An offset (optional) of where
            to start the transfer, specified in octets. If the offset
            argument is omitted, the message will be sent as specified
            by the RETR command in RFC 1939.

        Description:
            If the POP3 server issues a positive response, then the
            response given is multi-line. After the intial +OK, the
            POP3 server sends the message corresponding to the given
            message-number, starting from the offset provided, being
            careful to byte-stuff the termination character (as with
            all multi-line responses).            

        Possible Responses:
            +OK message follows
            -ERR no such message

        Examples:
            C: RETR 1 345628
            S: +OK 1253512 octets
            S: <the POP3 server sends the message here, starting with
                the 345628th octet of the message>
            S: .

        If the specified offset is beyond the size of the message being
        retrieved, or in any other way erroneous in its syntax, the
        server should respond with a negative response code. This would
        however not distinguish the type of error. In the following
        section you can read about the use of extended response codes
        to clarify errormessages.







A. Rundegren                                                    [page 3]
-- LINE -- 174 --
INTERNET-DRAFT                                         17 February, 2000


2.3 Bytestuffing

        This section explains how bytestuffing should be performed when
        resuming a previously interrupted transfer. When data is to be
        transferred from the server to the client, the server should
        be careful to byte-stuff all data. If the previous transfer
        was interrupted in the middle of a line, where the remaining
        part of the line starts with a '.' character, this means that
        data, that would normally not be bytestuffed (since it's not in
        the beginning of a line), must be byte-stuffed. Any octets added
        by any data-stuffing algorithm do not count as part of the offset
        used by the Extended RETR command.


        Examples:
            Message number is 1.
            Message size is 217,743 octets.
            Offset 113,435 starts with a '.'.

            Lets assume, that when transferring the above message, an
            interrupt occurs after exactly 113,435 octets. When
            resuming the transfer, the client executes "RETR 1 113435".
            The server then byte-stuffs the data before transferring it
            to the client, who then byte-destuffs the data before
            appending it to the previously transferred data.


3. Extended Response Codes

        The extended RETR command does not require the implementation
        of extended response codes (RFC 2449) to be present in order
        to work. However, this memo specifies the extended response
        codes to be used if implemented.

        If the specified offset is beyond the size of the message being
        retrieved, the extended response code should be:

            -ERR [OFFSET-OVERRUN] message exists

        If an error occured because the message was not present on the
        server, the extended response code should be:

            -ERR [NON-EXISTENT] no such message

        For all other type of errors, a simple "-ERR" is sufficient.








A. Rundegren                                                    [page 4]
-- LINE -- 232 --
INTERNET-DRAFT                                         17 February, 2000


4. The CAPA Tag

        The extended RETR command introduces a new CAPA tag (RFC 2449).
        This tag tells the client that the server is able to continue
        interrupted RETR commands. Its implementation is mandatory.

        CAPA tag:
            EXT-RETR

        Arguments:
            none

        Added commands:
            n/a

        Standard commands affected:
            RETR

        Announced states / possible differences:
            both / no

        Commands valid in states:
            TRANSACTION

        Specification reference:
            [POP3, this document]

        Discussion:
            The extended RETR capability indicates that the server is
            capable of excepting a second argument to the RETR command
            in order to resume a previously interrupted RETR command.






















A. Rundegren                                                    [page 5]
-- LINE -- 290 --
INTERNET-DRAFT                                         17 February, 2000


5. Security Considerations

        Use of the extended RETR command sends messages in the clear
        over the network.


6. Acknowledgements

        The extension introduced in this memo is based on the RETR
        command as specified in RFC 1939. I would like to thank
        R. Gellens, C. Newman and L. Lundblade for their comments
        and suggestions during the drafting of this document.


7. References

        1)  Post Office Protocol - Version 3 (RFC 1939).
            J. Myers, M. Rose.

        2)  Multipurpose Internet Mail Extensions, Part One (RFC 2045).
            N. Freed, N. Borenstein.

        3)  POP3 Extension Mechanism (RFC 2449).
            R. Gellens, C. Newman, L. Lundblade.


8. Author's Address

        Anders Rundegren
        Skimmelgatan 1
        212 35 Malmo
        Sweden

        email: anders@rundegren.com



















A. Rundegren                                                    [page 6]
-- LINE -- 348 --

--------------BB1DF73CF35D8C026969FE38--


From owner-ietf-pop3ext  Wed Feb 16 23:42:50 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA12874
	for ietf-pop3ext-bks; Wed, 16 Feb 2000 23:42:50 -0800 (PST)
Received: from duva.bluetail.com (mail.bluetail.com [195.149.129.26])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA12867
	for <ietf-pop3ext@imc.org>; Wed, 16 Feb 2000 23:42:48 -0800 (PST)
Received: from  emu.bluetail.com (emu.bluetail.com [192.168.128.35])
 by bluetail.com (BLUETAIL Mail Robustifier1.1.9) with ESMTP
 id s573t35-bmr-duva
 ; Thu, 17 Feb 2000 08:45:01 +0100
Received: (from tobbe@localhost)
	by emu.bluetail.com (8.9.3/8.9.3) id IAA00959;
	Thu, 17 Feb 2000 08:45:01 +0100
To: Anders Rundegren <anders@rundegren.com>
Cc: ietf-pop3ext@imc.org, Alexey Melnikov <mel@messagingdirect.com>,
        Solar Designer <solar@false.com>
Subject: Re: Extended RETR - version 2
References: <200001310419.HAA05533@false.com> <389691B7.98B12E09@messagingdirect.com> <38AB404D.E9E77193@rundegren.com>
From: Torbjorn Tornkvist <tobbe@bluetail.com>
Date: 17 Feb 2000 08:45:01 +0100
In-Reply-To: Anders Rundegren's message of "Thu, 17 Feb 2000 01:26:53 +0100"
Message-ID: <m2itzouvb6.fsf@emu.bluetail.com>
Lines: 16
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


>  Many clients connecting to an ISP, or even the ISP itself,
>  have their modems setup in a way that doesn't handle a noisy
>  phoneline very well. When line-quality isn't high enough, this
>  often results in a premature disconnect.

Sorry, but I'm a bit doubtful about this extension. How serious
is the problem with a "noisy phoneline" really ? I'm just a naive
user (i.e not running an ISP) but I have never experienced this
problem, neither when living in Sweden nor in Australia.

Cheers /Tobbe
--
Torbjörn Törnkvist , tel: +46 8 692 22 15 , fax: +46 8 654 70 71
Bluetail AB , Hantverkargatan 78 , SE-112 38 Stockholm , Sweden            
Email: tobbe@bluetail.com , Web: http://www.bluetail.com/~tobbe

From owner-ietf-pop3ext  Thu Feb 17 02:52:51 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17987
	for ietf-pop3ext-bks; Thu, 17 Feb 2000 02:52:51 -0800 (PST)
Received: from mail.remote.org (mail@visby.remote.org [212.227.14.25])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17978
	for <ietf-pop3ext@imc.org>; Thu, 17 Feb 2000 02:52:49 -0800 (PST)
Received: from localhost
	by mail.remote.org with local-rmail 
	id 12LObe-0003Ht-00; Thu, 17 Feb 2000 11:56:22 +0100
Received: from sqrt by eldorado.remote.org with local (Exim 2.02 #1)
	id 12LObI-0000UV-00
	for ietf-pop3ext@imc.org; Thu, 17 Feb 2000 11:56:00 +0100
Date: Thu, 17 Feb 2000 11:56:00 +0100
From: Jochen Topf <jochen@remote.org>
To: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 2
Message-ID: <20000217115600.A1881@eldorado.remote.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Torbjorn Tornkvist <tobbe@bluetail.com> wrote:
:>  Many clients connecting to an ISP, or even the ISP itself,
:>  have their modems setup in a way that doesn't handle a noisy
:>  phoneline very well. When line-quality isn't high enough, this
:>  often results in a premature disconnect.

: Sorry, but I'm a bit doubtful about this extension. How serious
: is the problem with a "noisy phoneline" really ? I'm just a naive
: user (i.e not running an ISP) but I have never experienced this
: problem, neither when living in Sweden nor in Australia.

A quick grep over the logfiles of a large ISP (>1 Mio POP accesses a day)
tells me that less then 0.1% of the connections die while sending something
to the client. There are another about 0.2% where the client didn't properly
close the connection with QUIT, but they happen while waiting for the next
command.

These numbers are very rough, just to give a sense of the order of magnitude.
They will probabely vary between different ISPs depending on types of users
etc.

Jochen
-- 
Jochen Topf - jochen@remote.org - http://www.remote.org/jochen/


From owner-ietf-pop3ext  Thu Feb 17 03:44:37 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA21064
	for ietf-pop3ext-bks; Thu, 17 Feb 2000 03:44:37 -0800 (PST)
Received: from hromeo.algonet.se (hromeo.algonet.se [194.213.74.51])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA21060
	for <ietf-pop3ext@imc.org>; Thu, 17 Feb 2000 03:44:34 -0800 (PST)
Received: (qmail 23708 invoked from network); 17 Feb 2000 12:48:07 +0100
Received: from sinclair.tninet.se (195.100.94.101)
  by hromeo.algonet.se with SMTP; 17 Feb 2000 12:48:07 +0100
Received: from  rundegren.com (sdu96-202.ppp.algonet.se [195.163.202.96])
 by tninet.se (BLUETAIL Mail Robustifier1.1.9) with ESMTP
 id s2012983t267659-bmr-sinclair for <ietf-pop3ext@imc.org>
 ; Thu, 17 Feb 2000 12:48:05 +0100
Message-ID: <38ABE019.73E11FCC@rundegren.com>
Date: Thu, 17 Feb 2000 12:48:41 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 2
References: <20000217115600.A1881@eldorado.remote.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> A quick grep over the logfiles of a large ISP (>1 Mio POP accesses a day)
> tells me that less then 0.1% of the connections die while sending something
> to the client. There are another about 0.2% where the client didn't properly
> close the connection with QUIT, but they happen while waiting for the next
> command.

Where in the world is the above statistics from?

A few years/months from now this number is probably going to increase,
given the nature of the Internet, i.e. everything escalates beyond
everyone's imagination. :)

// Anders

From owner-ietf-pop3ext  Thu Feb 17 03:52:28 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA21193
	for ietf-pop3ext-bks; Thu, 17 Feb 2000 03:52:28 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA21189
	for <ietf-pop3ext@imc.org>; Thu, 17 Feb 2000 03:52:27 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id FAA20988; Thu, 17 Feb 2000 05:55:42 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id OAA03814; Thu, 17 Feb 2000 14:48:18 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200002171148.OAA03814@false.com>
Subject: Re: Extended RETR - version 2
In-Reply-To: <20000217115600.A1881@eldorado.remote.org> from Jochen Topf at "Feb 17, 0 11:56:00 am"
To: jochen@remote.org (Jochen Topf)
Date: Thu, 17 Feb 2000 14:48:17 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> 
> : Sorry, but I'm a bit doubtful about this extension. How serious
> : is the problem with a "noisy phoneline" really ? I'm just a naive
> : user (i.e not running an ISP) but I have never experienced this
> : problem, neither when living in Sweden nor in Australia.
> 
> A quick grep over the logfiles of a large ISP (>1 Mio POP accesses a day)
> tells me that less then 0.1% of the connections die while sending something
> to the client. There are another about 0.2% where the client didn't properly
> close the connection with QUIT, but they happen while waiting for the next
> command.

Here's some data from a small ISP in Moscow, Russia (the log is for
about a day):

cannabis!root:~# grep -c 'Authentication passed' /var/log/popper
28042
cannabis!root:~# grep -c 'Authentication failed' /var/log/popper
699
cannabis!root:~# grep -c 'Session crashed' /var/log/popper
198
cannabis!root:~# grep -c 'Connection timed out' /var/log/popper
46
cannabis!root:~# grep -c 'Another MUA active' /var/log/popper
7

About 0.7% of the sessions crashed while sending something to the
client, and almost 1% didn't terminate with a QUIT.  There may also
be a few cases where people don't interrupt a slow connection (to
re-dial or re-connect over a network) because they know they wouldn't
be able to continue the transfer of a large message.

I'm not sure if the problem is worth an extension to the protocol,
but as long as this is an optional protocol feature and there're not
going to be any clients that will refuse to support older servers, I
don't see any problem with defining the extension.

Signed,
Solar Designer

From owner-ietf-pop3ext  Fri Feb 18 10:44:27 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26488
	for ietf-pop3ext-bks; Fri, 18 Feb 2000 10:44:27 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA26484
	for <ietf-pop3ext@imc.org>; Fri, 18 Feb 2000 10:44:26 -0800 (PST)
Received: from 172.30.236.230 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 18 Feb 2000 10:42:05 -0800 (Pacific Standard Time)
Received: from MIKEGA9 ([157.59.255.155]) by popdog.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 19B8LHM1; Fri, 18 Feb 2000 10:42:09 -0800
Message-ID: <000201bf7a40$160a4290$9bff3b9d@redmond.corp.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Anders Rundegren" <anders@rundegren.com>, <ietf-pop3ext@imc.org>
References: <38ABE019.73E11FCC@rundegren.com>
Subject: Re: Extended RETR - version 2
Date: Fri, 18 Feb 2000 10:43:45 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Re: Extended RETR - version 2Anders writes:
>> A quick grep over the logfiles of a large ISP (>1 Mio POP accesses a day)
>> tells me that less then 0.1% of the connections die while sending
something
>> to the client. There are another about 0.2% where the client didn't
properly
>> close the connection with QUIT, but they happen while waiting for the
next
>> command.
>Where in the world is the above statistics from?
>A few years/months from now this number is probably going to increase,
>given the nature of the Internet, i.e. everything escalates beyond
>everyone's imagination. :)

Not necessarily.  I think a strong case can be made that while the volume
may increase, the quality is also increasing as well.  As I mentioned
earlier, I have no objections to this extension from a technical point of
view, just pointing out that before we extend POP, lets make sure that we
are solving a real problem.  A large part of POP's success is due to its
simplicity.



From owner-ietf-pop3ext  Fri Feb 18 21:22:16 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27152
	for ietf-pop3ext-bks; Fri, 18 Feb 2000 21:22:16 -0800 (PST)
Received: from musse.tninet.se (musse.tninet.se [195.100.94.12])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA27146
	for <ietf-pop3ext@imc.org>; Fri, 18 Feb 2000 21:22:14 -0800 (PST)
Received: (qmail 18526 invoked from network); 19 Feb 2000 06:25:52 +0100
Received: from sinclair.tninet.se (195.100.94.101)
  by musse.tninet.se with SMTP; 19 Feb 2000 06:25:52 +0100
Received: from  rundegren.com (sdu9-201.ppp.algonet.se [195.163.201.9])
 by tninet.se (BLUETAIL Mail Robustifier1.1.9) with ESMTP
 id s1673770t209083-bmr2-sinclair
 ; Sat, 19 Feb 2000 06:25:51 +0100
Message-ID: <38AE2986.6E15B481@rundegren.com>
Date: Sat, 19 Feb 2000 06:26:30 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Gahrns <mikega@microsoft.com>
CC: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 2
References: <38ABE019.73E11FCC@rundegren.com> <000201bf7a40$160a4290$9bff3b9d@redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> >Where in the world is the above statistics from?

Correction: the above question was meant to be referring to geographic
location (please excuse my malformed translation).

> Not necessarily.  I think a strong case can be made that while the volume
> may increase, the quality is also increasing as well.  As I mentioned
> earlier, I have no objections to this extension from a technical point of
> view, just pointing out that before we extend POP, lets make sure that we
> are solving a real problem.  A large part of POP's success is due to its
> simplicity.

Exactly what are you referring to by "quality", please specify.

// Anders

From owner-ietf-pop3ext  Fri Feb 18 23:33:16 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA01842
	for ietf-pop3ext-bks; Fri, 18 Feb 2000 23:33:16 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA01838
	for <ietf-pop3ext@imc.org>; Fri, 18 Feb 2000 23:33:14 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id BAA18649; Sat, 19 Feb 2000 01:36:45 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id KAA06592; Sat, 19 Feb 2000 10:33:59 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200002190733.KAA06592@false.com>
Subject: Re: Extended RETR - version 2
In-Reply-To: <38AB404D.E9E77193@rundegren.com> from Anders Rundegren at "Feb 17, 0 01:26:53 am"
To: anders@rundegren.com (Anders Rundegren)
Date: Sat, 19 Feb 2000 10:33:58 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> I'm attaching the revised version of the draft (I haven't uploaded it to
> IETF since I thought you might have more comments, which I hope). I've

Below are my proposed changes to the draft.  If the reasoning behind
some is non-obvious, just ask. :-)

--- extended-retr-draft-v2.txt	Sat Feb 19 08:05:15 2000
+++ extended-retr-draft-v2s.txt	Sat Feb 19 10:25:29 2000
@@ -81,23 +81,19 @@
         parts, more commonly known as attachments. These attachments
         are often much larger than the readable textparts.
 
-        Many clients connecting to an ISP, or even the ISP itself,
-        have their modems setup in a way that doesn't handle a noisy
-        phoneline very well. When line-quality isn't high enough, this
-        often results in a premature disconnect.
-
-        Using commands currently found in the the POP3 protocol, these
-        messages will have to be re-downloaded from scratch taking a
-        lot of unnecessary bandwidth from the ISP, not to mention
-        resources within the system itself.
+        Currently, POP3 requires messages to be re-downloaded from
+        scratch should there be a premature disconnect during a
+        message transfer. Such disconnects happen for various reasons,
+        including poor phone line quality, modem setup, network packet
+        loss, and temporary network problems.
 
         By extending the RETR command, the download-and-delete model
         that characterizes the POP3 protocol becomes more complete in
-        handling todays requirements of email. Consider the benefits:
+        handling todays requirements of email. The benefits are:
 
-        a) Less resources used on the server-side
-        b) Less time used online for the client
-        c) Less consumption of bandwidth
+        a) Less time used online for the client
+        b) Less consumption of bandwidth
+        c) Less resources used on the server side
 
 
 2. The Extended RETR Command
@@ -109,7 +105,8 @@
 
         The RETR command (as specified by RFC 1939), takes one argument
         which specifies the message to be retrieved by the client. The
-        possible responses are "+OK" and "-ERR", without the quotes.
+        allowed responses are "+OK" and "-ERR", without the quotes,
+        possibly followed by a space and a comment.
 
 
 A. Rundegren                                                    [page 2]
@@ -121,11 +118,14 @@
 
         The second argument to the extended RETR command specifies the
         offset in the message of where the transfer should start. The
-        offset is given in octets. All data that is transferred with a
-        standard RETR command should be accounted for. This means that
-        top headers, followed by messageparts will be transferred, in
-        that order. As specified by RFC 1939, responses can not be more
-        than 512 characters long, including the terminating CRLF.
+        offset is given in octets, and is calculated the way message
+        sizes are, as defined in section 11 of RFC 1939. In order to
+        ensure a valid multi-line response, with all lines terminated
+        with a CRLF pair (and never a single LF), the offset MUST NOT
+        point into the middle of a CRLF pair.
+
+        As specified by RFC 1939, responses can not be more than 512
+        characters long, including the terminating CRLF.
 
         The syntax of the extended RETR command would be:
 
@@ -140,7 +140,7 @@
 
         Description:
             If the POP3 server issues a positive response, then the
-            response given is multi-line. After the intial +OK, the
+            response given is multi-line. After the initial +OK, the
             POP3 server sends the message corresponding to the given
             message-number, starting from the offset provided, being
             careful to byte-stuff the termination character (as with
@@ -154,15 +154,24 @@
             C: RETR 1 345628
             S: +OK 1253512 octets
             S: <the POP3 server sends the message here, starting with
-                the 345628th octet of the message>
+                the 345629th octet of the message>
+            S: .
+               ...
+            C: RETR 1 1599140
+            S: +OK 0 octets
             S: .
 
+        Offsets equal to the message size are allowed, as shown in the
+        last example. This can be used by a client to check if it has
+        a complete message and continue the transfer if not, with one
+        command.
+
         If the specified offset is beyond the size of the message being
-        retrieved, or in any other way erroneous in its syntax, the
-        server should respond with a negative response code. This would
-        however not distinguish the type of error. In the following
-        section you can read about the use of extended response codes
-        to clarify errormessages.
+        retrieved, points into the middle of a CRLF pair, or is in any
+        way erroneous in its syntax, the server should respond with a
+        negative response code. This would however not distinguish the
+        type of error. In the following section you can read about the
+        use of extended response codes to clarify error messages.
 
 
 
@@ -209,10 +218,10 @@
         to work. However, this memo specifies the extended response
         codes to be used if implemented.
 
-        If the specified offset is beyond the size of the message being
-        retrieved, the extended response code should be:
+        If the specified offset is in any way erroneous, the extended
+        response code should be:
 
-            -ERR [OFFSET-OVERRUN] message exists
+            -ERR [INVALID-OFFSET] message exists
 
         If an error occured because the message was not present on the
         server, the extended response code should be:
@@ -237,13 +246,15 @@
 
         The extended RETR command introduces a new CAPA tag (RFC 2449).
         This tag tells the client that the server is able to continue
-        interrupted RETR commands. Its implementation is mandatory.
+        interrupted RETR commands. Its implementation is mandatory if
+        the server supports this extension and the CAPA command.
 
         CAPA tag:
             EXT-RETR
 
         Arguments:
-            none
+            one of ALWAYS, YES or NO in TRANSACTION state, an optional
+            ALWAYS specifier in AUTHORIZATION state
 
         Added commands:
             n/a
@@ -252,7 +263,7 @@
             RETR
 
         Announced states / possible differences:
-            both / no
+            both / yes
 
         Commands valid in states:
             TRANSACTION
@@ -262,9 +273,21 @@
 
         Discussion:
             The extended RETR capability indicates that the server is
-            capable of excepting a second argument to the RETR command
+            capable of accepting a second argument to the RETR command
             in order to resume a previously interrupted RETR command.
 
+            If a server supports this extension for at least some of
+            the maildrops, it MUST announce the extension while in
+            the AUTHORIZATION state. If the extension is supported
+            for all of the maildrops, the server SHOULD also include
+            the ALWAYS specifier, so that clients don't have to
+            reissue the CAPA command after entering the TRANSACTION
+            state. If announced in the AUTHORIZATION state, the
+            server MUST announce the capability in the TRANSACTION
+            state as well. If the extension is not supported for the
+            particular maildrop, the argument should be set to NO.
+            Otherwise, the argument can be set to either ALWAYS or
+            YES, which should be treated the same by clients.
 
 
 
@@ -293,8 +316,10 @@
 
 5. Security Considerations
 
-        Use of the extended RETR command sends messages in the clear
-        over the network.
+        This extension is believed not to introduce additional
+        security issues. Use of the RETR command sends messages in
+        the clear over the network, unless an encryption layer has
+        been previously negotiated.
 
 
 6. Acknowledgements


From owner-ietf-pop3ext  Sat Feb 19 01:45:21 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA09115
	for ietf-pop3ext-bks; Sat, 19 Feb 2000 01:45:21 -0800 (PST)
Received: from mail.remote.org (mail@visby.remote.org [212.227.14.25])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09109
	for <ietf-pop3ext@imc.org>; Sat, 19 Feb 2000 01:45:19 -0800 (PST)
Received: from localhost
	by mail.remote.org with local-rmail 
	id 12M6VZ-0008Ro-00; Sat, 19 Feb 2000 10:49:01 +0100
Received: from sqrt by eldorado.remote.org with local (Exim 2.02 #1)
	id 12M6Uo-0002CR-00
	for ietf-pop3ext@imc.org; Sat, 19 Feb 2000 10:48:14 +0100
Date: Sat, 19 Feb 2000 10:48:14 +0100
From: Jochen Topf <jochen@remote.org>
To: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 2
Message-ID: <20000219104814.A8413@eldorado.remote.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Anders Rundegren <anders@rundegren.com> wrote:
:> >Where in the world is the above statistics from?

: Correction: the above question was meant to be referring to geographic
: location (please excuse my malformed translation).

Germany.

I have no historical data at the moment to tell us, whether the numbers are
getting better or worse. But I am quite sure that they are getting better.
>From my view there is no need for the extended RETR, but maybe others see
different statistics here.

Would be nice to have some more statistics from other parts of the world
and other types of ISPs.

Another thing: The offset and bytestuffing issue is really the killer here.
If this is not documented properly and there is only one implementation
doing it differently the whole thing is worthless, because it will lead
to corrupted email. I suggest adding a paragraph mentioning that the offset
is calculated by using CRLF line endings, just to make sure.

And another caveat: The RFC should mention that there is no guarantee that
the message numbering stays the same from one POP connection to the next.
For instance, if there is another process accessing the same mailbox at the
same time it might have deleted a message. So if the client wants to use
extended RETR it MUST use UIDL to find the right message number, which further
complicates the matter and is an easy trap for the implementor to fall into.

And a third caveat: There might be server implementations that send some
error message when dieing unexpectedly. For instance when the server gets
a signal it might send a "-ERR I am out of here" message or similar. If this
can ever happen while the server is sending the mail, the client would
probabely not notice this, take this message as part of the mail, and ask
for a retransmit with the wrong offset resulting in a corrupted mail. I don't
know of any server with this behaviour, but it is a possible szenario. So
when the author of the server implements the extended RETR, he has to make
sure, that this can never happen with his server.

Jochen
-- 
Jochen Topf - jochen@remote.org - http://www.remote.org/jochen/


From owner-ietf-pop3ext  Sun Feb 20 05:32:06 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA16214
	for ietf-pop3ext-bks; Sun, 20 Feb 2000 05:32:06 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA16210
	for <ietf-pop3ext@imc.org>; Sun, 20 Feb 2000 05:32:04 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id HAA11385; Sun, 20 Feb 2000 07:35:45 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id QAA07926; Sun, 20 Feb 2000 16:31:07 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200002201331.QAA07926@false.com>
Subject: Re: Extended RETR - version 2
In-Reply-To: <20000219104814.A8413@eldorado.remote.org> from Jochen Topf at "Feb 19, 0 10:48:14 am"
To: jochen@remote.org (Jochen Topf)
Date: Sun, 20 Feb 2000 16:31:07 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> 
> I have no historical data at the moment to tell us, whether the numbers are
> getting better or worse. But I am quite sure that they are getting better.
> From my view there is no need for the extended RETR, but maybe others see
> different statistics here.

It's not obvious to me whether we need this extension or not, but I
don't see any harm in it either, and I do hear some user complaints
about wasting their money downloading a large message from scratch.
(Fortunately, my job doesn't involve user support.)

If someone has volunteered to define the extension anyway, it seems
better to ensure there're no hidden uncertainties left.

> Would be nice to have some more statistics from other parts of the world
> and other types of ISPs.

The statistics posted here so far only show the overhead caused by
re-transmissions as seen by ISP's.  It's likely that some users are
getting disconnected more often than some of the others.  While we
see under 1% POP3 sessions interrupted during a message transfer on
average for an ISP, there may well be over 10% such sessions for a
given user.  If that user once receives a huge message, a disconnect
during the transfer of that message is even more likely.

If we look at the statistics, it's also important to note that most
of the POP3 sessions are to empty mailboxes, and thus didn't have a
real chance to crash.  It makes more sense to count POP3 sessions
that transferred at least one message and use that when calculating
the percentage of crashed transfers.

> Another thing: The offset and bytestuffing issue is really the killer here.
> If this is not documented properly and there is only one implementation
> doing it differently the whole thing is worthless, because it will lead

I think there should be at least two independent implementations
before this becomes an RFC (if ever).  Then new implementations could
be checked against those two.

> to corrupted email. I suggest adding a paragraph mentioning that the offset
> is calculated by using CRLF line endings, just to make sure.

I think the reference to section 11 of RFC 1939 covers that.

> And another caveat: The RFC should mention that there is no guarantee that
> the message numbering stays the same from one POP connection to the next.

Agreed.

> And a third caveat: There might be server implementations that send some
> error message when dieing unexpectedly. For instance when the server gets
> a signal it might send a "-ERR I am out of here" message or similar. If this
> can ever happen while the server is sending the mail, the client would

That would violate RFC 1939 anyway.

Signed,
Solar Designer

From owner-ietf-pop3ext  Fri Feb 25 20:25:23 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19833
	for ietf-pop3ext-bks; Fri, 25 Feb 2000 20:25:23 -0800 (PST)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19828
	for <ietf-pop3ext@imc.org>; Fri, 25 Feb 2000 20:25:22 -0800 (PST)
Received: from 129.46.242.106 (randy-mac.qualcomm.com [129.46.242.106]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.15) with ESMTP id UAA06997 for <ietf-pop3ext@imc.org>; Fri, 25 Feb 2000 20:25:04 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p04301420b4dd057f0b83@129.46.242.106>
X-Mailer: QUALCOMM Eudora Pro v4.2 for Macintosh
Date: Fri, 25 Feb 2000 20:24:26 -0800
To: ietf-pop3ext@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: The SYS and AUTH Response Codes
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: v1.0b12
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

I just sent in a draft defining the SYS and AUTH response codes and 
the AUTH-RESP-CODE capability.   Before it shows up in the I-D 
directories, it can be obtained from 
<ftp://ftp.pensive.org/Public/Randy/draft-gellens-pop-err-00.txt>.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Advertising is 85 percent confusion and 15 percent commission.
                                                 --Fred Allen

From owner-ietf-pop3ext  Sat Feb 26 04:02:54 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA07271
	for ietf-pop3ext-bks; Sat, 26 Feb 2000 04:02:54 -0800 (PST)
Received: from knatte.tninet.se (knatte.tninet.se [195.100.94.10])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA07267
	for <ietf-pop3ext@imc.org>; Sat, 26 Feb 2000 04:02:51 -0800 (PST)
Received: (qmail 17907 invoked from network); 26 Feb 2000 13:02:35 +0100
Received: from garibaldi.tninet.se (195.100.94.103)
  by knatte.tninet.se with SMTP; 26 Feb 2000 13:02:35 +0100
Received: from  rundegren.com (sdu181-201.ppp.algonet.se [195.163.201.181])
 by tninet.se (BLUETAIL Mail Robustifier1.1.9) with ESMTP
 id s3087423t363963-bmr2-garibaldi for <ietf-pop3ext@imc.org>
 ; Sat, 26 Feb 2000 13:02:33 +0100
Message-ID: <38B7C0E1.FE6B60D3@rundegren.com>
Date: Sat, 26 Feb 2000 13:02:41 +0100
From: Anders Rundegren <anders@rundegren.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 3
References: <20000219104814.A8413@eldorado.remote.org>
Content-Type: multipart/mixed;
 boundary="------------C761A1235DE3A859830F0320"
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------C761A1235DE3A859830F0320
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've attached version 3 of the draft describing the extended RETR
command. It incorporates some changes, suggested by Solar Designer and
Jochen Topf. Some suggested changes hasn't been incorporated, see my
reasoning for this below.

"Offsets equal to message sizes are allowed"
--------------------------------------------
I didn't add this to the draft since I found it redundant. If a message
transfer being resumed doesn't end with a '.' on a new line followed by
a CRLF pair, the transfer would be considered to be incomplete anyway.
There should be no need for the server to "double-check" this. Also, it
introduces further complexity to the extension.

"CAPA tag re-definition"
------------------------
This re-definition of the CAPA tag introduces furthermore complexity and
I fail to see the use of being able to specify the availability of the
extension to individual users maildrops.

I'm not sure on how to best solve the problem with message numbering not
being the same between sessions, for now I've included a note to
implementors that the use of UIDL is required to ensure validity of the
downloaded message.

Please continue with all feedback! I find comments posted on this list
to be extremely helpful in "bug-tracking" the specification of the
extension.

// Anders
--------------C761A1235DE3A859830F0320
Content-Type: text/plain; charset=us-ascii;
 name="extended-retr-draft-v3.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="extended-retr-draft-v3.txt"

INTERNET-DRAFT                                            INTERNET-DRAFT
                                                            A. Rundegren
                                                       26 February, 2000


                  Extended RETR - Extension to POP3
                    <draft-rundegren-pop3-01.txt>           


Status of this Memo

        This document is an Internet-Draft and is in full
        conformance with all provisions of Section 10 of RFC2026.

        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups. Note that other groups may also distribute working
        documents as Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be
        accessed at http://www.ietf.org/shadow.html.

        Distribution of this document is unlimited. Please send
        comments to the author.


Abstract

        This memo introduces an extension to the RETR command in the
        POP3 protocol. The extension makes it possible for an
        interrupted RETR command to be continued. This is
        particularly useful when downloading large messages over
        unstable connections.














A. Rundegren                                                    [page 1]
-- LINE -- 58 --
INTERNET-DRAFT                                         26 February, 2000


Table of Contents
        1.  Introduction  ...........................................  2
        2.  The Extended RETR Command  ..............................  2
          2.1  RFC 1939 Specification  ..............................  2
          2.2  The Offset Argument  .................................  3
	  2.3  Bytestuffing  ........................................  4
        3.  Extended Response Codes  ................................  5
        4.  The CAPA Tag  ...........................................  5
        5.  Security Considerations  ................................  6
        6.  Acknowledgements  .......................................  6
        7.  References  .............................................  6
        8.  Author's Address  .......................................  6


1. Introduction

        When email was first developed it was intended to transfer
        readable text messages. Since the introduction of MIME (RFC
        2045) it has become more common to transfer other message
        parts, more commonly known as attachments. These attachments
        are often much larger than the readable textparts.

        The current POP3 specification requires messages to
        re-downloaded from scratch in the case of a premature
        disconnect during a message transfer.

        Such disconnects happens for various reasons, including poor
        phone line quality, modem setup, network packet loss and
        temporary network problems.

        By extending the RETR command, the download-and-delete model
        that characterizes the POP3 protocol becomes more complete in
        handling todays requirements of email. The benefits are:

        a) Less time used online for the client
        b) Less resources used on the server-side
        c) Less consumption of bandwidth


2. The Extended RETR Command

        This section will give a detailed view on how the second
        argument of the extended RETR command should be implemented.

2.1 RFC 1939 Specification

        The RETR command (as specified by RFC 1939), takes one argument
        which specifies the message to be retrieved by the client. The
        allowed responses are "+OK" and "-ERR", without the quotes,
        possible followed by a space (decimal code 032) and a comment.



A. Rundegren                                                    [page 2]
-- LINE -- 116 --
INTERNET-DRAFT                                         26 February, 2000


2.2 The Offset Argument

        The second argument to the extended RETR command specifies the
        offset in the message of where the transfer should start. The
        offset is given in octets, and is calculated the way message
        sizes are , as defined in section 11 of RFC 1939. In order to
        ensure a valid multi-line response, with all lines terminated
        with a CRLF pair, the offset MUST NOT point into the middle of
        a CRLF pair.

        As specified by RFC 1939, responses can not be more htan 512
        characters long, including the terminating CRLF.

        Implementors should note that there is no guarantee that
        the message numbering stays the same between sessions. In
        order to ensure the validity of a downloaded message,
        the use of a UIDL command is required.

        The syntax of the extended RETR command would be:

            RETR msg offset

        Arguments:
            A message-number (required) which may NOT refer to a
            message marked as deleted. An offset (optional) of where
            to start the transfer, specified in octets. If the offset
            argument is omitted, the message will be sent as specified
            by the RETR command in RFC 1939.

        Description:
            If the POP3 server issues a positive response, then the
            response given is multi-line. After the initial +OK, the
            POP3 server sends the message corresponding to the given
            message-number, starting from the offset provided, being
            careful to byte-stuff the termination character (as with
            all multi-line responses).            

        Possible Responses:
            +OK message follows
            -ERR no such message

        Examples:
            C: RETR 1 345628
            S: +OK 1253512 octets
            S: <the POP3 server sends the message here, starting with
                the 345629th octet of the message>
            S: .






A. Rundegren                                                    [page 3]
-- LINE -- 174 --
INTERNET-DRAFT                                         26 February, 2000


        If the specified offset is beyond the size of the message being
        retrieved, points into the middle of a CRLF pair, or in any
        other way erroneous in its syntax, the server should respond
        with a negative response code. This would however not
        distinguish the type of error. In the following section you
        can read about the use of extended response codes to clarify
        errormessages.


2.3 Bytestuffing

        This section explains how bytestuffing should be performed when
        resuming a previously interrupted transfer. When data is to be
        transferred from the server to the client, the server should
        be careful to byte-stuff all data. If the previous transfer
        was interrupted in the middle of a line, where the remaining
        part of the line starts with a '.' character, this means that
        data, that would normally not be bytestuffed (since it's not in
        the beginning of a line), must be byte-stuffed. Any octets added
        by any data-stuffing algorithm do not count as part of the offset
        used by the Extended RETR command.


        Examples:
            Message number is 1.
            Message size is 217,743 octets.
            Offset 113,435 starts with a '.'.

            Lets assume, that when transferring the above message, an
            interrupt occurs after exactly 113,435 octets. When
            resuming the transfer, the client executes "RETR 1 113435".
            The server then byte-stuffs the data before transferring it
            to the client, who then byte-destuffs the data before
            appending it to the previously transferred data.



















A. Rundegren                                                    [page 4]
-- LINE -- 232 --
INTERNET-DRAFT                                         26 February, 2000


3. Extended Response Codes

        The extended RETR command does not require the implementation
        of extended response codes (RFC 2449) to be present in order
        to work. However, this memo specifies the extended response
        codes to be used if implemented.

        If the specified offset is beyond the size of the message being
        retrieved, the extended response code should be:

            -ERR [OFFSET-OVERRUN] message exists

        If an error occured because the message was not present on the
        server, the extended response code should be:

            -ERR [NON-EXISTENT] no such message

        For all other type of errors, a simple "-ERR" is sufficient.


4. The CAPA Tag

        The extended RETR command introduces a new CAPA tag (RFC 2449).
        This tag tells the client that the server is able to continue
        interrupted RETR commands. Its implementation is mandatory if
        the server supports this extension and the CAPA command.

        CAPA tag:
            EXT-RETR

        Arguments:
            none

        Added commands:
            n/a

        Standard commands affected:
            RETR

        Announced states / possible differences:
            both / no

        Commands valid in states:
            TRANSACTION

        Specification reference:
            [POP3, this document]

        Discussion:
            The extended RETR capability indicates that the server is
            capable of excepting a second argument to the RETR command
            in order to resume a previously interrupted RETR command.


A. Rundegren                                                    [page 5]
-- LINE -- 290 --
INTERNET-DRAFT                                         26 February, 2000


5. Security Considerations

        This extension is believed not to introduce additional security
        issues. Use of the extended RETR command sends messages in the
        clear over the network, unless an encryption layer has been
        previously negotiated.


6. Acknowledgements

        The extension introduced in this memo is based on the RETR
        command as specified in RFC 1939. I would like to thank
        R. Gellens, C. Newman and L. Lundblade for their comments
        and suggestions during the drafting of this document.


7. References

        1)  Post Office Protocol - Version 3 (RFC 1939).
            J. Myers, M. Rose.

        2)  Multipurpose Internet Mail Extensions, Part One (RFC 2045).
            N. Freed, N. Borenstein.

        3)  POP3 Extension Mechanism (RFC 2449).
            R. Gellens, C. Newman, L. Lundblade.


8. Author's Address

        Anders Rundegren
        Skimmelgatan 1
        212 35 Malmo
        Sweden

        email: anders@rundegren.com

















A. Rundegren                                                    [page 6]
-- LINE -- 348 --

--------------C761A1235DE3A859830F0320--


From owner-ietf-pop3ext  Mon Feb 28 16:18:58 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25371
	for ietf-pop3ext-bks; Mon, 28 Feb 2000 16:18:58 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA25365
	for <ietf-pop3ext@imc.org>; Mon, 28 Feb 2000 16:18:56 -0800 (PST)
Received: from 172.30.236.230 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 28 Feb 2000 16:11:14 -0800 (Pacific Standard Time)
Received: from MIKEGA9 ([157.59.255.155]) by popdog.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id F4XH18LV; Mon, 28 Feb 2000 16:11:19 -0800
Message-ID: <000401bf8249$d2d0dc70$9bff3b9d@redmond.corp.microsoft.com>
From: "Mike Gahrns" <mikega@microsoft.com>
To: "Anders Rundegren" <anders@rundegren.com>
Cc: <ietf-pop3ext@imc.org>
References: <38AE2986.6E15B481@rundegren.com>
Subject: Re: Extended RETR - version 2
Date: Mon, 28 Feb 2000 16:13:36 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Re: Extended RETR - version 2>> Not necessarily.  I think a strong case can
be made that while the volume
>> may increase, the quality is also increasing as well.  As I mentioned
>> earlier, I have no objections to this extension from a technical point of
>> view, just pointing out that before we extend POP, lets make sure that we
>> are solving a real problem.  A large part of POP's success is due to its
> >simplicity.
>Exactly what are you referring to by "quality", please specify.
>// Anders
*** Sorry for the delay in responding. I did not have email access last
week...
This comment was in regards to a previous statement that the number of line
errors that occur and cause a message to be RETR'd again will only increase,
as the use of the internet continues to grow beyond everybody's
expectations.   The point I was trying to make was that although volume will
no doubt increase, the quality of the lines/connections is also increasing.
I would bet that in most of the world today, the quality of the connection
is at a point where line quality is a non-issue, and for those parts of the
world where line quality is still an issue, I would suspect that quality
will rapidly improve.


From owner-ietf-pop3ext  Mon Feb 28 16:29:10 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25585
	for ietf-pop3ext-bks; Mon, 28 Feb 2000 16:29:10 -0800 (PST)
Received: from samspade.org (qmailr@blighty.com [206.117.161.80])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA25581
	for <ietf-pop3ext@imc.org>; Mon, 28 Feb 2000 16:29:09 -0800 (PST)
Received: (qmail 12080 invoked by uid 500); 29 Feb 2000 00:29:14 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 29 Feb 2000 00:29:14 -0000
Date: Mon, 28 Feb 2000 16:29:13 -0800 (PST)
From: <steve@blighty.com>
To: ietf-pop3ext@imc.org
Subject: Re: Extended RETR - version 2
In-Reply-To: <000401bf8249$d2d0dc70$9bff3b9d@redmond.corp.microsoft.com>
Message-ID: <Pine.LNX.4.04.10002281621270.10958-100000@blighty.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pop3ext@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>



On Mon, 28 Feb 2000, Mike Gahrns wrote:

> Re: Extended RETR - version 2>> Not necessarily.  I think a strong case can
> be made that while the volume
> >> may increase, the quality is also increasing as well.  As I mentioned
> >> earlier, I have no objections to this extension from a technical point of
> >> view, just pointing out that before we extend POP, lets make sure that we
> >> are solving a real problem.  A large part of POP's success is due to its
> > >simplicity.
> >Exactly what are you referring to by "quality", please specify.
> >// Anders
> *** Sorry for the delay in responding. I did not have email access last
> week...
> This comment was in regards to a previous statement that the number of line
> errors that occur and cause a message to be RETR'd again will only increase,
> as the use of the internet continues to grow beyond everybody's
> expectations.   The point I was trying to make was that although volume will
> no doubt increase, the quality of the lines/connections is also increasing.
> I would bet that in most of the world today, the quality of the connection
> is at a point where line quality is a non-issue, and for those parts of the
> world where line quality is still an issue, I would suspect that quality
> will rapidly improve.

It has a long way to go. I'm just between silicon valley and San
Francisco, one of the most wired parts of the world. I'm only 2.5 miles
from my local PacBell switch.

While I wait for DSL I'm using AOLs dialup pool. I regularly get
connection drops. Whether that's due to faulty equipment at AOL or whether
it's due to genuine line-quality issues doesn't really matter to me as an
end-user. As higher bandwidth connectivity rolls into an area the POTS
providers are pushed down market and the quality of service drops (at the
low end of the dialup market, anyway).

Dialup isn't particularly reliable in general right now. Were I trying to
download megabyte+ mails via POP3 I'd be retrying after connection drop
fairly often.

Cheers,
  Steve


From owner-ietf-pop3ext  Tue Mar 14 11:35:52 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15391
	for ietf-pop3ext-bks; Tue, 14 Mar 2000 11:35:52 -0800 (PST)
Received: from laptop.imc.org (ip12.proper.com [165.227.249.12])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15382
	for <ietf-pop3ext@imc.org>; Tue, 14 Mar 2000 11:35:50 -0800 (PST)
Message-Id: <4.3.2.20000314113237.00aa9d50@mail.imc.org>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Tue, 14 Mar 2000 11:32:44 -0800
To: ietf-pop3ext@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Announcement of MailConnect 6
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Greetings again. IMC is pleased to announce our next testing event, 
MailConnect 6. The event will focus on IMAP4, POP3, and SMTP, and will be 
held May 31 and June 1 in San Jose, CA. Full details are available at 
<http://www.imc.org/imc-mailconnect/>.

The two days of MailConnect 6 will focus on IMAP4. IMAP4 is a 
well-established specification with new facilities promising substantial 
improvement for mobile and client/server mail environments. IMAP4 
implementations have fully emerged, although the large number of new of 
IMAP extensions have not been subjected to wide inter-vendor testing. 
MailConnect 6 will provide an opportunity for intense interoperability 
testing and repair of IMAP4 implementations.

During the previous MailConnect events, it has become clear that client 
developers need to pay more attention to the disconnected mode of IMAP. 
MailConnect is an excellent place for client and server vendors to test 
interoperability in this area. Further, IMAP is a dynamic protocol, and 
many valuable extensions have been proposed in the past year. Developers 
will want to meet with other developers at MailConnect to test their early 
implementations of these extensions.

Because most IMAP vendors also have POP3 and SMTP implementations, 
MailConnect 6 will be a good place to test them as well. A new round of 
extensions to POP have come out in the past year, and client vendors have 
expressed strong interest in testing these. Also in the past year, many 
extensions to SMTP have been standardized and deployed; these new features 
will be the focus of the SMTP testing at MailConnect 6. Specifically, 
message submission, SMTP over TLS, and SMTP authorization are likely 
candidates for participant testing.

--Paul Hoffman, Director
--Internet Mail Consortium


From owner-ietf-pop3ext  Thu Mar 23 23:04:33 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA12956
	for ietf-pop3ext-bks; Thu, 23 Mar 2000 23:04:33 -0800 (PST)
Received: from hotmail.com (oe18.law4.hotmail.com [216.33.148.122])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA12949
	for <ietf-pop3ext@imc.org>; Thu, 23 Mar 2000 23:04:32 -0800 (PST)
Received: (qmail 14468 invoked by uid 65534); 24 Mar 2000 07:06:03 -0000
Message-ID: <20000324070603.14467.qmail@hotmail.com>
X-Originating-IP: [164.164.12.10]
From: "Faheem" <faheem@mail.com>
To: "IETF-POP3 Ext" <ietf-pop3ext@imc.org>
Subject: A suggestion for RFC1939
Date: Fri, 24 Mar 2000 12:37:04 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0022_01BF958D.A8FBE0F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01BF958D.A8FBE0F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

I don't understand why RFC1939 restricts to using message number with =
the DELE command. Using the messageID (UIDL) with the DELE command would =
be a lot more useful where the user agent can be sure of which message =
it is deleting.=20

In which case I'd rather  go ahead with the following sequence.
DELE 20000304062907.AAA.e0081efb  =20
DELE 20000304062908.AAA.e0081efb  =20
DELE ...........
..................
QUIT

So, can we please further our discussion on this if it seems to be =
helpful to most user agents?=20

Regards -Faheem
=20
Day Phone: +91+80+3312966
Night Phone: +91+80+5546449
Email: faheem@mail.com=20
Time Zone: GMT +05:30

------=_NextPart_000_0022_01BF958D.A8FBE0F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Hi All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>I don't understand why =
RFC1939 restricts=20
to using message number with the DELE command. Using the messageID =
(UIDL) with=20
the&nbsp;DELE command would be a lot more useful where the user agent =
can be=20
sure of which message it is deleting. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>In which case I'd =
rather&nbsp; go ahead=20
with the following sequence.</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE=20
20000304062907.AAA.e0081efb&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE=20
20000304062908.AAA.e0081efb&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>DELE ...........</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" =
size=3D2>..................</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>QUIT</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>So, can we please further our =
discussion=20
on this if it seems to be helpful to most user agents? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Regards -</FONT><FONT=20
face=3D"Comic Sans MS" size=3D2>Faheem</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Day Phone: =
+91+80+3312966</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Night Phone: =
+91+80+5546449</FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Email: </FONT><A=20
href=3D"mailto:faheem@mail.com">faheem@mail.com</A> </DIV>
<DIV>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Time Zone: GMT=20
+05:30</FONT></DIV></DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0022_01BF958D.A8FBE0F0--

From owner-ietf-pop3ext  Fri Mar 24 02:19:51 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id CAA24217
	for ietf-pop3ext-bks; Fri, 24 Mar 2000 02:19:51 -0800 (PST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA24213
	for <ietf-pop3ext@imc.org>; Fri, 24 Mar 2000 02:19:49 -0800 (PST)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2])
	by internal.mail.demon.net with ESMTP id KAA10349;
	Fri, 24 Mar 2000 10:21:46 GMT
Message-ID: <SvV1doAaE024QAwo@turnpike.com>
Date: Fri, 24 Mar 2000 10:19:06 +0000
To: ietf-pop3ext@imc.org
From: Paul Overell <paulo@turnpike.com>
Subject: Re: A suggestion for RFC1939
References: <20000324070603.14467.qmail@hotmail.com>
In-Reply-To: <20000324070603.14467.qmail@hotmail.com>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.00 beta 4 M <U2yaxlNz9mbtXQDcM+J3SutElj>
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

In article <20000324070603.14467.qmail@hotmail.com>, Faheem
<faheem@mail.com> writes
>    Hi All,
>    
>    I don't understand why RFC1939 restricts to using message number 
>    with the DELE command. Using the messageID (UIDL) with the DELE 
>    command would be a lot more useful where the user agent can be sure 
>    of which message it is deleting. 
>

A user agent can be absolutely sure which message gets deleted.  During
a POP3 session the mapping between message-numbers and UIDs is fixed,
there is no uncertainty.

>
>    In which case I'd rather go ahead with the following sequence.
>    DELE 20000304062907.AAA.e0081efb
>    DELE 20000304062908.AAA.e0081efb
>    DELE ...........
>    ..................
>    QUIT
>

This syntax is ambiguous, UIDs can be simple numbers and so confused
with message-numbers.

If this extension is required then a new command should be used for it.

>
>    So, can we please further our discussion on this if it seems to be 
>    helpful to most user agents? 
>

Even with this extension clients will still have to cope with un-
extended servers and continue to use DELE message-number with them.

Had this command been included in the original POP3 specification then I
would have no problem with it, but I'm afraid I can't see any point in
adding it now.

Regards

-- 
Paul Overell                                             T U R N P I K E

From owner-ietf-pop3ext  Fri Mar 24 08:42:47 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA07102
	for ietf-pop3ext-bks; Fri, 24 Mar 2000 08:42:47 -0800 (PST)
Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA07098
	for <ietf-pop3ext@imc.org>; Fri, 24 Mar 2000 08:42:46 -0800 (PST)
Received: from llundblade-laptop.qualcomm.com (llundblade-laptop.qualcomm.com [129.46.242.17]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id IAA14305; Fri, 24 Mar 2000 08:44:42 -0800 (PST)
Message-Id: <4.3.1.2.20000324084045.00e46cc0@hotsun.qualcomm.com>
X-Sender: lgl@hotsun.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 24 Mar 2000 08:43:42 -0800
To: "Faheem" <faheem@mail.com>, "IETF-POP3 Ext" <ietf-pop3ext@imc.org>
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: A suggestion for RFC1939
In-Reply-To: <20000324070603.14467.qmail@hotmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_79285824==_.ALT"
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

--=====================_79285824==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I very much agree with Paul. While this is a nice idea and how I would have 
chosen to do it at the start, there's so many POP clients out there that 
now that any implementation will have to support both forever. Adding a new 
way wouldn't save any body any work. It would just add. We'd never get away 
from having to do it the old way. Also note that UIDL is optional in the 
standard.

A similar annoyance is that TOP takes an argument in lines and LIST returns 
a value in bytes.

Both of these are because UIDL and TOP were late additions to the POP 
standard I believe.

LL

At 12:37 PM 3/24/00 +0530, Faheem wrote:
>Hi All,
>
>I don't understand why RFC1939 restricts to using message number with the 
>DELE command. Using the messageID (UIDL) with the DELE command would be a 
>lot more useful where the user agent can be sure of which message it is 
>deleting.
>
>In which case I'd rather  go ahead with the following sequence.
>DELE 20000304062907.AAA.e0081efb
>DELE 20000304062908.AAA.e0081efb
>DELE ...........
>..................
>QUIT
>
>So, can we please further our discussion on this if it seems to be helpful 
>to most user agents?
>
>Regards -Faheem
>
>Day Phone: +91+80+3312966
>Night Phone: +91+80+5546449
>Email: <mailto:faheem@mail.com>faheem@mail.com
>Time Zone: GMT +05:30

--=====================_79285824==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
I very much agree with Paul. While this is a nice idea and how I would
have chosen to do it at the start, there's so many POP clients out there
that now that any implementation will have to support both forever.
Adding a new way wouldn't save any body any work. It would just add. We'd
never get away from having to do it the old way. Also note that UIDL is
optional in the standard.<br>
<br>
A similar annoyance is that TOP takes an argument in lines and LIST
returns a value in bytes.<br>
<br>
Both of these are because UIDL and TOP were late additions to the POP
standard I believe.<br>
<br>
LL<br>
<br>
At 12:37 PM 3/24/00 +0530, Faheem wrote:<br>
<blockquote type=cite cite><font face="Comic Sans MS" size=2>Hi 
All,<br>
&nbsp;<br>
I don't understand why RFC1939 restricts to using message number with the
DELE command. Using the messageID (UIDL) with the DELE command would be a
lot more useful where the user agent can be sure of which message it is
deleting. <br>
&nbsp;<br>
In which case I'd rather&nbsp; go ahead with the following 
sequence.<br>
DELE 20000304062907.AAA.e0081efb&nbsp;&nbsp; <br>
DELE 20000304062908.AAA.e0081efb&nbsp;&nbsp; <br>
DELE ...........<br>
..................<br>
QUIT<br>
&nbsp;<br>
So, can we please further our discussion on this if it seems to be
helpful to most user agents? <br>
&nbsp;<br>
Regards -Faheem<br>
&nbsp;<br>
Day Phone: +91+80+3312966<br>
Night Phone: +91+80+5546449<br>
Email: <a href="mailto:faheem@mail.com">faheem@mail.com</a> <br>
Time Zone: GMT +05:30</font></blockquote></html>

--=====================_79285824==_.ALT--


From owner-ietf-pop3ext  Sat Mar 25 12:55:53 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23480
	for ietf-pop3ext-bks; Sat, 25 Mar 2000 12:55:53 -0800 (PST)
Received: from mystic.false.com (root@false.com [198.65.171.171])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23476
	for <ietf-pop3ext@imc.org>; Sat, 25 Mar 2000 12:55:52 -0800 (PST)
Received: from false.com (root@false.com [198.65.171.171]) by mystic.false.com (8.9.3/8.9.3) with ESMTP id OAA31805; Sat, 25 Mar 2000 14:57:36 -0600
Received: (from solar@localhost) by false.com (8.8.5/8.8.5) id XAA15545; Sat, 25 Mar 2000 23:16:04 +0300
From: Solar Designer <solar@false.com>
Message-Id: <200003252016.XAA15545@false.com>
Subject: Re: A suggestion for RFC1939
In-Reply-To: <SvV1doAaE024QAwo@turnpike.com> from Paul Overell at "Mar 24, 0 10:19:06 am"
To: paulo@turnpike.com (Paul Overell)
Date: Sat, 25 Mar 2000 23:16:04 +0300 (MSK)
Cc: ietf-pop3ext@imc.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

> >
> >    In which case I'd rather go ahead with the following sequence.
> >    DELE 20000304062907.AAA.e0081efb
> >    DELE 20000304062908.AAA.e0081efb
> >    DELE ...........
> >    ..................
> >    QUIT
> 
> This syntax is ambiguous, UIDs can be simple numbers and so confused
> with message-numbers.

Multiple instances of the same message can also have the same UID,
so with an approach like this it would be ambiguous which instance
gets deleted.

Signed,
Solar Designer

From owner-ietf-pop3ext  Mon Mar 27 07:55:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA08866
	for ietf-pop3ext-bks; Mon, 27 Mar 2000 07:55:18 -0800 (PST)
Received: from tomcat.aditi.soft.net ([164.164.12.25])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08860
	for <ietf-pop3ext@imc.org>; Mon, 27 Mar 2000 07:55:15 -0800 (PST)
Received: by TOMCAT with Internet Mail Service (5.5.2650.21)
	id <H4GDSMVV>; Mon, 27 Mar 2000 21:32:22 +0530
Message-ID: <608E92548499D311A894000629383804F68515@TOMCAT>
From: Faheem Ahmed  Khan <faheemak@aditi.com>
To: jgmyers@netscape.com
Cc: ietf-pop3ext@imc.org
Subject: RE: A suggestion for RFC1939
Date: Mon, 27 Mar 2000 21:32:21 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

I agree that the UIDL to the message number mapping doesn't change during
one session, but it can change between consecutive sessions.

For example:
there are 100 mails in the mailbox.
I have retreived 95 and my connection to the mail server is terminated
abruptly. Though I have issued DELE after every RETR my messages still lie
in the mail box, and in my next connection to the mail server I have to
match the UIDL of the message already read by me with every message in the
mailbox before retreiving new ones. BUT, if I could use UIDL with the DELE
command I wouldn't have had bothered about that and issued a batch delete
for all the messages already retreived and still be sure that I have not
deleted an unread message. Wouldn't that save me from comparing the
MessageID of every message on the server with the ones already read?

-Faheem.

-----Original Message-----
From: jgmyers@netscape.com [mailto:jgmyers@netscape.com]
Sent: 27 March 2000 09:09
To: Faheem Ahmed Khan
Subject: Re: A suggestion for RFC1939




> Faheem Ahmed Khan wrote:
> I don't understand why RFC1939 restricts to using message number with
> the DELE command. Using the messageID (UIDL) with the DELE command
> would be a lot more useful where the user agent can be sure of which
> message it is deleting.

I don't see how it could be more useful, since the client needs to know
the message numbers for the other commands, such as RETR.  The UIDL to
message number mapping never changes during a session, so I don't see
how the client could be "more sure."

At the time UIDL was created, we were trying hard to limit the number
and scope of changes to the protocol.  The fewer changes, the fewer
things for implementations to get wrong.

From owner-ietf-pop3ext  Mon Mar 27 09:09:23 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11141
	for ietf-pop3ext-bks; Mon, 27 Mar 2000 09:09:23 -0800 (PST)
Received: from jittlov.qualcomm.com (jittlov.qualcomm.com [129.46.50.79])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11136
	for <ietf-pop3ext@imc.org>; Mon, 27 Mar 2000 09:09:22 -0800 (PST)
Received: from llundblade-laptop.qualcomm.com (llundblade-laptop.qualcomm.com [129.46.242.17]) by jittlov.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id JAA08762; Mon, 27 Mar 2000 09:11:30 -0800 (PST)
Message-Id: <4.3.1.2.20000327090349.00afadb0@hotsun.qualcomm.com>
X-Sender: lgl@hotsun.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Mon, 27 Mar 2000 09:11:15 -0800
To: Faheem Ahmed  Khan <faheemak@aditi.com>, jgmyers@netscape.com
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: RE: A suggestion for RFC1939
Cc: ietf-pop3ext@imc.org
In-Reply-To: <608E92548499D311A894000629383804F68515@TOMCAT>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

At 09:32 PM 3/27/00 +0530, Faheem Ahmed  Khan wrote:
>I agree that the UIDL to the message number mapping doesn't change during
>one session, but it can change between consecutive sessions.
>
>For example:
>there are 100 mails in the mailbox.
>I have retreived 95 and my connection to the mail server is terminated
>abruptly. Though I have issued DELE after every RETR my messages still lie
>in the mail box, and in my next connection to the mail server I have to
>match the UIDL of the message already read by me with every message in the
>mailbox before retreiving new ones.

Yes, you do have to do this as things stand now.


>BUT, if I could use UIDL with the DELE
>command I wouldn't have had bothered about that and issued a batch delete
>for all the messages already retreived and still be sure that I have not
>deleted an unread message. Wouldn't that save me from comparing the
>MessageID of every message on the server with the ones already read?

It would save you comparing. BUT, your mail client would only be able to 
talk to new servers with this new feature. It will take five years or more 
before all the servers are upgraded to allows UIDL with DELE. This is not 
an exaggeration! People just don't upgrade software that fast. In the mean 
time your client software would be sort of useless.

There's actually many things like this in Internet protocols that could be 
redone much better now with hindsight (RFC-822 address syntax for example, 
or the chattiness of SMTP), but backwards compatibility stops us from 
changing things. The deployed base is huge. In your case of POP and UIDL 
the inconvenience to programmers like you and I is relatively small. All 
you have to do is build a UIDL to message number mapping table when you 
start your POP session. In other cases the messes are much bigger. 
Basically I don't think you're going to get very far pressing this.

LL




>-Faheem.
>
>-----Original Message-----
>From: jgmyers@netscape.com [mailto:jgmyers@netscape.com]
>Sent: 27 March 2000 09:09
>To: Faheem Ahmed Khan
>Subject: Re: A suggestion for RFC1939
>
>
>
>
> > Faheem Ahmed Khan wrote:
> > I don't understand why RFC1939 restricts to using message number with
> > the DELE command. Using the messageID (UIDL) with the DELE command
> > would be a lot more useful where the user agent can be sure of which
> > message it is deleting.
>
>I don't see how it could be more useful, since the client needs to know
>the message numbers for the other commands, such as RETR.  The UIDL to
>message number mapping never changes during a session, so I don't see
>how the client could be "more sure."
>
>At the time UIDL was created, we were trying hard to limit the number
>and scope of changes to the protocol.  The fewer changes, the fewer
>things for implementations to get wrong.


From owner-ietf-pop3ext  Fri May 12 21:54:23 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA03773
	for ietf-pop3ext-bks; Fri, 12 May 2000 21:54:23 -0700 (PDT)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA03764;
	Fri, 12 May 2000 21:54:22 -0700 (PDT)
Received: from [192.168.1.5] (vpnap-g1-012068.qualcomm.com [10.13.12.68]) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id WAA25478; Fri, 12 May 2000 22:00:32 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p04320302b5428f5bf797@[192.168.1.5]>
In-Reply-To: <4.3.2.20000314113237.00aa9d50@mail.imc.org>
References: <4.3.2.20000314113237.00aa9d50@mail.imc.org>
X-Mailer: QUALCOMM Eudora v4.3 for Macintosh
Date: Fri, 12 May 2000 21:58:38 -0700
To: Paul Hoffman / IMC <phoffman@imc.org>, ietf-pop3ext@imc.org
From: Randall Gellens <randy@Qualcomm.Com>
Subject: Re: Announcement of MailConnect 6
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

At 11:32 AM -0800 3/14/00, Paul Hoffman / IMC wrote:

>  A new round of extensions to POP have come out in the past year, 
> and client vendors have expressed strong interest in testing these.

I'll be bringing a server that supports CAPA, and I'll have another 
(Qpopper) available which supports CAPA (RFC 2449), the IN-USE 
response (RFC 2449), and the AUTH and SYS responses 
(draft-gellens-pop-err-00.txt).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The whole dream of democracy is to raise the proletarian to the level
of stupidity attained by the bourgeois.            --Gustave Flaubert

From owner-ietf-pop3ext  Wed Aug 30 01:17:24 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA03432
	for ietf-pop3ext-bks; Wed, 30 Aug 2000 01:17:24 -0700 (PDT)
Received: from sendflowersamerica.com ([206.168.43.194])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618;
	Wed, 30 Aug 2000 01:00:01 -0700 (PDT)
From: sfaquestions@sendflowersamerica.com
Subject: FlowerFunds - Fund Raising Program
Date: Wed, 30 Aug 2000 01:32:17
Message-Id: <620.108063.29555@sendflowersamerica.com>
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

SendFlowersAmerica is proud to introduce FlowerFunds--

This unique new concept will provide an income flow for your 
organization for years to come.  Your organization is invited to 
explore the possibilities of participating in FlowerFunds. 
       

     $FlowerFunds is an individualized fund raising program for 
non-profit organizations and schools.

     $FlowerFunds are cash rebates that are paid to your 
organization each and every time an order is placed by your 
members and supporters.

     $The best part is that it costs your organization nothing to 
participate!!



How it works:

     1.   When your members and supporters order flowers or gifts 
through sendflowersamerica they determine the price they want to 
pay; be it $30, $40, $50 or $1000.  Since your members and 
supporters determine the price, they all can participate in this 
program.

     2.   Your organization receives 20% of the purchase price of 
the order.  Say a husband buys his wife a $50 bouquet.  Your 
organization will receive a $10 cash rebate. Nice.



This program never ends.  Each and every time there is an order 
placed by your memebers and supporters, your organization will 
receive the 20% cash rebate.  That's a lot of FlowerFunds, and 
your organization stands to benefit from a findraiser unlike any 
other fundraiser.


For more information call 1 800 SEND 123 or

http://www.sendflowersamerica.com


Imagine earning money for your organization by making someone 
smile  :-)
 
 
 
 
 

From owner-ietf-pop3ext  Sun Feb 11 20:35:06 2001
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id UAA06074
	for ietf-pop3ext-bks; Sun, 11 Feb 2001 20:35:06 -0800 (PST)
Received: from RNR-DB. ([211.106.66.239])
	by above.proper.com (8.9.3/8.9.3) with SMTP id UAA06055;
	Sun, 11 Feb 2001 20:33:44 -0800 (PST)
From: toner3@yep.com
Received: from 211.106.66.239 by RNR-DB. (SMI-8.6/SMI-SVR4)
	id NAA28132; Mon, 12 Feb 2001 13:16:32 +0900
Message-Id: <200102120416.NAA28132@RNR-DB.>
To: friend@republic.com
Date: Sun, 11 Feb 01 03:43:18 EST
Subject: toner supplies
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES


**** VORTEX  SUPPLIES ****

-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--

LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES

WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY
LOW PRICES

ORDER BY PHONE:1-888-288-9043
ORDER BY FAX: 1-888-977-1577
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.

PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).


IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
NO SHIPPING CHARGES FOR ORDERS $49 OR OVER
ADD $4.75 FOR ORDERS UNDER $49.
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 

OUR NEW, LASER PRINTER TONER CARTRIDGE, PRICiES ARE  AS FOLLOWS: 

(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)
                                 
HEWLETT PACKARD: (ON PAGE 2)
                                   
ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 5000 (29A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A0------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54

LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105
OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165
-
EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105

CANON PRINTERS (ON PAGE 5)

 PLEASE CALL FOR MODELS AND UPDATED PRICES
 FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79



CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54


CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.


From owner-ietf-pop3ext  Thu Mar 29 01:32:49 2001
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id BAA02410
	for ietf-pop3ext-bks; Thu, 29 Mar 2001 01:32:49 -0800 (PST)
Received: from fep40-svc.tin.it (mta40-acc.tin.it [212.216.176.93])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id BAA01092;
	Thu, 29 Mar 2001 01:26:44 -0800 (PST)
From: toner12@asianwired.net
Received: from [212.171.30.247] by fep19-svc.tin.it
          (InterMail vM.4.01.03.13 201-229-121-113) with SMTP
          id <20010329092548.VBWC8227.fep19-svc.tin.it@[212.171.30.247]>;
          Thu, 29 Mar 2001 11:25:48 +0200
To: handyandy@republic.com
Date: Wed, 28 Mar 01 02:33:16 EST
Subject: toner supplies
Reply-To: handyandy@republic.com
Message-Id: <20010329092548.VBWC8227.fep19-svc.tin.it@[212.171.30.247]>
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

PLEASE FORWARD TO THE PERSON
RESPONSIBLE FOR PURCHASING
YOUR LASER PRINTER SUPPLIES


**** VORTEX  SUPPLIES ****

-SPECIALS OF THE DAY ON LASER TONER SUPPLIES AT DISCOUNT PRICES--

 
LASER PRINTER TONER CARTRIDGES
COPIER AND FAX CARTRIDGES

WE ARE -->THE<-- PLACE TO BUY YOUR TONER CARTRIDGES BECAUSE YOU
SAVE UP TO 30% FROM OFFICE DEPOT'S, QUILL'S OR OFFICE MAX'S EVERY DAY
LOW PRICES

ORDER BY PHONE:1-888-288-9043
ORDER BY FAX: 1-888-977-1577
CUSTOMER SERVICE: 1-888-248-2015
E-MAIL REMOVAL LINE: 1-888-248-4930 

UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)
ALL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL.

PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS).


IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. 
IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER
C.O.D. ORDERS ADD $4.5 TO SHIPPING CHARGES.

FOR THOSE OF YOU WHO REQUIRE MORE INFORMATION ABOUT OUR COMPANY
INCUDING FEDERAL TAX ID NUMBER, CLOSEST SHIPPING OR CORPORATE ADDRESS IN THE
CONTINENTAL U.S.  OR  FOR CATALOG  REQUESTS PLEASE CALL OUR CUSTOMER
SERVICE LINE  1-888-248-2015 
 

OUR NEW , LASER PRINTER TONER CARTRIDGE, PRICES ARE  AS FOLLOWS: 

(PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER)
                                 
HEWLETT PACKARD: (ON PAGE 2)
                                   
ITEM #1  LASERJET SERIES  4L,4P (74A)------------------------$44
ITEM #2  LASERJET SERIES  1100 (92A)-------------------------$44
ITEM #3  LASERJET SERIES  2 (95A)-------------------------------$39
ITEM #4  LASERJET SERIES  2P (75A)-----------------------------$54 
ITEM #5  LASERJET SERIES  5P,6P,5MP, 6MP (3903A)--$44
ITEM #6  LASERJET SERIES  5SI, 5000 (29A)------------------$95
ITEM #7  LASERJET SERIES  2100 (96A)-------------------------$74
ITEM #8  LASERJET SERIES  8100 (82X)-----------------------$145
ITEM #9  LASERJET SERIES  5L/6L (3906A0------------------$35
ITEM #10 LASERJET SERIES  4V-------------------------------------$95
ITEM #11 LASERJET SERIES 4000 (27X)-------------------------$72
ITEM #12 LASERJET SERIES 3SI/4SI (91A)--------------------$54
ITEM #13 LASERJET SERIES 4, 4M, 5,5M-----------------------$49

HEWLETT PACKARD FAX (ON PAGE 2)

ITEM #14 LASERFAX 500, 700 (FX1)----------$49
ITEM #15  LASERFAX 5000,7000 (FX2)------$54
ITEM #16  LASERFAX (FX3)------------------------$59
ITEM #17  LASERFAX (FX4)------------------------$54

LEXMARK/IBM (ON PAGE 3)

OPTRA 4019, 4029 HIGH YIELD---------------$89
OPTRA R, 4039, 4049 HIGH YIELD---------$105
OPTRA E----------------------------------------------------$59
OPTRA N--------------------------------------------------$115
OPTRA S--------------------------------------------------$165
-
EPSON (ON PAGE 4)

ACTION LASER 7000,7500,8000,9000-------$105
ACTION LASER 1000,1500-------------------------$105

CANON PRINTERS (ON PAGE 5)

 PLEASE CALL FOR MODELS AND UPDATED PRICES
 FOR CANON PRINTER CARTRIDGES

PANASONIC (0N PAGE 7)

NEC SERIES 2 MODELS 90 AND 95----------$105

APPLE (0N PAGE 8)

LASER WRITER PRO 600 or 16/600------------$49 
LASER WRITER SELECT 300,320,360---------$74
LASER WRITER 300 AND 320----------------------$54
LASER WRITER NT, 2NT------------------------------$54
LASER WRITER 12/640--------------------------------$79



CANON FAX (ON PAGE 9)

LASERCLASS 4000 (FX3)---------------------------$59
LASERCLASS 5000,6000,7000 (FX2)---------$54
LASERFAX 5000,7000 (FX2)----------------------$54
LASERFAX 8500,9000 (FX4)----------------------$54


CANON COPIERS (PAGE 10)

PC 3, 6RE, 7 AND 11 (A30)---------------------$69
PC 300,320,700,720 and 760 (E-40)--------$89

IF YOUR CARTRIDGE IS NOT LISTED CALL CUSTOMER SERVICE AT 1-888-248-2015 

90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS.

ALL TRADEMARKS AND BRAND NAMES LISTED ABOVE ARE PROPERTY OF THE 
RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY.


From owner-ietf-pop3ext  Sat Apr 14 11:39:45 2001
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id LAA25740
	for ietf-pop3ext-bks; Sat, 14 Apr 2001 11:39:45 -0700 (PDT)
Received: from Prodabel (bhz65.pbh.gov.br [200.17.182.65])
	by above.proper.com (8.9.3/8.9.3) with SMTP id LAA25726
	for <ietf-pop3ext@imc.org>; Sat, 14 Apr 2001 11:39:33 -0700 (PDT)
Date: Sat, 14 Apr 2001 11:39:33 -0700 (PDT)
Message-Id: <200104141839.LAA25726@above.proper.com>
From: Hahaha <hahaha@sexyfun.net>
Subject: Branca de Neve pornô!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEHM3OTYBKT"
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

----VEHM3OTYBKT
Content-Type: text/plain; charset="us-ascii"

Faltava apenas um dia para o seu aniversario de 18 anos. Branca de Neve estava
muito feliz e ansiosa, porque os 7 anões prometeram uma *grande* surpresa.
As cinco horas, os anõezinhos voltaram do trabalho. Mas algo nao estava
bem... Os sete anõezinhos tinham um estranho brilho no olhar...


----VEHM3OTYBKT
Content-Type: application/octet-stream; name="dunga.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="dunga.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr
FqhUAABKQUpMT0RJTQAOBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa
HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj
SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV
ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA
D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP
hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA
AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/
lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA
AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC
AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW
V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT
/5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F
fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm
90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg
99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk
XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z
9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E
i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe
AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS
AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy
ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0
JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW
/7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs
AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA
AAAAAABo+AdRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC
AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquEREQkSruEFGTEuruNG6p7r3
0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/
lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA
i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe
VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk
OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB
AACB7f73//9VaAEAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAgAAgP/WhcBa
dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA
dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/
NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze
mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD
QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL
w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G
i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR
g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix
UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X
JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty
PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx
IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi
TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI
bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A
FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D
TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz
wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq
AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn
////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC
DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS
uBznbwe5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q
i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j
EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH
EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH
XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX
GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX
ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH
CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK
NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC
WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP
fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK
GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf
RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC
YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL
R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA
D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg
i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA
i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd
AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v//
D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg
/v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB
D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO
HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f//
d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP
grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL
RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ
T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ
R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw
9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt
Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy
IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jWkjpda+J6XVpc+l1S4zpddKf6XW0
oel1oJLpdaCW6XWER+l184zpdSNn6XUpZ+l1g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg
6Ar2//+L/YHvAKAAAIvfgcf9EgAAufgBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz
Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB
dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+40cIfA4fOKAfB
yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H
GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA
AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP//
/2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0
V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+
///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA
AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc
DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH
g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq
IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB
7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL
lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/
laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA
/zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr
+ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII
EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB
VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v//
6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P
D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN
hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w
//+H9YHGJh8AAGi8AAAAgwb8/zboqgkAAGi4AAAAaACgTYLomwkAAOjD8P//aAAA6XX/lXciAABo
mAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o
8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo
QfD///+VhyIAAAP4sSC6oYjwANPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA
akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY
RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy
BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog
MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA
AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy
c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo
IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp
c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi
qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/
/2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA
UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V
uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/
/4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ
6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+
AJBNgoHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW
iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/
NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg
g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC
DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL
fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz
IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE
99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF
EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk
Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD
wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51
9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0
GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgEkLqCagTo
9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM
AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAuYxKQwCNBMGJRCQciwjjJr8AAAEAV2pA
i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw
QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/
D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX
jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ
iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA
M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8NfNZAOsM6BLo///GhUIhAAD4ZGeP
BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB
xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA
AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav//
lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk
KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28
PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+
ifB8zFHTe1dmQlbdRk+jsS3TEzoYzve/AKDjdQ4P+r8we/e/sW/3vztx97/N4Pi/0Hb3v9Fv97/h
Evq/Qnn3v5p297+pIPi/ST34vzhq97+obfe/Fnf3vzlw979t4Pe/23r3v2Zv9789bve/tEj3vwgt
+b/1Gfq//PT4v68P+b9HY/m/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF
AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk
lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90
JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc
YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr
WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA
AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3
8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA
U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe
DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc
/5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo
AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA
agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o
nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA
AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA
XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v//
iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq
/2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy
wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0
OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB
qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd
w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq
BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/
lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90
AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk
K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK
kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP
t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I
dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh
w/////+xnB/x7FBeWZecADqOHa4/Kiv0sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vguc
fuCtLIXAFsfKrNx9cg9qEWxL990BZsKwe4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXa
lTQWveC9Yf7xmwv0O8iA4RilwPGLtL1FE4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrC
rBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJfcHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x
3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfWf6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5
kM6OiRr20ryeIxVe5j/wsFY3+ilJtTquyKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEy
MSswKLlzyAKAJ513m0vB+/YE91TmNaySVwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQ
vaMQtyjHx/FvfopyS8DlSEV4t2CUFn2pXRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffB
kVaTitcokrIc2ofMd2Wvn7TyJbL+pnWfED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQg
EWE3+/RVRfICgWLDezP0Wa268cjUae/TmE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hla
sw2yeZ88dsFXFlBjo12Hr6sXphJFUduoFlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQ
rUihEObcsT2CP/i7CzPz9q4XH64YUlmsNasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOo
TcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+Y
CbuRdflvsJZql5cjW/coBQC9AZlRUPxc/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxy
XF6H1gmbs1LmrTLZmLcF96nMDf47NUZzZXJ2AgAAADADAADGNNGjEyg1mrZvZ2ZVkYh95GVTepQb
9oL6+n6yEO+l5t7U1gzLQZZN5ja+FR4KcwFAF59y+3G3pmNkoQOgJ1w9ivRlnpVgUxWux9yF04HJ
mQhtk8mmZQIWg+Tv84UA3J9CLASaDZCayYxdA5A9aeB7acw4rHY+9gyFAEE0fQ0fQ5FNMrOTq9Lv
niQL1Kdn9vUwCKu8YxJ9Auk9jA5Kn2NT6HawUDq06k5On9LD/KdiFd9vipiG6+9rEHcML+Wgb7gI
laSTLU/sBMwZrvTmEWVOqsxbX4fL7KYiMvBAxMcz7dW9A1Q3ixwGfkYnZDrhSR3EkWh9/zeTh0aH
PsU3fHZcGuGAJE0ivd+I299Q3ol7MiaNNmwabhLWgWt7HS8+DcTVG7WR8MfANO2WZA9oL4k1MzRW
EahSMmtX7j7sY9htGlwMa4PnniTzImimP/82b2SmOEsJZdXKi+vh5IHFaafIlkBsgvpOJ+pE2Pe+
D4LrfRGBZa6UKqrsqSNQII9TebUsO4V7q/uqIcF85Q9HCjL2h6qHVpmk6ZmW+aDhiy4A7xHUJPal
xbTpaOlSE/CUyXmpSPeH3thaAPLN7K7SMJKrWj0G0RobVBgGOn9lMTXfsm2a1jJzV7WQUCa+NqNB
6FvKUe9HEZMf2Iil3AHnf/ElG9xivmO9ZnFl5QHcQufClLPOyO8bP5S8brtr7+WJrw7AIyH/YpNM
Gyoi/K7r9J6qMNn4DrVRX7yCCWmljzt64mfWpCBO6NLrZG8M1UDFXVHXxZVVZVkP7RTkNegwXu7e
SgzU4lgMYNhDa/B1XqmgewbPEujflxMur+OxamaHsd6no9xCu7AN/8gJTVpiEDedNeH7uP6ynA1v
Pv8qs2ImO6IPU++GPHdkpKX2Rl09jqvpAkMtUGxzvumNh2DF34Y+WGwjkPBB0ZrUujgJ0ASgpN/5
67XQMPbBp+k2LcHtg7riYWLvs1SOxAKjXxvI2hmrQ3ugz/r9RfboBqb+udMl4KBUjhm77y9QGAfR
U7IWQZsdga8UAVGcopzfw9GtUP5JoUSZ+qaouSQgKbHHQm+00xAV6KHB6TYcKfkpoMf5kduAzWub
WbSVM3FB3sQMxA1YPyzePn4bucVdsqBZhaxyTYIw8puBnTHTjb9jtV9YyGBS3JoBLx1jXAm1MBek
yjd/JuzL9hTwopCegCJNs/bsAXoL4OVM5vq16TK9SXv7Xh9Jx6Cha4OyVdiTP1AM91XWoPrhkuUQ
LbUb17LcVve4JlTxT7PMV1Qto4UtlpsWUVL3Rswin56oqtNIZhOx3iGgbkYl2VRrUWo4McSwfER9
YyH0kq4DIsSJ03s83Pp9MkdsVQSGodnNedw5TcRn4pRv1QkkXQI/hyHJRKlrn0RfZ83KJappO0x3
cTPe5w0KFRGX6uEMglTw8kXBuZwdvBeprmYYKZ0Y/DiHcabPMcxfge1JekwgLNJymun0RQ/ZzzLt
92NMYcEfUT7phc8z11VveZPHcLbfq8Csfkpv1tDwgLxSs/SZOEGghKcaupUDvDAIa6HvmmzzcqQQ
dcj5PGESY3uSMYw36kVGVBVPAbgb07E/vUpRoCtm8qIxekfI8+XcNJjOuUZ6B4iSqKljFxKHgGJj
08xNEX9L5yf3RR+abS5bkPtsNpnEZNc54oFGMiuAjWPARJUirl5vApkqx+oPbvhqX/n+8M09RE0/
Ye79/IC6U4TBfBOZGdva28TA2XVc+95bcA522xDxjwbMtsHh1Xp51YsQXNtVJwY0AuUsGyNbfSyD
WOMjVZ6xriBEqwiNnpSq0qRumFAcr3CSfwwqbHtUb04GU67+qgHeDCglG7+Py/gArl+NLdRjaLF0
i58foJxsB0AskViPXQRJexmT1wvDqrx/Ql0coZ4egUt66hbntuUsypupQomV6xvsHPsA+mHvPFYR
Mk4zYXcsWWgOSNWIVFnopxeXwli8GChriYpR31cDNehCyvsWdRL5fjwRkExRrmilIEhn44a1kVng
wYCTCfvLmOnVIb4QwZRUaCYY4YNiDOfLE7nNJeBiMKQopkVXECGnnoEKB2/ez6sf7yvBNP8y16qD
DxaztFUwd224wNdM+B8/ttrygO1shkjeorsxupJzFDBN7CX18qF15Hysldnh2UrGNMxOdr3MuxA/
g2QBt6elRk3+creBu59LSAjdfMMOs2xpkdiPo86OzN4jmJgo7F6znZKHQ3WVbiI+wM9Kso8HI3oS
vweAVsW1i9EfNuUv+PRpSXttO6cqVkLKwx5qc4Xli/iiQTAPHxBwZt3bOE9yJNbGSbEX8WP1ffts
jKSm4OudCOXuyWbnFf/1k66mbva0AAzsZe/Yrvl4mhh71ZOq9RF9cC5P0pBTPBvzgUaz/O8wzc24
AFN5HbE5FrHATNaLqBj4V6MmJv4C0wxfkFkkQkjdC2FBx0OICDtpT0TKHzRvH/MaOJpUZ12O44EA
OaRmBHZx3eba1HlY86r2z0qNIbPo+qnjzoq+pXQk1ozO9qm+CXqDJrPt6BJMYBFelh4uNkQg4RBY
An9AX4dtdCBZ/BslS5RWS+ybbBUfmr4IAUOsxeFxbd5kk8KZe+BvFpIygeusZppbiDD1bg7y+e4T
U5YMPb/5E/H2dmuJnbsaxqToQFZC4StpIGTLnl0pFVZVwQvkywnNFs/5Of5pGGpX04oyFbEKfPgT
/sxMxEIhQ3Twpw55d0UZURrBqKCWC+PqSt4aOMzNP0ZSAhcK95TcO0VJY4axgxzTnUE7+lAeip1S
/ITae8UzxXtXO8c09yrY2nElSEtoqxD77j1PJvMV8PBZXCejw0mdc6/ot/zdCR7dss9K8e23f60Y
zd9DyDjltDNzSn3q83ItCMBRkr/Av33NtmkhxvElI4aov3WN53HjSC2kXrAzCc5G07VB6VLfgXC7
+2tkEv4C0wxfkFkkgg8Fr4ae9jpaja/XyZML4+7PlryQ3Gt671Yp3y55x2PziChkbNNsdLBjaLkg
iQm1rUykfo/kOWIzI6xA5okFeAYAWR82gilDm4vfyG/c07LGeMHEJlPy8M2RTFpe7R1eEJU6dJ/k
5nsEFJqoj0d6llU95gTzH+JRd8gsp62uTC88DtT0Y7Hds+P1hQB9ZQ3xWZ6fYOuAySSgPGr55Zg+
wMp2jXM2jdZOis+Bre6QaJ//x0QuYjxhZfWbmv2t7G5wZRH06OJoNiU8e5cQ/HP2CMJiIJBXC+yM
GLDT7uNPOIekqJGkLAz7XjKU54yGXZh4Rf40N2C9ZYXvmhl0EZpDF2FmADwrOc2J/1E/NasMrjKZ
oLlxlxr9Z5tt5pn51qCVGXLkyZRi+NuNV62cbvT05Ld/8rRs0JbeexdAsmSqwY7Dw2IzZjVyeK6+
DKEABXDkePW/8ZZZrekVYJEHGfO/ZZ5SIGWYdM/uCRVSUPmcV8pTpeETW7LAQCJuviQg8STfMoeU
YK47yaR88XPw53oh8NxMHwMXqiv/cWgYMMRJrz9FTAKHUxJarSIMr2IpWSS3ruVrqduIunvM2xgb
y/upiRfu6OCdctXV4RHzuojOOmOB2IIuTqUK5ThDQvejCNupDsHiyyzwqzPioaBWSP4pofavxzTP
W3iFVPrUwE+bUQfblBpP6Nb+OmlfcnoBAQAAoAoAADnQVSmTyKTeTu8+mp03C636d4vNRdxPiVfq
k7h4rEreo7uCoqJCQVYVdsGqs+d+ObiNkmcOAixnbQd2TcHB/KGhMG1JNNF2EjEeyxN9jiOKyrD1
7vzvqG2ANaMQfXu9qEjMXiU+TtVmILwy6CpSYYSNlhf/rhl9g/A9SMXfqvaONlQMeUsbDHgjNUER
pJYk+kIR0YEUYk/261IzyPdJmaZsUqu3ZBG0uyKYoH79HTMfFCmXZunABK7m/9RXRlk3Tls5KBrL
R+ITNPwtJNc6lxwphKdpP+22foFHHKWDeofJKziXhTMdo/EPrGMkKLayCNqJjCr4pzUPkNuZGz9k
dWzHgjkCGbsMEgzlAUCyMDwT8rPfCg0CyWe+TfPg2DJUWj/9X7mzNqdLZbn2xAlYQW9lJA8FMyuo
d1l4DhXcbTCmw+4Y/mtvqxY86EPqWzCwPzCs5C9ymkiDTR1vyKP6+UfVcsey2ChtbXjSuXuLS2qM
Er5f2VL9TviVWN6nlvvLH7/Ahlfm0KM/z42m7rqcoIjmsqAgU6DLAENreysOJ4g8tsHeWT1YIk8W
0OZSSnNJDle6CO7/MPv0yzk6dZR6SrWmC+6yw4oyxVdOR4P0PTwdMfd8QEqkS7ZrEdjExE1P8njI
GsGM8JvYIcXwFxKztKVbx6cB7W/u1qoU9uzJ3j6Vr4SDzsHUMeJuyRkN65QyKOGs9m5NLdQMo9za
ZjXkive+OgYbPKmlgdgXnAGnQy8cTYrAZ020JEI6/F0bI0e8EhrPAH2FY6Xq63R/VpVAqKt9l0JB
9R11h6/IbnDbUEU9dV90y6w1pagUvHTLgbVh0kS4j+dd2v8UCM+f7S6e6rqDzVs0kGOxiIvEpA27
OaVF89LY6PbDqQEKDt/lgLLs3EfRU+T6HgfddDHysRihKv3oQy3l6C+z/B1I+IKX38K9rRPqaVvo
54Lg5Y5oMGK9dZ4as5T2WmVpj4DzTA8DZoGeL/3AYcDIeDqtwTrQ4t5wQMb4wY2fvAuXwhX3fkDM
6RZVXVnZUN4cSq9ctuRGcnoIP0pDYxyBjTDX0R2BkCPSLuovKG5P6fprhpOfnEGzTfOdeuropgXV
qo9mGeklsCxd7BobPYBb0Dp1r2DZrtdWt51LK0UZkb9nRjPP37wRilJuUqhU+IvELrozr95xE5Go
d7rauIJ2zfTILFEH/hEObweEI9VsMR5ovlKTZx6TcS69HYBGm9k13YC/S/xcrTPUr0huIGBgsGzO
7Ic2QoaFCfftXqe3jo0ICSq2GMbCAePvajQpMRLfg3XHBeRmQRSY+bGkEYbM6zCgV45WRrVdN8vb
q7vKiyG3keQ3RdOC37reCIXr1EF6AAZFcVpWtzlaUdkgjLRhgmivPCup1JXIsb9lGdXtOIWEiuaz
MXeZ3UPnkI449pAg4D1kJ6R17Q/ZDA7QjKgg41WUxuE+UcfV4lR0ywrDwcsl7GOKI4wPrEnxxyoo
FHqf+6v6e341ADn+lVzC7AKaYQeSRIr9J4yzK7vWdybWjiIh3p7Vb9cIg3PB8aaCsqQDIZbC13C/
qz6JDzA2qtvmBtNxteLTikRN4UtaX8n4tG2tyFfKUx2btH8X77BvHaa1o/SiGeG4WgCjelBe/a8/
sA5WZoY1f27AJYAS0eMUxCLYfMKkh/8kSCnAjHfKV/2hZIrURtEks4EM9Qmk9mbfX6WqIbeillo2
sJS7Po0euW5gkN88avhy1xdwBXU3k7QGBXi/6JVSuYJkn3NFipMNNRaCG1VbkB3w71IhoPKcX1XV
7z5xs0G7mNLWTXG0M9ud9ch1TxhqVDV5oZVzzIxF6dQTHoA/+CkYgFWx6r2xVb7u6ouMu2+qqoCi
zoMYag9nbx5MvkdFH9B9oBMLHgcDCtvquXvlU9Jo9i64OVAeXCCKz+qr6wWtKaAloMMWHTamhDsk
hnLONlzTkSKWB8veVRNV2Ls1HBGkO6HO88LNAb7bM4UcQ+pun3iblqJhuDyAUCmQceM068fecNfB
Ue2rMNXCVlqBWUzqLOU0E8UyDr4MN94a+OfHBBCfCB9QxH83snaERR6XCEzmRtaXVeg7XkvnM1G9
xA8lfERT2rA2pxyvO6t6aAyhrjx+Om8W1ZZO63B2P+GfOG3SxXelFHUPc8v4OJFaUW/oDKQTZ2ap
li8LGbUHMPWbKiXwt/Ot9uxsjkuexI+WlYKdolvzjkW03WODIFJPkluY/J/Fkm205baWwtZ8q+98
Jbndba8MSfjGlWaVXIs75f5XKuMjItcLc+tv2Caxo+Jp7I7wKv54lTHhp0YXEK2D/4VxfndC5/wG
cOJ71cxHDnJkRZZpUwT32ykucbjjWcqa3v8Hk1sSX7tHasgxQJpDJbMClvXItmIBRnsKroKkIFAq
5LTSdln+7rUpRNq488uQ1x6s0IQAtU5EzUOcHr9oMAXv/meh40J69F//Z9aC5nIDnRDDawH2MbOG
JNcNsbLeZNjJjY+jv0j+gMUvFqo5fSkmodO99NSWQ4FbOs8GjbzMdEJ5/q5u2PSljaDxJt4S59EK
Ei6W5ZaVzIJ6eEn18zjL+Ysq1liGVmmtpMLs5u7GBZROR6yoG6I7zRfLRko8OlLFDsaB8TKmKE3h
aH/XVgOE9/tgQQpRDtZROWBktqwfG6A6U1v19rNTV4IIjQkVlkB6wFk6E5Ie+UGWRPSLqbbvwb51
NZwT9paEL0JDVrICiouf4tN6v6mRgYEe5ZV7kTgW0c2DPW869Vyq1Dy9ZIib+dQlWWKSIuYoNgNA
SgrtMZ1UrIlP723bKjwaRysHDyo2xbHQy9istm7RFgKO7FiT/ZaehcnwkEg6u4p6LOzVF7UpKFVv
KM6a7+TezS6QYKYeqifKQ3g0Xe0TEftuRnRleHQCAAAAcAgAAIR5ooYjZ6LZf9/7w3yvusKHgbm8
SXi2AJwWrypH6oCRXcmg+F1tKSnGsGKvGSskcYsUUHfKbd4cnNJrPs51on6hpglIa1gThjGMANri
eog3gwcWfr5V7UFsxFWwb1LhB5Cz8Jf+GoOX0IzsVY5xEh6jojpCXLmTs6KcJHxdTPjqCh0g8kXK
fQkIhjDFshqrNNga2w6HzpROxN7H1J02he4WON3w3ASOiS1GDjijrEwfiEZgBh2ErUlFXHn0DtV7
zteiw8dgBGoErm0Kz7DTdv7HheX7MVOxo/lVtziOomDGNqe5Ou0HXyiqTkWUFFntvEJWkn7R2XQs
3ft6I7uSGSvl13/B+1y67omuZaWX/m54B6KNj1xsPHDbZTiXkHOtz6SA4wEVvjqtXJAdQsY1UYpq
Zf/Yp1czzAdrrhyeY+S88Yxh38M4LZG13cZPO/I/GCnqg9zE162RQihpFqYKC08bzRJ6NJ8ZTTNU
z9YBBxA3SZsXla+G2EHbDm7vAumjo1wfZgm4JRybC3UYtcOFJhxhdmlwAQAAAJABAABC6Q2D9vWf
pWxZYayHaWKj9V/NTb3VEf0IuWUmB4L3fOdR4beD/cjwc5o5vTSEc4O5MP5bafGZ+aIv+gExVGqQ
X343c/0RWthYfhBuWPadIStZrDCUR22Ubq2ZuIIUbxRTi14YHT/a+5kX6DqWr5XpPf6qbRZUf5yg
96uZmIH771AtsWn23SfzUhS8Bykd3F7sk9HDAAr/bvr4jENoPAyobWq9VKugXoA4YSzSwpNPr39P
HwQidhwtmkwCYWE8Lc09JNYJPAEBxP/cQWTSYNWr0Yj+B0Fr2KV43fd4kK8leeNf+YSFF+xW79F4
VmTq/AhBpF1ncWgpLrJOO7xeo9WtW9QKFBze/qYET83+0RBbrTvHR/T6xBbHsygq8y+I+VAaoX+Y
Pv3IPrbEgWzQZ18+ilQ7tiJR8g5qtfASd0Qokj3Fgr424d4wjjI+IHBmLJulbt7tadq22lH5nQ3g
r3vPCBeU568Tfwq3CBzP5tXaOoh7KFRDgWwY4pYW3dhql/qtiTAAU/k+GZZlPP0I1T9xDBKHqvLA
vjJ4oXhxshcU47gm/ug5kv36i0o8j/12ONYmHIIWQX7UWz9LvWJTvHPk5+hW8+DTUDaCh//f4GVb
Qt4p2GLUgzJ7cILAMg5XbLdC07VA/ml9fMU0GvQWFzBxJuHLoNyCF1azw6tCFKCZB0GbgpSg0Tdx
8j1ykG+BNJlscgYP8sCNt7ORf20Hrz8tHvnawOCSsAmQZSCRjVEO/YuOAiTzlLFp5jxJZLXSCVXx
PHeF5xSY21ycEmeuBK7vY0X38/JfAc0k+WEBK1432hGIdtLz1RwjbzvLBznh5EX0WIuThxQoJ6u7
ZJr17HjylbFgFwfcJkWVeZS7ICHG1D7hJ4yqYrCxyVLxC5qkTmzfpqwdxaHf1ZmbZ8rI6w4QcXMy
hNDOaZOGV5ju6DHGR3ie0tDXyYuKu/UugnmAgBVm0+GZ6wmRmX/N3FRSWLG61pDuI5JWwYXQ6uWj
hNgzoRXblO6eEUq/BLXZ0Fv4/Q1R4zNwOcVbdYorWlWxPBfEO8uRJiO1FL6n3hBsT7pbEDXp4yLQ
G+bgJfU5Q6tLKIXR+1fGAA+GLgHKv6YdAh5TwP6oNrI4h3s6JnJRvriwoir2R4iUcjUIJmk+XDY7
fuDMiZCU+DvGp6XmwgC4THIccmYUCcQduCzr9W8y8A3U0K83fCPQAa/hTKpYjHP5WzG4HzWg5VDs
yWwuLszr2hc5WX/4/kddZLuzTOAWro+hjUJR1PJcMUJI6qjr5OlnPZ80qv+ZD4T3hMTcDc18Ayfh
gP5WXqQMpiMRto1TKLZtl7i74jn2Jq9CE1Vkz2KVohYbTGl9/WZhncWfeI8ihGBQwk3DCCl7fZW7
hxWvNZxxW2e5RzmKqAzPUlfEq8WpNzwu8uL7QVeQRjq4wZrT5VgALXkHfms5r1MAJbueXKf9U8Gk
dTF00QmQnOkOAK6RNmPvlCUafRXh+h7pvlBOleUVJW2hddVbLwJyH1N1qnC3nM35MTT/lCRoQQz9
qv3c6ZL+eSt9TQx+hAgkSzLALZCfMstqbj0ZkVc5I55sZqyxyM2XkOGoVrAz7kn9u2P62Xoo7lz7
iVQEl5/qcM00Ll32lz9IKlkQOGpddwwqcbdap4DA3CqYONNWtUK4Cbcx6sSKVBxADpoCr1m8BRWV
Sx2PQ9Tw2V8eiO79iuAFHo0TCa1RA1no3E7yAZVjctRpn340EHfO2xiEPzG8zLHxqtcrcqp3IzHJ
KoHHGvSC606cDGh0dHACAAAAMAUAAA5/+IJnWs7WVAscosvo+dn39bgMbnyuUKhBGmF+rCynWFDf
6E0x2QVJqVKRukBrgo1XzhTG7XdKDjYyfQ43y1+cX9AKKOTXVwDpXLxnoHMRWlXmO36YDzBivO4E
h7GAnaJco0z9FfqPYsT0v49gurvEHDWixk/5GLnuwHTRyTBG20kvEvnQKEWWmonBHsnlpFnEPB3s
ttG/fZQsh5/3vqjkHgZ9vWPKnqZJbTTVt8ISJcZ1vj3z5j6Hsnh2B8x9ze7Lo3z2aNmMoWUaNPr7
db58b1oEyBQyLoHv33it/zdP/D06O/XdoZ+PLWfHnqx/4dqaNaXK5aBPqWQCP8ztjPGMBJwqyTSk
m1aeQUdjwBmLE+dH52MV3ol3gcVRTrRknGnJW4OVAdq6SCzBRsXV/M4S3Agxf99Is2YWRmMLLzAm
nUo+tTv+7b8KkNPoJCQF4foIJX8XRx5o0REbHvlCGpxSckPZeXsSJHXTd4E3wSxUySZHQC8t4jle
9DQ/X5BlS364ni/Ara+flpT0kWv5MmqUsetT8S/wqGH6zvr/jWq1GC+CV1aQo0JKO5vOB7cOr/vl
qfOvo+0g69h48fv40+BMHFQhlazcETWcm40l4W4AAxFDE/QwBhQUHgoKdwYeVhYmrl5rFtl0IiT3
zRlBkCpJf/bQPkQc8R3VKSh3BRZxrQWYWLTf5VTRaGhbrFELpp9iUrSGor+2YFkZ78+DyRzT+zFy
V3u9IAIt8kAd/sNB5riVO5ZxErVI+usYgjb2D5ZcmUEHpgWse76VeWCn2dRH3YWQQJg+G8vFoT21
NjaT7JB65Mdaqjqe3yM5GpsUhKZfF3tL11J6lM7v2ldx/TR6HsC3eCgCMl70relxQOIC9HKP3s8A
uIFxV6vUPpoMhtHO4lb5s7dVRG4G0Aw8H1AImDyd5m33UE1Bvj1yXWhGJUqR0XKDLFoahrBFYjV/
6lfAlneiIL5jt3dgG3zroe9nDMqObhNY98C8gk6A5eYKH7raOVCI9uWIC4Fc02/E9FHYA11CNlzF
WRRmMs77S7AkTV4M9a6RuWd7bfJSUD+THx47DhbHwbQm5l+CmSkBm56kXE7W8TA+j+fNlMXVLtrL
VFj8sL4spM0QUuoP6RynDX7b8gtkytPIpXqq07Mv+Qqhwg7Eyfp77DpotmxyWLl/3EUl5MyuSv+l
cvTVUBD5K4CeI6KeRQssFZBdXAPGEGu27ho/b30/83YWe1HpyuxynU5TwBNCW7RlkufkCxISjV+v
G8G8AsXAD6nUYX2cSNjOQbh7RL0oqbSkhCLCuBeD//IAAAyNQ7fEREOgszKx9F0aGVJju0Ezcpmp
IY158YQz09mnldhJQsO4lf0ffZkqHNX8ufbU4UCRWGNCtu/Df8ong1c7x3lSTQ6VLzhsriO+YFRg
z9CpiLsFY1w5QpGVrjQD+0sPCIlLfwW3jmHdi1/NnuefjLPTaYxD978dhWFJqIMzv6Mg+557DCOy
oZJE52dK6C59ESO6+uNaRR9eDlNyNhqpkCtCzV7CzLSWK6vpS/32UsavTNvR/Xj6KSTyUMLBYaoB
xc39MsL3YO+XRfJy+sRSs2d2VEZDCEFzbuZGPzbHWGLpt09sCVL9802p8leOVBd4SS94WlWpMe/t
dLsJuR54vZ5vQ9rRTgB12W+hAkOJkDCk9rnwVAnWgrOhgcuAJaxcFxrx6pgNBB+o2Sg125eM5ubI
TJXUN0CM7VUlrGG5CWWfdkfQOU0E9D3B4Vbi7PWeTtA1fIDqEl6C9Ic/2R12uhHaATVcO44YUE3M
KEsAAWl4rY4P6VgCsVfPFfxiwuB3iXagmnf59Y391HznsL3HaOp3H/ddEelw3tRSdsRDvc8QMfJE
+V+kdN1j4xnnWZriufkhDQ0sxrgtQqZEQKRVpee4X5ddfIMXwtlhlxr7iVPSIBSGDRtTXJzUonnZ
l7UbU/R24MxRmi4GQ0MVnvc0acSkJtiEfp+fy3YebBfuvlGWl92lDY4W4OdFoziC6iJl34hxZu+7
Hz3et9h/fsaLnzi+yVoQcFhVJhhXyJHeUleepON6BDAjjP/19pXOAEio0xSdGgCFICzZuZwkp54C
wM4WQapTS6phaAEHIMmeLcrdLh1QNGvKiZfYQ7qz2OfUOuxl1ZtcbrQ4CpFx7AQAYtSL4Nzk0lIW
yMcCu9L1VhOfd0pnh5qYqAqUSSu2AcQDapxDTnVesrdbzgJ60YZOfeXI4AvyeiqlEGx6OZfT2AhF
u9wDOlHLyHW7Xu8vqL39RFVjcZnaftNK6CCEaWT5kwdfznyNaxHH/W/V1Qm3/m56vhWgDYDKZAJJ
QzMwqcLPcvP5ugo2nj9BuCIj1kkVTw4uRwokpwUEFKmOV3WoC1QdsG+LfW8gDDWirdYIdyRWKTeq
Maa/1ZuhHiBqvupL+pSGSwgTVKwNUL2O+j6OmVejPAFlBxAjWrr3dpSm/DWJyQ3cELWQNKdUeopH
CkeFVKO1QKRf6TexuD7TwOkkqD1wjZ3TVq0ykjzMq8emyUt+tSJi56BqhYHo/fSWZ6foLnDDh2yb
fTYNU9dfCZgL9rI3PoCPeEV2NQKcIAUtcL3sA6RysFlirvwi2a7MdCoq9QWRyoFzh8G27OhV1ZZ8
1nueizE0XcT6VthXvn2F/YEDQNAMa5FdcBe7vfDcGZUM5OjXkB8+RTxTd+rusXkNzweXd881qriM
BLa+lWrneaT/VhkzuVWOkobEbOvUzwInE7XH6f6zM9mbNxqn7CBOmxLNC6kJ/7a/+2jQglawnYuL
UqIEmxboAKsA3GmwIvgBV8KDqNnDBwMxCiUKapWgt2oJaLwClKD5lmy/h1ssrA89PjLeV97vWpYF
mozY5zv6Z3zDufPlqU8qxmyPpz+MFhYqWYC3f3EcEhxiSvog6UsmCUBt6zgd2rrZ6E5BUOwlthh1
DaoJsSygiNUsgqJCmRyCSU4ePaq3xGDSs0GS/Dtej6P0UOHjFotwLewpF9khpsKqiYi39BR9CvAj
S7i5jumkn018haC18G1Dc39DpRywDkjwOirFqG/2w4zx9htmTyuMrD943/M1wm+psVc0QQFOrIm9
NGym0m0naoN2ICu/16PanhCJu2lr46T7mi2xrSYxKy5QH4kflq5uaCMSia7t8+4fsdZDE222xHrq
CSKHYXymhUs46OqzJi413Gc2TmfOxgLxhaPMIGOqflMCrZwPJYZoK9H/Vp4Kkmujn4ui7/g3ys+P
ASrq9Gc4OzFLhPD8ia9+lKT9EQzcBZnwdaPKn6nXG1HV7GQFMpN08jCYIgHVnjnJAAE2A3ldRzT+
zoj85VwHEZXrGvTol5+OCeZ+RvwzHmiYod3rGpr3x3n/ZjDPZs4NDk3P/BwAyMix6Bb2l+Ln1VoA
ZWuSEd5c8nsIkaZkQmXAzy1OyJpDC3BgbBd0UA631csPgfUaRMlGRaAI09zMcWkEMccjd/UubXuh
e2U7w+fBkjpn0Ln+U1t63tnFN9eunqYVfsw5R2mthEzNMKr90xpwsQ61u/LXme6N3sim/S7Xe1XU
cPBMe5fIi7VY6dQDhmNwVYFN8TufX1b1hYXVkgoown1zGKJXTp3rhwDSCsxhl8d/eEF2Xwdk3iOi
P/DrZ2IZXzu6TV2sw60/TyDAbcjjMBVOtrbobnRjEvb+vqDfNdIAgvx64F21aE8pc5fPCLhymPDP
fFqzBLH2YD5g5++86b8UTOkwGxbjIuJHcgFw8/t4HtfGldiIFHndA1MvIZ2+qBowJeuwTm3bCQ6c
nGHUnFuYj2QWHm7dLqsX8Wwpg6Di4jYu4ONa0GfFD6Xxg9cyKaSkw08nX//xKBKT6GFhLMCNEECy
xHyHzuTeiuPA/O5krlAueTl/tBHqMTCFsuXMrUG8NP3eupB4/lMC6y59xhsI76BOVuN2+/r7zr1I
MHRONLGdnZkv1bG3DlrzLiu/ka5/ifLzRSLXBWmtzO7Y41T1u5FEeLLLorkyAL2pUYrw+BYgnO3W
61PHt+Q1EDIQFX8v8yFZmiL4Ip9Q2CGC7xLfYRWohp3cvnBZ82rWDhVYBU8h8HYfGC/suAmf9eq/
G204JaYYeyc7P+pPVU1DdlpfLk76PjxETBrOhwDWZsqY4eEcensZYaAFIDkaWrmPrL9Gg5dwo5O7
j536cu2p30UteSv1L2pe2nA4qN5B4s54vG9A1fnZdB5KdEY5nHVOliMngv39i/UHjyIlEkDKarzo
dmMVxYJBHV90jezaOe/p25U3SOFj6fx4ZOXK5quuVeuhN3GHWFkgkTC0322OGHRXWoEpNARYNv+z
hT+CubmnKToNod9a4MfI76p6fmRNl9++ZOFR+O3zt7XzQOhqn31ZHjLg0nCJGpV70kQYXmqEkdJe
LdFeGOE2elBr+NS/ioiLYE+8JtSHktJVJOanjQ4PZe3gSkGMWpRanxyTaJOTRaME23oAPi3h9Axs
DprP79rIOTzBU+LQU/Hwxl3mapCAet2a6OBBcce/7wD+sA2se16kQwlZCIAGp88e/Pv5MCE3Bb0d
dm7LEzCoiHTyVvqLe7nu6KKiHI29/oDWVjrHrEVrHYt4rInxFM+6wo8ZVp7EWbpPvHCrwN7iU2QX
7ENNxZb2SefMHgDTfn87yF//NIasbekUM6o6Oe8bEU03tTS4Mj9v9nEyY4o/4vKvtKr5t+O0Zpuz
yrAoKYqrUzxdc1Rs3Tlv1YwsdzTFC8po63CbiJoIb7PbX4rlM6TVgW6MX1YJg2le+hTikcIEsTFu
ZXdzAgAAAPANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

----VEHM3OTYBKT--


From owner-ietf-pop3ext  Tue Apr 17 03:31:40 2001
Received: by above.proper.com (8.9.3/8.9.3) id DAA01642
	for ietf-pop3ext-bks; Tue, 17 Apr 2001 03:31:40 -0700 (PDT)
Received: from tamaris.wanadoo.fr (smtp-rt-12.wanadoo.fr [193.252.19.60])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA01631
	for <ietf-pop3ext@imc.org>; Tue, 17 Apr 2001 03:31:37 -0700 (PDT)
Received: from villosa.wanadoo.fr (193.252.19.122) by tamaris.wanadoo.fr; 17 Apr 2001 12:31:07 +0200
Received: from stef.freeplanning.fr.a (193.250.4.29) by villosa.wanadoo.fr; 17 Apr 2001 12:31:05 +0200
From: Stéphane LOEUILLET <stephane@freeplanning.com>
Organization: FreePlanning SAS
To: ietf-pop3ext@imc.org
Subject: Virus in 'Branca de Neve pornô!' mail on list
Date: Tue, 17 Apr 2001 13:24:23 +0200
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <01041713281300.05623@stef.freeplanning.fr.a>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA01636
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Hi,

there is a virus in this mail.

If i remember what my antivirus told me, it is 'W32/Hybris-B'
It kindly modify 'wsock32.dll' and spreads via the mail system.

The attachment (a screen saver, so an executable) has to be runned to launch
the virus. If you have just read the mail without executing the attachment,
there is no problem.

Only windows users are concerned.

Bye

From owner-ietf-pop3ext  Sun May  6 16:14:15 2001
Received: by above.proper.com (8.9.3/8.9.3) id QAA18343
	for ietf-pop3ext-bks; Sun, 6 May 2001 16:14:15 -0700 (PDT)
Received: from bsun05. (bsun05.bre.polyu.edu.hk [158.132.106.17])
	by above.proper.com (8.9.3/8.9.3) with SMTP id QAA18335
	for <ietf-pop3ext@imc.org>; Sun, 6 May 2001 16:14:12 -0700 (PDT)
From: zr94@yahoo.com
Received: from littlenipples.nu by bsun05. (SMI-8.6/SMI-SVR4)
	id HAA14196; Mon, 7 May 2001 07:02:16 +0800
Message-Id: <200105062302.HAA14196@bsun05.>
To: <ietf-pop3ext@imc.org>
Subject: I need a POP3 mailbox...
Date: Sun, 06 May 2001 16:20:13 -0700
MIME-Version: 1.0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: zr94@yahoo.com
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

<HTML>
<BODY>

<FONT face=3D"MS Sans Serif">
<FONT size=3D2> Hello,<BR>
<BR>
I need a bulletproof POP3 mailbox that won't be shut down for spamming.<BR=
>
My mailboxes keep getting shut down.<BR>
<BR>
Can you help?<BR>
<BR>
If not, can you refer me to someone who can?<BR>
<BR>
Thank you very much,<BR>
<BR>
Mike<BR>
zr94@yahoo.com<BR>
<BR>
</FONT></FONT>
</BODY>
</HTML>



From owner-ietf-pop3ext  Wed May  9 03:00:15 2001
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id DAA24649
	for ietf-pop3ext-bks; Wed, 9 May 2001 03:00:15 -0700 (PDT)
Received: from pavilion (a24b31n80client230.hawaii.rr.com [24.31.80.230])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA24629
	for <ietf-pop3ext@imc.org>; Wed, 9 May 2001 03:00:11 -0700 (PDT)
Message-ID: <2069520015399526860@pavilion>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
X-MSMail-Priority: Normal
From: "Mitchell" <mail2@pcpostal.com>
To: ietf-pop3ext@imc.org
Subject: Business/Employment Opportunity
Date: Tue, 8 May 2001 23:52:06 -1000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id DAA24642
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>

Dear Friend:

"Making over half million dollars every 4 to 5 months from your
home for an investment of only $25 U.S. Dollars expense one
time"

THANKS TO THE COMPUTER AGE AND THE INTERNET!
===============================================

BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !!

Before you say "Bull" , please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below , to see if it really can make people
money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are "absolutely
no laws prohibiting the participation in the program and if people
can follow the simple instructions, they are bound to make
some mega bucks with only $25 out of pocket cost".

DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT
THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING
BETTER THAN EVER.

This is what one had to say:

"Thanks to this profitable opportunity. I was approached
many times before but each time I passed on it. I am so glad
I finally joined just to see what one could expect in return
for the minimal effort and money required. To my astonishment, I
received total $ 610,470.00 in 21 weeks, with money still
coming in".
Pam Hedland, Fort Lee, New Jersey.

-------------------------------------------------------------------------

Here is another testimonial:

"This program has been around for a long time but I never
believed in it. But one day when I received this again in
the mail I decided to gamble my $25 on it. I followed thesimple instructions and walaa ..... 3 weeks later the money
started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00.
So far, in the past 8 months by re-entering the program,I
have made over $710,000.00 and I am playing it again.
The key to success in this program is to follow the simple
steps and NOT change anything ."

More testimonials later but first,

****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *******

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ
IT AGAIN and AGAIN !!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR
FINANCIAL DREAMS WILL COME TRUE, GUARANTEED!

INSTRUCTIONS:

**** Order all 5 reports shown on the list below.

**** For each report, send $5 CASH, THE NAME & NUMBER OF THE
REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS
to the person whose name appears ON THAT LIST next to the report.
MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
TOP LEFT CORNER in case of any mail problems.

**** When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on your 
computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00.

**** Within a few days you will receive, via e-mail, each of the 5
reports from these 5 different individuals. Save them on your computer
so they will be accessible for you to send to the 1,000's of people
who will order them from you. Also make a floppy of these
reports and keep it on your desk in case something happen to your
computer.

****.IMPORTANT - DO NOT alter the names of the people who are
listed next to each report, or their sequence on the list, in
any way other than what is instructed below in steps 1 through6 or you will loose out on majority of your profits. Once you
understand the way this works, you will also see how it does not work if you 
change it.

Remember, this method has been tested, and if you alter, it
will NOT work!!! People have tried to put their friends/relatives names
on all five thinking they could get all the money. But it does not work this 
way. Believe us, we all have tried to be greedy and then nothing happened. 
So Do Not try to change anything other than what is instructed. Because if 
you do, it will not work for you. Remember, honesty reaps the reward!!!

1.. After you have ordered all 5 reports, take this advertisement
and REMOVE the name & address of the person in REPORT # 5. This
person has made it through the cycle and is no doubt counting
their fortune.

2.... Move the name & address in REPORT # 4 down TO REPORT # 5.

3.... Move the name & address in REPORT # 3 down TO REPORT # 4.

4.... Move the name & address in REPORT # 2 down TO REPORT # 3.

5.... Move the name & address in REPORT # 1 down TO REPORT # 2

6.... Insert YOUR name & address in the REPORT # 1 Position.

PLEASE MAKE SURE you copy every name & address ACCURATELY !
=========================================================

Take this entire letter, with the modified list of names, and save
it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.

To assist you with marketing your business on the internet, the
5 reports you purchase will provide you with invaluable
marketing information which includes how to send bulk e-mails legally,
where to find thousands of free classified ads and much more.

There are 2 Primary methods to get this venture going:

METHOD # 1 : BY SENDING BULK E-MAIL LEGALLY
============================================
let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive only a0.2% response (the response could be much better but lets just
say it is only 0.2% . Also many people will send out hundreds of
thousands e-mails instead of only 5,000 each).

Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail
each for a total of 50,000. Out of those 50,000 e-mails only
0.2% responded with orders. That's = 100 people responded
and ordered Report # 2. Those 100 people mail out 5,000
e-mails each for a total of 500,000 e-mails. The 0.2% response
to that is 1000 orders for Report # 3. Those 1000 people send
out 5,000 e-mails each for a total of 5 million e-mails sent out.
The 0.2% response to that is 10,000 orders for Report # 4.
Those 10,000 people send out 5,000 e-mails each for a total of
50,000,000 (50 million) e-mails. The 0.2% response to that is
100,000 orders for Report # 5.

THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million).

Your total income in this example is:
1..... $50 +
2..... $500 +
3..... $5,000 +
4..... $50,000 +
5..... $500,000 ......... Grand Total = $555,550.00

NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE
OUT THE WORST POSSIBLE RESPONSES AND NO MATTER
HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF
MONEY !

------------------------------------------------------------------------------

REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for
a moment what would happen if everyone, or half or even one 4th
of those people mailed 100,000 e-mails each or more? There are
over 250 million people on the internet worldwide and counting.
Believe me, many people will do just that, and more!

METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
===================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free adson the internet will easily get a larger response. We strongly
suggest you start with Method # 1 and add METHOD # 2 as you go
along.

For every $5 you receive, all you must do is e-mail them the Report
they ordered. That's it . Always provide same day service on all
orders. This will guarantee that the e-mail they send out, with your
name and address on it, will be prompt because they can not advertise until 
they receive the report.

_____________________ AVAILABLE REPORTS_____________________

ORDER EACH REPORT BY ITS NUMBER & NAME ONLY.

Notes: Always send $5 cash (U.S. CURRENCY) for each Report.
Checks NOT accepted. Make sure the cash is concealed by wrapping
it in at least 2 sheets of paper. On one of those sheets of paper,
Write the NUMBER & the NAME of the Report you are ordering, YOUR
E-MAIL ADDRESS and your name and postal address.

PLACE YOUR ORDER FOR THESE REPORTS NOW :
==============================================
REPORT #1, "The Insider's Guide to Sending
Bulk E-mail on the Internet"

ORDER REPORT #1 FROM:

G. Donaldson
P.O. Box 25884
Honolulu, Hawaii 96825-0884


don't forget to provide a permanent e-mail address in clear writing (better 
typed) to receive the reports. We had problems in delivery e-mails before!!!

==============================================
REPORT #2 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #2 FROM:

Vijay Paul
C-291, Second Floor
Defence Colony
New Delhi - 110024
INDIA

==============================================
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
ORDER REPORT #3 FROM:

JD
P.O.Box 1114
Des Plaines, IL 60017
USA

==============================================
REPORT #4 "How to become a Millionaire utilizing the Power of
Multilevel Marketing and the Internet"
ORDER REPORT #4 FROM:

J Santi
833 Walter Ave
Des Plaines, IL 60016
USA

==============================================
REPORT #5 "How to SEND 1,000,000 e-mails for FREE"
ORDER REPORT #5 FROM:

Elaine Rix
138 Dundas Street, West, #243
Toronto, Ontario
Canada M5G 1C3

==============================================
There are currently more than 250,000,000 people online
worldwide!

$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$

Follow these guidelines to guarantee your success:

If you do not receive at least 10 orders for Report #1 within 2
weeks, continue sending e-mails until you do.

After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2.
If you did not, continue advertising or sending e-mails until
you do.
Once you have received 100 or more orders for Report # 2,
YOU CAN RELAX, because the system is already working for
you , and the cash will continue to roll in !

THIS IS IMPORTANT TO REMEMBER : Every time your name is
moved down on the list, you are placed in front of a different report.
You can KEEP TRACK of your PROGRESS by watching which
report people are ordering from you. IF YOU WANT TO GENERATE
MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND
START THE WHOLE PROCESS AGAIN. There is NO LIMIT to
the income you can generate from this business !!!
____________________________________________________

FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM:

You have just received information that can give you financial
freedom for the rest of your life, with NO RISK and JUST A
LITTLE BIT OF EFFORT. You can make more money in the
next few weeks and months than you have ever imagined.

Follow the program EXACTLY AS INSTRUCTED. Do Not change
it in any way. It works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you
have put your name and address in Report #1 and moved others to
#2...........# 5 as instructed above. One of the people you send this to may 
send out 100,000 or more e-mails and your name will be on everyone of them. 
Remember though, the more you send out the more potential customers you will 
reach.

So my friend, I have given you the ideas, information,
materials and opportunity to become financially independent. IT IS UP TO YOU 
NOW !

************** MORE TESTIMONIALS ****************

"My name is Mitchell. My wife , Jody and I live in Chicago.
I am an accountant with a major U.S. Corporation and I
make pretty good money. When I received this program I grumbled
to Jody about receiving ''junk mail''. I made fun of the
whole thing, spouting my knowledge of the population and
percentages involved. I ''knew'' it wouldn't work. Jody
totally ignored my supposed intelligence and few days later she jumped in 
with both feet. I made merciless fun of her, and was ready to
lay the old ''I told you so'' on her when the thing didn'twork. Well, the laugh was on me! Within 3 weeks she had received
50 responses. Within the next 45 days she had received a
total of $ 147,200.00 all cash! I was shocked. I have
joined Jody in her ''hobby''."
Mitchell Wolf,
Chicago, Illinois

------------------------------------------------------------

"Not being the gambling type, it took me several weeks to
make up my mind to participate in this plan. But conservative that
I am, I decided that the initial investment was so little
that there was just no way that I wouldn't get enough orders to at
least get my money back.

I was surprised when I found my medium size post office box
crammed with orders. I made $319,210.00 in the first 12
weeks. The nice thing about this deal is that it does not matter
where people live. There simply isn't a better investment
with a faster return and so big."
Dan Sondstrom, Alberta,
Canada

-----------------------------------------------------------

"I had received this program before. I deleted it, but
later I wondered if I should have given it a try. Of course, I had
no idea who to contact to get another copy, so I had to wait
until I was e-mailed again by someone else.........11 months
passed then it luckily came again...... I did not delete this
one! I made more than $490,000 on my first try and all the
money came within 22 weeks".
Susan De Suza,
New York, N.Y.

----------------------------------------------------

"It really is a great opportunity to make relatively easy
money with little cost to you. I followed the simple
instructions carefully and within 10 days the money
started to come in. My first month I made $ 20,560.00
and by the end of third month my total cash count was
$ 362,840.00. Life is beautiful, Thanx to internet".
Fred Dellaca, Westport,
New Zealand
------------------------------------------------------------


ORDER YOUR REPORTS TODAY AND GET STARTED ON
YOUR ROAD TO FINANCIAL FREEDOM !

=======================================================

If you have any questions of the legality of this program, contact the
Office of Associate Director for Marketing Practices, Federal Trade
Commission, Bureau of Consumer Protection, Washington, D.C.


Under Bill s.1618 TITLE III passed by the 105th US Congress this
letter cannot be considered spam as long as the sender includes
contact information and a method of removal.
This is one time e-mail transmission. No request for removal is
necessary.

------------------------------------------------------------
This message is sent in compliance of the new email
Bill HR 1910. Under Bill HR 1910 passed by the 106th
US Congress on May 24, 1999, this message cannot be
considered Spam as long as we include the way to be
removed. Per Section HR 1910, Please type "REMOVE" in
the subject line and reply to this email. All removal
requests are handled personally an immediately once
received.








From owner-ietf-pop3ext Thu Aug 30 06:09:04 2001
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id f7UD94500394
	for ietf-pop3ext-bks; Thu, 30 Aug 2001 06:09:04 -0700 (PDT)
Received: from marvin.nildram.co.uk (marvin.nildram.co.uk [195.112.4.71])
	by above.proper.com (8.11.6/8.11.3) with SMTP id f7UD93D00390
	for <ietf-pop3ext@imc.org>; Thu, 30 Aug 2001 06:09:03 -0700 (PDT)
Received: (qmail 30045 invoked from network); 30 Aug 2001 13:09:02 -0000
Received: from unknown (HELO paul.pscs.co.uk) (195.149.15.3)
  by marvin.nildram.co.uk with SMTP; 30 Aug 2001 13:09:02 -0000
Received: from 192.168.57.101 by paul.pscs.co.uk ([192.168.57.100] running VPOP3) with ESMTP for <ietf-pop3ext@imc.org>; Thu, 30 Aug 2001 14:09:28 +0100
Message-Id: <5.1.0.14.2.20010830135635.06bfae68@192.168.57.100>
X-Sender: paul@192.168.57.100
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 30 Aug 2001 14:09:26 +0100
To: ietf-pop3ext@imc.org
From: Paul Smith <paul@pscs.co.uk>
Subject: Problem with AUTH response from MSN
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Server: VPOP3 Enterprise V1.5.0 - Registered
X-Organisation: Paul Smith Computer Services
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


I've just seen what looks like a problem with the authentication on MSN, 
and I was wondering if anyone else has either seen the problem before, or 
has any comments..

Here's a (slightly obfuscated) transcript of the session:

S 1	+OK CPIMSPOPA16.email.msn.com POP3 Server
C 2	AUTH MSN
S 3	+
C 4	gobbledegook=
S 5	+
C 6	
S 7
C 8	STAT
S 9	+OK Mailbox for markhaas has 4 messages.

It all looks OK until line 6 or 7. I *think* the problem is at line 7, 
because, from my reading of RFC1734 the server should respond either '+...' 
as a challenge, or '+OK' or '-ERR' to indicate the result of the 
authentication. A blank line from the server wouldn't seem to be a valid 
response

Now, I can easily make the client ignore a blank line at this stage, but I 
only want to do that if (a) MSN is working properly, and I misunderstood 
the standard or (b) MSN isn't going to fix their server soon (anyone from 
Microsoft listening? ;-) )


(The 'STAT' from the client is because the sequence is confusing the 
client, so it's sending a 'STAT' command before it should do and then all 
the server responses are out of sync)

Paul				VPOP3 - Internet Email Server/Gateway
paul@pscs.co.uk			http://www.pscs.co.uk/



From owner-ietf-pop3ext Thu Aug 30 12:03:28 2001
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id f7UJ3S215136
	for ietf-pop3ext-bks; Thu, 30 Aug 2001 12:03:28 -0700 (PDT)
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UJ3RD15132
	for <ietf-pop3ext@imc.org>; Thu, 30 Aug 2001 12:03:27 -0700 (PDT)
Received: from gotmail-a.red.iplanet.com (gotmail-a.red.iplanet.com [192.18.73.248])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f7UJ3JZ29500;
	Thu, 30 Aug 2001 12:03:19 -0700 (PDT)
Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95])
 by we-gotmail.red.iplanet.com
 (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GIW0000XA8V72@we-gotmail.red.iplanet.com>; Thu,
 30 Aug 2001 12:02:55 -0700 (PDT)
Date: Thu, 30 Aug 2001 11:59:06 -0700
From: Chris Newman <cnewman@iplanet.com>
Subject: Re: Problem with AUTH response from MSN
In-reply-to: <5.1.0.14.2.20010830135635.06bfae68@192.168.57.100>
To: Paul Smith <paul@pscs.co.uk>, ietf-pop3ext@imc.org
Message-id: <412190.999172746@nifty-jr.west.sun.com>
MIME-version: 1.0
X-Mailer: Mulberry/2.1.0b3 (Mac OS/PPC)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <5.1.0.14.2.20010830135635.06bfae68@192.168.57.100>
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Correct.  The server is violating RFC 1734 at line 7 of the transcript.

But MSN is a non-standard authentication mechanism anyway, so if you want 
to use it you have to use it exactly the same way Microsoft clients use it.

		- Chris

--On Thursday, August 30, 2001 14:09 +0100 Paul Smith <paul@pscs.co.uk> 
wrote:

>
> I've just seen what looks like a problem with the authentication on MSN,
> and I was wondering if anyone else has either seen the problem before, or
> has any comments..
>
> Here's a (slightly obfuscated) transcript of the session:
>
> S 1	+OK CPIMSPOPA16.email.msn.com POP3 Server
> C 2	AUTH MSN
> S 3	+
> C 4	gobbledegook=
> S 5	+
> C 6	
> S 7
> C 8	STAT
> S 9	+OK Mailbox for markhaas has 4 messages.
>
> It all looks OK until line 6 or 7. I *think* the problem is at line 7,
> because, from my reading of RFC1734 the server should respond either
> '+...'  as a challenge, or '+OK' or '-ERR' to indicate the result of the
> authentication. A blank line from the server wouldn't seem to be a valid
> response
>
> Now, I can easily make the client ignore a blank line at this stage, but
> I  only want to do that if (a) MSN is working properly, and I
> misunderstood  the standard or (b) MSN isn't going to fix their server
> soon (anyone from  Microsoft listening? ;-) )
>
>
> (The 'STAT' from the client is because the sequence is confusing the
> client, so it's sending a 'STAT' command before it should do and then all
> the server responses are out of sync)
>
> Paul				VPOP3 - Internet Email Server/Gateway
> paul@pscs.co.uk			http://www.pscs.co.uk/
>
>



From owner-ietf-pop3ext Tue Feb 19 14:31:50 2002
Received: by above.proper.com (8.11.6/8.11.3) id g1JMVob12011
	for ietf-pop3ext-bks; Tue, 19 Feb 2002 14:31:50 -0800 (PST)
Received: from marvin.nildram.co.uk (marvin.nildram.co.uk [195.112.4.71])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g1JMVl312007
	for <ietf-pop3ext@imc.org>; Tue, 19 Feb 2002 14:31:48 -0800 (PST)
Received: (qmail 1529 invoked from network); 19 Feb 2002 22:31:49 -0000
Received: from unknown (HELO mail.pscs.co.uk) (195.149.15.3)
  by marvin.nildram.co.uk with SMTP; 19 Feb 2002 22:31:49 -0000
Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.59.3] running VPOP3) with ESMTP for <ietf-pop3ext@imc.org>; Tue, 19 Feb 2002 22:29:26 -0000
Message-Id: <5.1.0.14.2.20020219222323.08120e50@lmail.pscs.co.uk>
X-Sender: paul@lmail.pscs.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Feb 2002 22:31:12 +0000
To: ietf-pop3ext@imc.org
From: Paul Smith <paul@pscs.co.uk>
Subject: Is there are replacement for 'UIDL'?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Server: VPOP3 Enterprise V1.5.1 - Registered
X-Organisation: Paul Smith Computer Services
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


I've just had an email from one of our users, which they've been sent by 
their ISP (British Telecom) which looks to me like total baloney (which 
wouldn't be unusual), but I just want to check that there's not something 
I've missed...

Anyone out there want to read through it, and tell me that I'm correct, or 
that I've missed something?

Basically, if you send their server a 'UIDL' command it gives you a set of 
IDs for the messages, then if you ask a few hours later, it'll give you a 
totally different set of IDs for the same messages. As far as I am 
concerned this is a breach of the relevant bits of RFC 1939.

Their response was:

BTInternet as was, now BTOpenworld, whose server actually holds my "real" 
mailbox acknowledge that changed UIDL's can be demonstrated [now with 
increasing frequency] BUT they say that their server does not add a UIDL AT 
ALL to any messages on their servers, they are using, instead, their own 
Unique Message ID [which does persist across sessions]. They say that this 
is acceptable under RFC POP3 supplemental extension rules and blame 
BTWebworld [the domain-forwarding source of most of my mail] for ?somehow 
attaching changeable UIDL's which are confusing VPOP3 [our mail software].


They seem to be saying that this 'Unique Message ID' is a replacement to 
the UIDL which they claim not to add to messages, but which their servers 
WILL give you if you send a UIDL command. I don't know what these 'RFC POP3 
supplemental extension rules' are that they're talking about.

The only thing I can think of which they could mean by 'Unique Message ID' 
is the 'Message-Id:' header line which is normally added by the message 
SENDER, not POP3 server, and which isn't *guaranteed* unique as a UIDL is. 
Also, it's not generally a usable replacement for UIDL since there's no 
quick way of getting it.

Is there anything I've missed, or is it just waffle from an ISP which 
doesn't know what it's talking about?

I don't see what's hard about assigning a constant UIDL to each message. 
And if they really find it as difficult as they seem to, surely they should 
simply not implement the UIDL command at all - after all it's optional.

Paul				VPOP3 - Internet Email Server/Gateway
paul@pscs.co.uk			http://www.pscs.co.uk/



From owner-ietf-pop3ext Tue Feb 19 15:31:38 2002
Received: by above.proper.com (8.11.6/8.11.3) id g1JNVcn12791
	for ietf-pop3ext-bks; Tue, 19 Feb 2002 15:31:38 -0800 (PST)
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JNVb312787
	for <ietf-pop3ext@imc.org>; Tue, 19 Feb 2002 15:31:37 -0800 (PST)
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.4386);
	 Tue, 19 Feb 2002 15:32:08 -0800
Received: from 10.197.0.60 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Feb 2002 15:31:30 -0800
Received: from BEG.platinum.corp.microsoft.com ([10.197.0.46]) by DF-YURI.platinum.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 19 Feb 2002 15:31:30 -0800
Received: from df-benji.platinum.corp.microsoft.com ([10.197.1.10]) by BEG.platinum.corp.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 19 Feb 2002 15:31:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6147.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Is there are replacement for 'UIDL'?
Date: Tue, 19 Feb 2002 15:31:29 -0800
Message-ID: <171E417EF48FB54BA3C238F08C3EEF065A6DC9@df-benji.dogfood>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Is there are replacement for 'UIDL'?
Thread-Index: AcG5lVEmxrk2sUE0Qnm4hfYI0AsFLAABgQag
From: "Jeff Stephenson" <jeffstep@EXCHANGE.MICROSOFT.com>
To: "Paul Smith" <paul@pscs.co.uk>, <ietf-pop3ext@imc.org>
X-OriginalArrivalTime: 19 Feb 2002 23:31:30.0477 (UTC) FILETIME=[8F177DD0:01C1B99D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1JNVb312788
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


> -----Original Message-----
> From: Paul Smith [mailto:paul@pscs.co.uk] 
> Sent: Tuesday, February 19, 2002 2:31 PM

> Basically, if you send their server a 'UIDL' command it gives 
> you a set of IDs for the messages, then if you ask a few hours later, 
> it'll give you a totally different set of IDs for the same messages.
> As far as I am concerned this is a breach of the relevant bits of
> RFC 1939.

This is indeed bad - the UID for a message should not change.

> ... they say that their server does not add a UIDL AT 
> ALL to any messages on their servers, they are using, 
> instead, their own Unique Message ID [which does persist across
> sessions].

That's fine - there's nothing that says that the UID has to be stored
*on* the message, as long as the same UID is returned each time you ask.
If you're storing messages in a database, you might use the primary key
of the message in the DB as it's UID, for example.

> ... <they> blame BTWebworld [the domain-forwarding source of most of
my mail] 
> for ?somehow attaching changeable UIDL's which are confusing VPOP3
[our 
> mail software].

I have seen an X-UIDL header added to mail, which can lead to some real
problems - in particular, if a server accepts that as the UID of the
message, you can send it multiple different messages with the same
X-UIDL header and end up with multiple messages with the same UID on the
server.
 
> Is there anything I've missed, or is it just waffle from an ISP which 
> doesn't know what it's talking about?

It does sound like a waffle.  If they assign an invarient unique ID to
each message and return it as the UID of that message, then the UID of a
message should never change.  If they admit to the UID changing, then
they either (1) don't do what they say they do or (2) have a bug.
Besides, once a message is in their system how do they explain their
claim that the forwarder is somehow responsible for the changed UID?
*They* are now in control of the message!
 
-- jeff

From owner-ietf-pop3ext Tue Feb 19 15:52:17 2002
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g1JNqHF13101
	for ietf-pop3ext-bks; Tue, 19 Feb 2002 15:52:17 -0800 (PST)
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g1JNqG313097
	for <ietf-pop3ext@imc.org>; Tue, 19 Feb 2002 15:52:16 -0800 (PST)
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by numenor.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g1JNpqkQ000592;
	Tue, 19 Feb 2002 15:51:52 -0800 (PST)
Received: from LLUNDBLA2.qualcomm.com (llundbla2.qualcomm.com [129.46.154.11])
	by neophyte.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id g1JNpnu4022246;
	Tue, 19 Feb 2002 15:51:50 -0800 (PST)
Message-Id: <5.1.0.14.2.20020219154756.05300e58@jittlov.qualcomm.com>
X-Sender: llundbla@jittlov.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 19 Feb 2002 15:51:48 -0800
To: Paul Smith <paul@pscs.co.uk>, ietf-pop3ext@imc.org
From: Laurence Lundblade <lgl@Qualcomm.Com>
Subject: Re: Is there are replacement for 'UIDL'?
In-Reply-To: <5.1.0.14.2.20020219222323.08120e50@lmail.pscs.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


This Statement

>Basically, if you send their server a 'UIDL' command it gives you a set of 
>IDs for the messages, then if you ask a few hours later, it'll give you a 
>totally different set of IDs for the same messages. As far as I am 
>concerned this is a breach of the relevant bits of RFC 1939.

is contradictory with this

>  instead, their own Unique Message ID [which does persist across sessions].

which is it?


There's lots of POP servers that don't put any UIDL header into to the 
message header/body you get with a RETR and that's certainly OK. It would 
even be legal (but not nice) to add UIDL headers that have different or 
varying UIDL values than those returned by the UIDL command.

LL




From owner-ietf-pop3ext Wed Feb 20 02:31:53 2002
Received: by above.proper.com (8.11.6/8.11.3) id g1KAVr721772
	for ietf-pop3ext-bks; Wed, 20 Feb 2002 02:31:53 -0800 (PST)
Received: from marvin.nildram.co.uk (marvin.nildram.co.uk [195.112.4.71])
	by above.proper.com (8.11.6/8.11.3) with SMTP id g1KAVp321768
	for <ietf-pop3ext@imc.org>; Wed, 20 Feb 2002 02:31:51 -0800 (PST)
Received: (qmail 6266 invoked from network); 20 Feb 2002 10:31:51 -0000
Received: from unknown (HELO mail.pscs.co.uk) (195.149.15.3)
  by marvin.nildram.co.uk with SMTP; 20 Feb 2002 10:31:51 -0000
Received: from 192.168.57.101 by mail.pscs.co.uk ([192.168.59.3] running VPOP3) with ESMTP; Wed, 20 Feb 2002 10:20:17 -0000
Message-Id: <5.1.0.14.2.20020220102135.08f915b0@lmail.pscs.co.uk>
X-Sender: paul@lmail.pscs.co.uk
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 20 Feb 2002 10:22:23 +0000
To: "Jeff Stephenson" <jeffstep@EXCHANGE.MICROSOFT.com>,
   <ietf-pop3ext@imc.org>
From: Paul Smith <paul@pscs.co.uk>
Subject: RE: Is there are replacement for 'UIDL'?
In-Reply-To: <171E417EF48FB54BA3C238F08C3EEF065A6DC9@df-benji.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Server: VPOP3 Enterprise V1.5.1 - Registered
X-Organisation: Paul Smith Computer Services
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>



>It does sound like a waffle.  If they assign an invarient unique ID to
>each message and return it as the UID of that message, then the UID of a
>message should never change.  If they admit to the UID changing, then
>they either (1) don't do what they say they do or (2) have a bug.
>Besides, once a message is in their system how do they explain their
>claim that the forwarder is somehow responsible for the changed UID?
>*They* are now in control of the message!

Thanks for the confirmation. It confirms what I thought.


Paul				VPOP3 - Internet Email Server/Gateway
paul@pscs.co.uk			http://www.pscs.co.uk/



From owner-ietf-pop3ext Fri Oct 10 12:38:46 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AJckZA007035
	for <ietf-pop3ext-bks@above.proper.com>; Fri, 10 Oct 2003 12:38:46 -0700 (PDT)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9AJckvj007034
	for ietf-pop3ext-bks; Fri, 10 Oct 2003 12:38:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9AJciZA007028
	for <ietf-pop3ext@imc.org>; Fri, 10 Oct 2003 12:38:45 -0700 (PDT)
	(envelope-from dinaras@cnri.reston.va.us)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15732;
	Fri, 10 Oct 2003 15:38:36 -0400 (EDT)
Message-Id: <200310101938.PAA15732@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-pop3ext@imc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-siemborski-rfc1734bis-00.txt
Date: Fri, 10 Oct 2003 15:38:36 -0400
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: POP3 SASL Authentication Mechanism
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-rfc1734bis-00.txt
	Pages		: 11
	Date		: 2003-10-10
	
This document defines a profile of the Simple Authentication and
Security Layer (SASL) for the Post Office Protocol (POP3).	This
extension allows a POP3 client to indicate an authentication
mechanism to the server, perform an authentication protocol
exchange, and optionally negotiate a security layer for subsequent
protocol interactions during this session.

This document obsoletes RFC 1734 and replaces it as a Proposed
Standard.  It also updates information contained in Section 6.3 of
RFC 2449.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-rfc1734bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-siemborski-rfc1734bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-siemborski-rfc1734bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2003-10-10143206.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-siemborski-rfc1734bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-siemborski-rfc1734bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2003-10-10143206.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ietf-pop3ext Sun Oct 26 11:55:28 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtSI7031775
	for <ietf-pop3ext-bks@above.proper.com>; Sun, 26 Oct 2003 11:55:28 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9QJtSjN031774
	for ietf-pop3ext-bks; Sun, 26 Oct 2003 11:55:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9QJtGI7031748;
	Sun, 26 Oct 2003 11:55:17 -0800 (PST)
	(envelope-from paf@cisco.com)
Received: from cisco.com (144.254.74.60)
  by ams-iport-1.cisco.com with ESMTP; 26 Oct 2003 20:53:10 +0100
Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9QJt4l0006339;
	Sun, 26 Oct 2003 20:55:04 +0100 (MET)
Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 26 Oct 2003 20:55:11 +0100
Received: from [127.0.0.1] ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 26 Oct 2003 20:55:10 +0100
Mime-Version: 1.0 (Apple Message framework v606)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
Cc: Pete Resnick <presnick@Qualcomm.Com>, Ted Hardie <hardie@Qualcomm.Com>,
        Ned Freed <ned.freed@mrochek.com>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
Subject: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Sun, 26 Oct 2003 20:55:08 +0100
To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org
X-Mailer: Apple Mail (2.606)
X-OriginalArrivalTime: 26 Oct 2003 19:55:10.0612 (UTC) FILETIME=[101FC540:01C39BFB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9QJtII9031751
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


At the IETF in Minneapolis, there will be a BOF on Internationalized 
Email Addresses (IEA).

It is *preliminary* on the agenda on Monday, November 10, 2003 at 
1530-1730.

Chairs:  Pete Resnick, Patrik Fältström
Mailing list:imaa@imc.org (other salient lists include uri@w3.org)
Agenda:

Agenda Bashing (Chairs)                5 min.
Topic Introduction (Chairs)           10 min.
Proposals
   IDNA-Based (Paul Hoffman)           15 min.
   Infrastructure-Based (John Klensin) 15 min.
   IRI-Based (Michel Suignard)         15 min.

Discussion                            60 min.

Topics for discussion:

   Are there other solutions which have been specified?

   The solutions present the problem at different scopes;

      Where should the IETF tackle it?

      Are some short-term, and other long-term?

      Can the solutions be staged or co-exist?

      If staged, how to migrate from one to another?

   What are the next steps for the IETF?


NB:  This BoF is exploratory in nature, and it is not intended that the 
IETF will finalize a decision in this venue.  It was proposed to foster 
a community discussion, not charter a working group or pick a winner. 
If further work is required, step one would be identifying individuals 
willing to carry that work forward.

Reading material:
   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

Pete and myself hope people will come with a lot of constructive 
comments and ideas.

         Patrik, co-chair of the bof



From owner-ietf-pop3ext Mon Oct 27 07:44:52 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFiqI7056734
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 07:44:52 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RFiqO3056733
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 07:44:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from joy.songbird.com (joy.songbird.com [208.184.79.7])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFimI7056714;
	Mon, 27 Oct 2003 07:44:48 -0800 (PST)
	(envelope-from dcrocker@brandenburg.com)
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9RFokf29900;
	Mon, 27 Oct 2003 07:50:46 -0800
Date: Mon, 27 Oct 2003 07:41:11 -0800
From: Dave Crocker <dcrocker@brandenburg.com>
X-Mailer: The Bat! (v2.00.22)
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <12228881609.20031027074111@brandenburg.com>
To: =?ISO-8859-1?B?UGF0cmlrIEbkbHRzdHL2bQ==?= <paf@cisco.com>
CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, <lemonade@ietf.org>, <discuss@apps.ietf.org>,
        <ietf-imapext@imc.org>, <ietf-smtp@imc.org>,
        Pete Resnick <presnick@Qualcomm.Com>, Ted Hardie <hardie@Qualcomm.Com>,
        Ned Freed <ned.freed@mrochek.com>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Patrik,

Thanks for putting this BOF together.


PF>       Where should the IETF tackle it?

I am not sure I understand this question.  Please clarify.


PF>    What are the next steps for the IETF?

Would it help to have a draft charter for the meeting?  (I realize that the
presence of such different specifications makes a charter at least a bit
challenging, but it seems to help to have a draft, to make things concrete.)



d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>


From owner-ietf-pop3ext Mon Oct 27 07:53:55 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrsI7057227
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 07:53:54 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RFrshn057226
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 07:53:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RFrnI7057198;
	Mon, 27 Oct 2003 07:53:50 -0800 (PST)
	(envelope-from moore@cs.utk.edu)
Received: from localhost (klutz [127.0.0.1])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id 812AC14142; Mon, 27 Oct 2003 10:53:50 -0500 (EST)
Received: from klutz.cs.utk.edu ([127.0.0.1])
 by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 01580-02; Mon, 27 Oct 2003 10:53:49 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id 7D86C14094; Mon, 27 Oct 2003 10:53:49 -0500 (EST)
Date: Mon, 27 Oct 2003 10:52:22 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: moore@cs.utk.edu, paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org,
        ietf-822@imc.org, ietf@ietf.org, ietf-pop3ext@imc.org,
        lemonade@ietf.org, discuss@apps.ietf.org, ietf-imapext@imc.org,
        ietf-smtp@imc.org, presnick@Qualcomm.Com, hardie@Qualcomm.Com,
        ned.freed@mrochek.com
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Message-Id: <20031027105222.4eae54fd.moore@cs.utk.edu>
In-Reply-To: <12228881609.20031027074111@brandenburg.com>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
	<12228881609.20031027074111@brandenburg.com>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


> PF>    What are the next steps for the IETF?
> 
> Would it help to have a draft charter for the meeting?  

let's back up a step further.

what problem are we trying to solve here?

Keith

From owner-ietf-pop3ext Mon Oct 27 08:37:31 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbVI7060044
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 08:37:31 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RGbVEO060043
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 08:37:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RGbRI7060023;
	Mon, 27 Oct 2003 08:37:27 -0800 (PST)
	(envelope-from presnick@qualcomm.com)
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with
 ESMTP (Eudora Internet Mail Server X 3.2.3b1);
 Mon, 27 Oct 2003 10:37:25 -0600
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06100300bbc2f94105a7@[216.43.25.67]>
In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 <12228881609.20031027074111@brandenburg.com>
 <20031027105222.4eae54fd.moore@cs.utk.edu>
X-Mailer: Eudora [Macintosh version 6.1a2]
Date: Mon, 27 Oct 2003 10:37:21 -0600
To: Keith Moore <moore@cs.utk.edu>
From: Pete Resnick <presnick@Qualcomm.Com>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Cc: Dave Crocker <dcrocker@brandenburg.com>, moore@cs.utk.edu, paf@cisco.com,
        ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org, hardie@Qualcomm.Com,
        ned.freed@mrochek.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


On 10/27/03 at 10:52 AM -0500, Keith Moore wrote:

>>DC: Would it help to have a draft charter for the meeting?

As was mentioned in the draft agenda at 
<http://www.ietf.org/ietf/03nov/iea.txt>, we want to simply start the 
discussion, not immediately attempt to charter a working group.

>let's back up a step further.
>
>what problem are we trying to solve here?

Please have a look at draft-hoffman-imaa, 
draft-klensin-emailaddr-i18n, and draft-duerst-iri. Certainly the 
first two have very explicit descriptions of the problem.

pr
-- 
Pete Resnick <http://wwww.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From owner-ietf-pop3ext Mon Oct 27 09:01:54 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1sI7061186
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 09:01:54 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RH1sVh061185
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 09:01:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from panoramix.hexago.com ([209.71.226.3])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RH1oI7061125;
	Mon, 27 Oct 2003 09:01:50 -0800 (PST)
	(envelope-from Marc.Blanchet@viagenie.qc.ca)
Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22])
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9RH0M6r005886;
	Mon, 27 Oct 2003 12:00:22 -0500 (EST)
Date: Mon, 27 Oct 2003 12:00:01 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: Keith Moore <moore@cs.utk.edu>, Dave Crocker <dcrocker@brandenburg.com>
cc: paf@cisco.com, ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org,
        ietf@ietf.org, ietf-pop3ext@imc.org, lemonade@ietf.org,
        discuss@apps.ietf.org, ietf-imapext@imc.org, ietf-smtp@imc.org,
        presnick@Qualcomm.Com, hardie@Qualcomm.Com, ned.freed@mrochek.com
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Message-ID: <575390000.1067274001@classic.viagenie.qc.ca>
In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 	<12228881609.20031027074111@brandenburg.com>
 <20031027105222.4eae54fd.moore@cs.utk.edu>
X-Mailer: Mulberry/3.1.0b8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>




-- Monday, October 27, 2003 10:52:22 -0500 Keith Moore <moore@cs.utk.edu>
wrote/a ecrit:

>> PF>    What are the next steps for the IETF?
>> 
>> Would it help to have a draft charter for the meeting?  
> 
> let's back up a step further.
> 
> what problem are we trying to solve here?

to me, that (problem we are trying to solve) would be part of the
introduction in the charter...

so I guess some initial proposal for:
- what are we trying to solve
- what would be the way to solve it

would be a good starting point together with the "state-of-the-art"
presentations.

Marc.


> 
> Keith



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

From owner-ietf-pop3ext Mon Oct 27 09:13:55 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDsI7061690
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 09:13:54 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RHDswM061688
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 09:13:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHDpI7061670;
	Mon, 27 Oct 2003 09:13:51 -0800 (PST)
	(envelope-from mrc@CAC.Washington.EDU)
Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201])
	by mxout2.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDThu011833;
	Mon, 27 Oct 2003 09:13:30 -0800
Received: from localhost (mrc@localhost)
	by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RHDTew015664;
	Mon, 27 Oct 2003 09:13:29 -0800
Date: Mon, 27 Oct 2003 09:13:29 -0800 (PST)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Keith Moore <moore@cs.utk.edu>
cc: Dave Crocker <dcrocker@brandenburg.com>, paf@cisco.com, ietf-imaa@imc.org,
        idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@Qualcomm.Com,
        hardie@Qualcomm.Com, ned.freed@mrochek.com
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <20031027105222.4eae54fd.moore@cs.utk.edu>
Message-ID: <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


On Mon, 27 Oct 2003, Keith Moore wrote:
> what problem are we trying to solve here?

I agree with Keith.  This isn't to say that I dispute that there is a
problem to be solved -- indeed, I think that the problem is apparent to
all -- but we must have a problem statement that we all agree upon before
we even think about solutions.

I don't think that references to drafts of proposed solutions suffice as a
problem statement.  Leaving aside questions of possible bias (= present a
problem in such a way that this is the obvious best solution), having the
problem statement in a draft (which by its nature is an ephemeral
document) muddies the issues.

The problem statement should consist of a single paragraph (and preferably
in one or two sentences), separate from any proposed solution, and stated
in a charter which is approved by everyone.

Here's a start at such a statement:

As presently constituted, email addresses are limited to the 26 Latin
alphabetics, 10 digits, and a limited number of special characters in the
ASCII character set.  There is a growing need to use additional
characters, specifically Latin characters with diacriticals and non-Latin
characters, in email addresses to better serve the needs of the
multi-national Internet community.  However, the restrictions of ASCII
email addresses have served as a "lingua franca" since everybody can enter
ASCII email addresses, and there is an ongoing need for this as well.  The
problem to be solved is the resolution of these two needs.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From owner-ietf-pop3ext Mon Oct 27 09:30:56 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUuI7062579
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 09:30:56 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RHUurK062578
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 09:30:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mx.spindry.com (p1.spindry.com [64.5.41.83])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RHUsI7062559;
	Mon, 27 Oct 2003 09:30:54 -0800 (PST)
	(envelope-from bill-imc@carpenter.ORG)
Received: from filenet-gw.filenet.com ([198.3.8.1] helo=ATTABOY.carpenter.ORG)
	by mx.spindry.com with smtp (Exim 3.36 #2)
	id 1AEBCg-0005Z8-00; Mon, 27 Oct 2003 12:30:54 -0500
Date: Mon, 27 Oct 2003 09:30:46 -0800
Message-ID: <4027-Mon27Oct2003093046-0800-bill@carpenter.ORG>
X-Mailer: 21.1 (patch 9) "Canyonlands" XEmacs Lucid (via feedmail 11-beta-2 I) wjc loop;
	VM 6.71 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: bill-imc@carpenter.ORG (WJCarpenter)
To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
	<12228881609.20031027074111@brandenburg.com>
	<20031027105222.4eae54fd.moore@cs.utk.edu>
	<Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


mc> As presently constituted, email addresses are limited to the 26
mc> Latin alphabetics, 10 digits, and a limited number of special
mc> characters in the ASCII character set.  There is a growing need to

upper and lower case alphabetics
-- 
bill-imc@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3


From owner-ietf-pop3ext Mon Oct 27 10:45:40 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjeI7067931
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 10:45:40 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RIjej8067930
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 10:45:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RIjXI7067898;
	Mon, 27 Oct 2003 10:45:33 -0800 (PST)
	(envelope-from moore@cs.utk.edu)
Received: from localhost (klutz [127.0.0.1])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id 4F4301401D; Mon, 27 Oct 2003 13:45:34 -0500 (EST)
Received: from klutz.cs.utk.edu ([127.0.0.1])
 by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 25223-11; Mon, 27 Oct 2003 13:45:33 -0500 (EST)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by smtp.cs.utk.edu (Postfix) with ESMTP
	id 3AA6C13FEC; Mon, 27 Oct 2003 13:45:33 -0500 (EST)
Date: Mon, 27 Oct 2003 13:44:03 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Mark Crispin <mrc@CAC.Washington.EDU>
Cc: moore@cs.utk.edu, dcrocker@brandenburg.com, paf@cisco.com,
        ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@Qualcomm.Com,
        hardie@Qualcomm.Com, ned.freed@mrochek.com
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
Message-Id: <20031027134403.5eaaee9e.moore@cs.utk.edu>
In-Reply-To: <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
	<12228881609.20031027074111@brandenburg.com>
	<20031027105222.4eae54fd.moore@cs.utk.edu>
	<Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Mark,

Thanks for taking a stab at a problem statement.  I'd like to drill down
on this just a bit.

What is the source of the "growing need"?  Is it:

a. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to remember
b. for users of many languages (particularly those not using Latin alphabets)
   email addresses are difficult to transcribe or type
c. users want to use their names in email addresses
d. users are confused by apparently arbitrary restrictions on use of 
   characters in email addresses, and this leads to mistakes
e. on computer systems employing non-ASCII names for other purposes (e.g.
   login or account names) these do not map well to ASCII email addresses

or something else that I don't see?

> As presently constituted, email addresses are limited to the 26 Latin
> alphabetics, 10 digits, and a limited number of special characters in
> the ASCII character set.  There is a growing need to use additional
> characters, specifically Latin characters with diacriticals and
> non-Latin characters, in email addresses to better serve the needs of
> the multi-national Internet community.  However, the restrictions of
> ASCII email addresses have served as a "lingua franca" since everybody
> can enter ASCII email addresses, and there is an ongoing need for this
> as well.  The problem to be solved is the resolution of these two
> needs.

From owner-ietf-pop3ext Mon Oct 27 11:11:22 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBLI7069318
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 11:11:21 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RJBL7V069317
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 11:11:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.166])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RJBII7069299;
	Mon, 27 Oct 2003 11:11:18 -0800 (PST)
	(envelope-from mrc@CAC.Washington.EDU)
Received: from shiva1.cac.washington.edu (shiva1.cac.washington.edu [140.142.100.201])
	by mxout3.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtC2014056;
	Mon, 27 Oct 2003 11:10:56 -0800
Received: from localhost (mrc@localhost)
	by shiva1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9RJAtOx022764;
	Mon, 27 Oct 2003 11:10:55 -0800
Date: Mon, 27 Oct 2003 11:10:55 -0800 (PST)
From: Mark Crispin <mrc@CAC.Washington.EDU>
To: Keith Moore <moore@cs.utk.edu>
cc: dcrocker@brandenburg.com, paf@cisco.com, ietf-imaa@imc.org,
        idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org, presnick@Qualcomm.Com,
        hardie@Qualcomm.Com, ned.freed@mrochek.com
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <20031027134403.5eaaee9e.moore@cs.utk.edu>
Message-ID: <Pine.LNX.4.60.0310271059140.20831@shiva1.cac.washington.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 <12228881609.20031027074111@brandenburg.com> <20031027105222.4eae54fd.moore@cs.utk.edu>
 <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
 <20031027134403.5eaaee9e.moore@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


On Mon, 27 Oct 2003, Keith Moore wrote:
> Thanks for taking a stab at a problem statement.  I'd like to drill down
> on this just a bit.
> What is the source of the "growing need"?  Is it:
> [snip]

I agree that this needs to be stated, but someone other than me will have
to do it.

I believe that the primary push for this functionality comes from regions
which use Latin alphabetics with diacriticals; and that most individuals
in regions which do not use Latin script are accept the use of Latin
script for multinational interchange.  In many regions where Latin
diacriticals are used, there is no acceptable transform of a surname to a
form that does not use diacriticals.  Simply omitting the diacritical
causes (at least to the inhabitants of those regions) a misspelling.

This set of beliefs naturally biases how I approach the problem.  The
problem statement must be free of bias, including mine.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From owner-ietf-pop3ext Mon Oct 27 15:43:16 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNhGI7081092
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 15:43:16 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9RNhG43081088
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 15:43:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from sentosa.post1.com (sentosa.post1.com [202.27.17.100])
	by above.proper.com (8.12.10/8.12.8) with SMTP id h9RNh9I7081059
	for <ietf-pop3ext@imc.org>; Mon, 27 Oct 2003 15:43:12 -0800 (PST)
	(envelope-from jseng@pobox.org.sg)
Received: (qmail 5838 invoked from network); 28 Oct 2003 00:01:35 -0000
Received: from rifcd-04p117.ppp.odn.ad.jp (HELO pobox.org.sg) (211.3.24.117)
  by sentosa.post1.com with SMTP; 28 Oct 2003 00:01:35 -0000
Message-ID: <3F9CFC5D.7060509@pobox.org.sg>
Date: Mon, 27 Oct 2003 19:07:09 +0800
From: James Seng <jseng@pobox.org.sg>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en, zh-cn, zh-tw, ja, ko
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
CC: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org,
        Pete Resnick <presnick@Qualcomm.Com>, Ted Hardie <hardie@Qualcomm.Com>,
        Ned Freed <ned.freed@mrochek.com>
Subject: Re: [idn] FYI: BOF on Internationalized Email Addresses (IEA)
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
In-Reply-To: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


I seen John and Paul proposal but I have not seen Michel. Is there a 
draft that I can read up?

ps: I wont be able to join the meeting but I am interested in the subject.

-James Seng

Patrik Fältström wrote:

> At the IETF in Minneapolis, there will be a BOF on Internationalized 
> Email Addresses (IEA).
> 
> It is *preliminary* on the agenda on Monday, November 10, 2003 at 
> 1530-1730.
> 
> Chairs:  Pete Resnick, Patrik Fältström
> Mailing list:imaa@imc.org (other salient lists include uri@w3.org)
> Agenda:
> 
> Agenda Bashing (Chairs)                5 min.
> Topic Introduction (Chairs)           10 min.
> Proposals
>   IDNA-Based (Paul Hoffman)           15 min.
>   Infrastructure-Based (John Klensin) 15 min.
>   IRI-Based (Michel Suignard)         15 min.
> 
> Discussion                            60 min.
> 
> Topics for discussion:
> 
>   Are there other solutions which have been specified?
> 
>   The solutions present the problem at different scopes;
> 
>      Where should the IETF tackle it?
> 
>      Are some short-term, and other long-term?
> 
>      Can the solutions be staged or co-exist?
> 
>      If staged, how to migrate from one to another?
> 
>   What are the next steps for the IETF?
> 
> 
> NB:  This BoF is exploratory in nature, and it is not intended that the 
> IETF will finalize a decision in this venue.  It was proposed to foster 
> a community discussion, not charter a working group or pick a winner. If 
> further work is required, step one would be identifying individuals 
> willing to carry that work forward.
> 
> Reading material:
>   draft-hoffman-imaa-03.txt
>   draft-klensin-emailaddr-i18n-01.txt
>   draft-duerst-iri-04.txt
> 
> Pete and myself hope people will come with a lot of constructive 
> comments and ideas.
> 
>         Patrik, co-chair of the bof
> 
> 
> 
> 
> 



From owner-ietf-pop3ext Mon Oct 27 16:16:25 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0GOI7082405
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 16:16:24 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9S0GOpi082401
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 16:16:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from w1309.hostcentric.net (w1309.hostcentric.net [66.40.78.254])
	by above.proper.com (8.12.10/8.12.8) with SMTP id h9S0GKI7082375
	for <ietf-pop3ext@imc.org>; Mon, 27 Oct 2003 16:16:20 -0800 (PST)
	(envelope-from mark.davis@jtcsv.com)
Received: (qmail 22319 invoked by alias); 28 Oct 2003 00:16:21 -0000
Received: from unknown (HELO DAVIS1) (129.42.184.35)
  by 0 with SMTP; 28 Oct 2003 00:16:21 -0000
Message-ID: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1>
From: "Mark Davis" <mark.davis@jtcsv.com>
To: "Mark Crispin" <mrc@CAC.Washington.EDU>, "Keith Moore" <moore@cs.utk.edu>
Cc: <dcrocker@brandenburg.com>, <paf@cisco.com>, <ietf-imaa@imc.org>,
        <idn@ops.ietf.org>, <ietf-822@imc.org>, <ietf@ietf.org>,
        <ietf-pop3ext@imc.org>, <lemonade@ietf.org>, <discuss@apps.ietf.org>,
        <ietf-imapext@imc.org>, <ietf-smtp@imc.org>, <presnick@Qualcomm.Com>,
        <hardie@Qualcomm.Com>, <ned.freed@mrochek.com>
References: <E1AEH14-000N0E-GD@psg.com>
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Date: Mon, 27 Oct 2003 16:16:20 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


I'm curious: why do you think that everyone would be satisfied with Latin
characters only, and no non-Latin characters?

Mark
__________________________________
http://www.macchiato.com
â–ē ā¤ļā¤ŋā¤ˇāĨā¤¯ā¤žā¤Ļā¤ŋā¤šāĨā¤›āĨ‡ā¤¤āĨā¤Ēā¤°ā¤žā¤œā¤¯ā¤ŽāĨ ◄

----- Original Message ----- 
From: "Mark Crispin" <mrc@CAC.Washington.EDU>
To: "Keith Moore" <moore@cs.utk.edu>
Cc: <dcrocker@brandenburg.com>; <paf@cisco.com>; <ietf-imaa@imc.org>;
<idn@ops.ietf.org>; <ietf-822@imc.org>; <ietf@ietf.org>; <ietf-pop3ext@imc.org>;
<lemonade@ietf.org>; <discuss@apps.ietf.org>; <ietf-imapext@imc.org>;
<ietf-smtp@imc.org>; <presnick@qualcomm.com>; <hardie@qualcomm.com>;
<ned.freed@mrochek.com>
Sent: Mon, 2003 Oct 27 11:10
Subject: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)


> On Mon, 27 Oct 2003, Keith Moore wrote:
>
>  >> Thanks for taking a stab at a problem statement.  I'd like to drill down
>  >> on this just a bit.
>  >> What is the source of the "growing need"?  Is it:
>  >> [snip]
>
>
> I agree that this needs to be stated, but someone other than me will have
> to do it.
>
> I believe that the primary push for this functionality comes from regions
> which use Latin alphabetics with diacriticals; and that most individuals
> in regions which do not use Latin script are accept the use of Latin
> script for multinational interchange.  In many regions where Latin
> diacriticals are used, there is no acceptable transform of a surname to a
> form that does not use diacriticals.  Simply omitting the diacritical
> causes (at least to the inhabitants of those regions) a misspelling.
>
> This set of beliefs naturally biases how I approach the problem.  The
> problem statement must be free of bias, including mine.
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>
>
>
>
>
>
>
>


From owner-ietf-pop3ext Mon Oct 27 16:20:34 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KYI7082582
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 16:20:34 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9S0KYTc082580
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 16:20:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from joy.songbird.com (joy.songbird.com [208.184.79.7])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0KWI7082563;
	Mon, 27 Oct 2003 16:20:32 -0800 (PST)
	(envelope-from dhc@dcrocker.net)
Received: from bbprime (jay.songbird.com [208.184.79.253])
	by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h9S0Qaf09143;
	Mon, 27 Oct 2003 16:26:36 -0800
Date: Mon, 27 Oct 2003 16:19:25 -0800
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v2.00.22)
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <355752681.20031027161925@brandenburg.com>
To: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, <lemonade@ietf.org>, <discuss@apps.ietf.org>,
        <ietf-imapext@imc.org>, <ietf-smtp@imc.org>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 <12228881609.20031027074111@brandenburg.com>
 <20031027105222.4eae54fd.moore@cs.utk.edu>
 <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


Folks,

On the theory that discussions go better when they have a concrete
deliverable, here is a proposed charter for a proposed working group.

The following started with Mark Crispin's text, although it might not look it.
Besides the usual goals for a charter, the following text attempts to specify
the problem domain in the narrowest feasible form that is valid. If anyone
thinks the scope is too narrow, they need to explain why.



DRAFT CHARTER

Mail Internationalised Local-Part (MILP)
---------------------------------

The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821 mail
addresses are restricted to a subset of ASCII. This poses a fundamental
barrier for users needing mail addresses to be expressed in a richer set of
characters, such as Latin characters with diacriticals and the many Asian
characters. The goal of the current work is to add local-part support for
these additional characters, while preserving the large, installed base of
ASCII usage.

The group will take:

   draft-hoffman-imaa-03.txt
   draft-klensin-emailaddr-i18n-01.txt
   draft-duerst-iri-04.txt

as input to discussions.

The group will pay particular attention to barriers to adoption and utility,
as well as any impact the new scheme might have on the existing base of
Internet mail usage.


Milestones
----------

Nov, 03:  BOF

Dec, 03:  WG chartered

Feb, 03:  Initial draft of working group specifications.

Jun, 03:  Specifications submitted for IETF approval


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>


From owner-ietf-pop3ext Mon Oct 27 16:51:11 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pBI7083772
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 16:51:11 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9S0pBF3083771
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 16:51:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from willow.gnomon.org.uk (willow.gnomon.org.uk [69.10.132.76])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S0pAI7083766
	for <ietf-pop3ext@imc.org>; Mon, 27 Oct 2003 16:51:10 -0800 (PST)
	(envelope-from roy+dated+1069894267.41096d@gnomon.org.uk)
Received: from moriarty.gnomon.org.uk (cpc4-cmbg2-5-0-cust162.cmbg.cable.ntl.com [81.100.86.162])
	by willow.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0p9RX014086
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <ietf-pop3ext@imc.org>; Tue, 28 Oct 2003 00:51:12 GMT
Received: from moriarty.gnomon.org.uk (roy@localhost [127.0.0.1])
	by moriarty.gnomon.org.uk (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9S0p8Ze008689
	for <ietf-pop3ext@imc.org>; Tue, 28 Oct 2003 00:51:08 GMT
Received: by moriarty.gnomon.org.uk (tmda-sendmail, from uid 559);
	Tue, 28 Oct 2003 00:50:59 +0000 (GMT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16285.48493.496028.516294@moriarty.gnomon.org.uk>
Date: Tue, 28 Oct 2003 00:50:53 +0000
To: Dave Crocker <dcrocker@brandenburg.com>
Cc: ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, <lemonade@ietf.org>, <discuss@apps.ietf.org>,
        <ietf-imapext@imc.org>, <ietf-smtp@imc.org>
Subject: Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <355752681.20031027161925@brandenburg.com>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
	<12228881609.20031027074111@brandenburg.com>
	<20031027105222.4eae54fd.moore@cs.utk.edu>
	<Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
	<355752681.20031027161925@brandenburg.com>
X-Mailer: VM 7.03 under Emacs 20.7.2
From: Roy Badami <roy@gnomon.org.uk>
X-Delivery-Agent: TMDA/0.81 (Swaps)
X-Primary-Address: roy@gnomon.org.uk
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


 > Mail Internationalised Local-Part (MILP)

Even though, given IDNA now exists as a proposed standard, the main
issues relate to the local part, the issue under discussion is that of
internationalized mail addresses, not just internationalized
local-parts.

Restricting the disucssion to local-parts runs the risk of excluding
other potentially relevent issues.  For instance, one of the issues
that has been discussed on the IMAA list is whether full-width at
should be recognized in an internationalized mail address.  IMHO, the
charter shouldn't be framed in a way that is sufficiently narrow as to
render such questions out of scope.

	-roy


From owner-ietf-pop3ext Mon Oct 27 17:10:01 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1A1I7084635
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 17:10:01 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9S1A1ff084634
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 17:10:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from panoramix.hexago.com ([209.71.226.3])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S19rI7084577;
	Mon, 27 Oct 2003 17:09:58 -0800 (PST)
	(envelope-from Marc.Blanchet@viagenie.qc.ca)
Received: from localhost (retro.viagenie.qc.ca [IPv6:3ffe:b00:c18:3::22])
	(authenticated bits=0)
	by panoramix.hexago.com (8.12.8/8.12.8) with ESMTP id h9S18c6r006354;
	Mon, 27 Oct 2003 20:08:39 -0500 (EST)
Date: Mon, 27 Oct 2003 20:08:25 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: Dave Crocker <dcrocker@brandenburg.com>, ietf-imaa@imc.org,
        idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        ietf-imapext@imc.org, ietf-smtp@imc.org
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
Message-ID: <839550000.1067303305@classic.viagenie.qc.ca>
In-Reply-To: <355752681.20031027161925@brandenburg.com>
References: <4CD48AD0-07EE-11D8-9C47-000A959CF516@cisco.com>
 <12228881609.20031027074111@brandenburg.com>
 <20031027105222.4eae54fd.moore@cs.utk.edu>
 <Pine.LNX.4.60.0310270838030.13643@shiva1.cac.washington.edu>
 <355752681.20031027161925@brandenburg.com>
X-Mailer: Mulberry/3.1.0b8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


- good start!
- timeline seems pretty agressive... will see.
- would probably good to have a requirement document upfront. Might not the
same way that idn requirement ends up, but a narrow-implementable
requirement would help to have a concensus (hopefully) on what needs to be
done. 
- while the idn req went not that good, now that we have experience, I
think we should try to be better and have one.

I know I might start some debate with this, but still think it is the best
way to go...

- would be useful to have some reference to idn (idna) in the charter, as
background work. the developers and users will have to take care of "both"
(ie. idn and imail) in the email infrastructure.

Marc.

-- Monday, October 27, 2003 16:19:25 -0800 Dave Crocker <dhc@dcrocker.net>
wrote/a ecrit:

> Folks,
> 
> On the theory that discussions go better when they have a concrete
> deliverable, here is a proposed charter for a proposed working group.
> 
> The following started with Mark Crispin's text, although it might not
> look it. Besides the usual goals for a charter, the following text
> attempts to specify the problem domain in the narrowest feasible form
> that is valid. If anyone thinks the scope is too narrow, they need to
> explain why.
> 
> 
> 
> DRAFT CHARTER
> 
> Mail Internationalised Local-Part (MILP)
> ---------------------------------
> 
> The <local-part> portion of RFC2822 and <Local-part> portion of RFC2821
> mail addresses are restricted to a subset of ASCII. This poses a
> fundamental barrier for users needing mail addresses to be expressed in a
> richer set of characters, such as Latin characters with diacriticals and
> the many Asian characters. The goal of the current work is to add
> local-part support for these additional characters, while preserving the
> large, installed base of ASCII usage.
> 
> The group will take:
> 
>    draft-hoffman-imaa-03.txt
>    draft-klensin-emailaddr-i18n-01.txt
>    draft-duerst-iri-04.txt
> 
> as input to discussions.
> 
> The group will pay particular attention to barriers to adoption and
> utility, as well as any impact the new scheme might have on the existing
> base of Internet mail usage.
> 
> 
> Milestones
> ----------
> 
> Nov, 03:  BOF
> 
> Dec, 03:  WG chartered
> 
> Feb, 03:  Initial draft of working group specifications.
> 
> Jun, 03:  Specifications submitted for IETF approval
> 
> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 



------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

From owner-ietf-pop3ext Mon Oct 27 17:15:33 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FXI7084842
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 17:15:33 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.10/8.12.9/Submit) id h9S1FXpB084841
	for ietf-pop3ext-bks; Mon, 27 Oct 2003 17:15:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pop3ext@mail.imc.org using -f
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1FTI7084821;
	Mon, 27 Oct 2003 17:15:30 -0800 (PST)
	(envelope-from MRC@CAC.Washington.EDU)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139])
	by mxout1.cac.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1EwaZ010323;
	Mon, 27 Oct 2003 17:14:59 -0800
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
	(authenticated bits=0)
	by smtp.washington.edu (8.12.10+UW03.09/8.12.10+UW03.09) with ESMTP id h9S1Ewx0018732
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 27 Oct 2003 17:14:58 -0800
Date: Mon, 27 Oct 2003 17:15:00 -0800 (Pacific Standard Time)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Mark Davis <mark.davis@jtcsv.com>
cc: Keith Moore <moore@cs.utk.edu>, dcrocker@brandenburg.com, paf@cisco.com,
        ietf-imaa@imc.org, idn@ops.ietf.org, ietf-822@imc.org, ietf@ietf.org,
        ietf-pop3ext@imc.org, lemonade@ietf.org, discuss@apps.ietf.org,
        IMAP Extensions WG <ietf-imapext@imc.org>, ietf-smtp@imc.org,
        presnick@Qualcomm.Com, hardie@Qualcomm.Com, ned.freed@mrochek.com
Subject: Re: [idn] Re: FYI: BOF on Internationalized Email Addresses (IEA)
In-Reply-To: <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1>
Message-ID: <Pine.WNT.4.60.0310271656320.860@Tomobiki-Cho.CAC.Washington.EDU>
References: <E1AEH14-000N0E-GD@psg.com> <00fd01c39ce8$b6f19fe0$79d52b09@DAVIS1>
Organization: Networks & Distributed Computing
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pop3ext@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pop3ext/mail-archive/>
List-ID: <ietf-pop3ext.imc.org>
List-Unsubscribe: <mailto:ietf-pop3ext-request@imc.org?body=unsubscribe>


On Mon, 27 Oct 2003, Mark Davis wrote:
> I'm curious: why do you think that everyone would be satisfied with Latin
> characters only, and no non-Latin characters?

I didn't say that.  I stated my belief that, for reasons of practicality,
most individuals in regions which do not use Latin script accept the use
of Latin script for multinational exchange.

It does not work well for an individual in Japan with surname Tanaka to
expect the overwhelming majority of non-Japanese individuals worldwide to
know his surname is written with the Han characters for "rice paddy" and
"middle", or what those characters look like, or how to enter those
characters on the computer.

It does, however, work for him to expect that the overwhelming majority of
individuals worldwide to know how to deal with the 6 Latin letters that
form the romanization "Tanaka".

Nor is it very likely that this situation will change in the future.  I
doubt that many individuals in the world are literate in all the world's
active scripts.  Literacy in one's native script and basic Latin script is
something that most computer users possess today.

For domestic exchange only, that pair of Han characters are probably
alright.  Within Western Europe, it's probably alright to use Latin
characters with diacriticals.

Perhaps the main problem that needs to be decided in any IEA effort is if
it is alright to have email addresses that are only usable in limited
areas of the world; or if not, how to represent internationalized email
addresses in a usable fashion when (not if) the email address needs to be
represented for a person and/or computer is illiterate in that script.

A likely side issue is whether it is "good enough" to promote Latin
characters with diacriticals to the same status of "everybody must know
how to do these" that is required for ASCII.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

From owner-ietf-pop3ext Mon Oct 27 17:39:37 2003
Received: from above.proper.com (localhost [127.0.0.1])
	by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1dbI7085757
	for <ietf-pop3ext-bks@above.proper.com>; Mon, 27 Oct 2003 17:39:37 -0800 (PST)
	(envelope-from owner-ietf-pop3ext@mail.imc.org)
Received: (fr