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

[Randall Gellens <[e-mail]>]

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