Subject: Re: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism)
From: Randall Gellens <[email-masked]>
To: "Mike Gahrns" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>, "Randall Gellens" <[email-masked]>, <[email-masked]>
Date: Mon, 27 Jul 1998 14:40:15 -0700

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: "Mike Gahrns" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Randall Gellens" <[email-masked]>
Cc: <[email-masked]>
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
Sender: [email-masked]

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.

Date: Sat, 25 Jul 1998 01:25:08 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: Randall Gellens <[email-masked]>
CC: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Sat, 25 Jul 1998 01:25:44 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: Randall Gellens <[email-masked]>
CC: [email-masked]
Subject: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism)
Sender: [email-masked]

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: "Mike Gahrns" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>, "Randall Gellens" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Date: Thu, 23 Jul 1998 15:59:48 -0700
Sender: [email-masked]

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

Date: Thu, 23 Jul 1998 15:22:47 -0700
To: Chris Newman <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: EXPIRE
Cc: Lyndon Nerenberg <[email-masked]>, Randall Gellens <[email-masked]>, [email-masked], Mike Gahrns <[email-masked]>
Sender: [email-masked]

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.

Date: Thu, 23 Jul 1998 15:22:59 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Thu, 23 Jul 1998 15:02:25 -0700
To: Lyndon Nerenberg <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: EXPIRE
Cc: Randall Gellens <[email-masked]>, [email-masked], Mike Gahrns <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 24 Jul 1998 01:58:04 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Thu, 23 Jul 1998 14:17:53 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: EXPIRE
To: Lyndon Nerenberg <[email-masked]>
Cc: Randall Gellens <[email-masked]>, [email-masked], Mike Gahrns <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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: Lyndon Nerenberg <[email-masked]>
Date: Thu, 23 Jul 1998 13:46:39 -0600
To: Randall Gellens <[email-masked]>
Subject: EXPIRE
Cc: [email-masked], Mike Gahrns <[email-masked]>
Sender: [email-masked]

> 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

Date: Thu, 23 Jul 1998 11:52:14 -0700
To: "Mike Gahrns" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: <[email-masked]>
Sender: [email-masked]

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: "Mike Gahrns" <[email-masked]>
To: "Randall Gellens" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Date: Wed, 22 Jul 1998 20:46:55 -0700
Sender: [email-masked]

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

Date: Wed, 22 Jul 1998 12:08:00 -0700
To: "Mike Gahrns (Exchange)" <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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: "Mike Gahrns (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Tue, 21 Jul 1998 21:18:19 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, July 08, 1998 6:30 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Off Topic] Need review for POP3 extension mechanism

I apologize for an off-topic posting.  
Please send replies to [email-masked], 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:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, July 08, 1998 6:30 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; [email-masked]</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 [email-masked], 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--

Date: Mon, 20 Jul 1998 16:13:23 -0700
To: Chris Newman <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
Cc: Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

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.

Date: Fri, 17 Jul 1998 16:05:46 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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

Date: Sat, 18 Jul 1998 01:38:04 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Fri, 17 Jul 1998 10:54:31 -0700
To: Tony Hansen <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt?
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Fri, 17 Jul 1998 10:10:33 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
Subject: any comments on draft-hansen-pop3-xtndext-00.txt?
Sender: [email-masked]

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, [email-masked]

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

Date: Thu, 16 Jul 1998 18:06:19 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Thu, 16 Jul 1998 17:54:32 -0700
To: Laurence Lundblade <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: Randall Gellens <[email-masked]>, Steve Hole <[email-masked]>, [email-masked], John Gardiner Myers <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 16 Jul 1998 10:04:41 -0700
To: Randall Gellens <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: Steve Hole <[email-masked]>, [email-masked]
Sender: [email-masked]

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: Steve Hole <[email-masked]>
Date: Thu, 16 Jul 1998 08:04:25 -0600
To: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: [email-masked]
Sender: [email-masked]

Message-ID: <[email-masked]>
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 <[email-masked]> 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:[email-masked]  
Phone:403-424-4922

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

--Part9807160804.F--

To: [email-masked]
Date: Wed, 15 Jul 1998 21:21:32 -0400
From: Paul Hethmon <[email-masked]>
Reply-To: Paul Hethmon <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

** Reply to note from Keith Moore <[email-masked]> 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                                         [email-masked]
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 <[email-masked]>

Date: Wed, 15 Jul 1998 17:32:43 -0700
To: Steve Hole <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Mon, 13 Jul 1998 15:09:37 -0700
To: Jacob Palme <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension  mechanism
Cc: [email-masked], IETF mail extensions mailing list <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 13 Jul 1998 15:17:04 -0700
To: [email-masked], Keith Moore <[email-masked]>
From: Laurence Lundblade <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Mon, 13 Jul 1998 09:52:32 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
To: Jacob Palme <[email-masked]>
Cc: [email-masked], IETF mail extensions mailing list <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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

Date: Mon, 13 Jul 1998 18:58:16 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: Randall Gellens <[email-masked]>
CC: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Sun, 12 Jul 1998 11:35:46 +0200
To: [email-masked], IETF mail extensions mailing list <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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 [email-masked], so please
copy any replies to this message, which I should see,
either to me personally or to the [email-masked]
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 <[email-masked]> (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

Date: Fri, 10 Jul 1998 16:29:02 -0700
To: Alexey Melnikov <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Sat, 11 Jul 1998 02:27:16 +0400
From: Alexey Melnikov <[email-masked]>
Organization: Epsylon Technologies
To: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Keith Moore wrote:

> I apologize for an off-topic posting.
> Please send replies to [email-masked], 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 :-))

Date: Fri, 10 Jul 1998 12:57:26 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
To: Steve Hole <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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: Steve Hole <[email-masked]>
Date: Fri, 10 Jul 1998 08:37:05 -0600
To: [email-masked]
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

On Wed, 08 Jul 1998 21:30:01 -0400 Keith Moore <[email-masked]> 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:[email-masked]  
Phone:403-424-4922

Date: Fri, 10 Jul 1998 23:05:10 +1200
To: [email-masked]
From: Glenn Anderson <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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

Date: Thu, 9 Jul 1998 14:38:50 -0700
To: [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
Sender: [email-masked]

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: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked]
Subject: RE: [Off Topic] Need review for POP3 extension mechanism
Date: Thu, 9 Jul 1998 14:24:39 -0500 
Sender: [email-masked]

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:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Wednesday, July 08, 1998 8:30 PM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]; [email-masked]
> Subject: 	[Off Topic] Need review for POP3 extension mechanism
> 
> I apologize for an off-topic posting.  
> Please send replies to [email-masked], 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
> 

Date: Thu, 09 Jul 1998 09:27:08 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
To: [email-masked]
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

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

To: [email-masked], [email-masked]
Subject: [Off Topic] Need review for POP3 extension mechanism
cc: [email-masked], [email-masked]
From: Keith Moore <[email-masked]>
Reply-To: [email-masked]
Date: Wed, 08 Jul 1998 21:30:01 -0400
Sender: [email-masked]

I apologize for an off-topic posting.  
Please send replies to [email-masked], 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