Re: [Off Topic] Need review for POP3 extension mechanism

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.