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

From: "Mike Gahrns (Exchange)" <[email-masked]>
Date: Tue, 21 Jul 1998 21:18:19 -0700

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 Jul 1998 12:08:00 -0700

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

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