From adm Mon May 18 07:22:58 1998 Delivery-Date: Mon, 18 May 1998 07:31:22 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id HAA20829 for ietf-123-outbound.10@ietf.org; Mon, 18 May 1998 07:15:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA20784; Mon, 18 May 1998 07:11:37 -0400 (EDT) Message-Id: <199805181111.HAA20784@ietf.org> To: IETF-Announce: ; Cc: ietf-pop3ext@imr.org From: The IESG SUBJECT: Last Call: POP3 Extension Mechanism to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 18 May 1998 07:11:37 -0400 Sender: scoya@CNRI.RESTON.VA.US The IESG has received a request to consider POP3 Extension Mechanism as a Proposed Standard. This has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 18, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-gellens-pop3ext-05.txt From owner-ietf-smtp@imc.org Wed Jul 22 00:32:02 1998 Delivery-Date: Wed, 22 Jul 1998 00:32:02 -0400 Return-Path: owner-ietf-smtp@imc.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA12424 for ; Wed, 22 Jul 1998 00:32:01 -0400 (EDT) Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA03231; Wed, 22 Jul 1998 00:31:53 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA11183 for ietf-smtp-bks; Tue, 21 Jul 1998 21:17:59 -0700 (PDT) Received: from yuri.exchange.microsoft.com (yuri.exchange.microsoft.com [131.107.88.54]) by mail.proper.com (8.8.8/8.8.5) with SMTP id VAA11171; Tue, 21 Jul 1998 21:17:49 -0700 (PDT) Received: by yuri.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 21 Jul 1998 21:18:24 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010B37E591@DINO> From: "Mike Gahrns (Exchange)" To: "'ietf-pop3ext@imc.org'" , drums@cs.utk.edu, ietf-smtp@imc.org Subject: RE: [Off Topic] Need review for POP3 extension mechanism Date: Tue, 21 Jul 1998 21:18:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDB527.C46A0970" Sender: owner-ietf-smtp@imc.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BDB527.C46A0970 Content-Type: text/plain; charset="iso-8859-1" I apologize for such a late response, but i have been out of the office for the last few weeks. I agree with the others who view this as being a useful draft, and second the motion that it should go as proposed instead of informational or experimental. Although the list has not had a lot of dicussion on it, I know Randy has been discussing this with various people at venues like the ietf, so it has been getting review. My biggest concern was the former LMOS setting allowed for expiration settings to be based on the command used to acccess the msg, which Randy has addressed with the new EXPIRE setting. I do have one minor concern regarding the current wording of the EXPIRE setting. The draft states: "If the expiration policy might differ per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in the AUTHENTICATION state the smallest value which might be used. The server should announce the more accurate value in the TRANSACTION state. It is unclear to me whether the intent of this is to force the server to keep track of the smallest setting a user currently has set, or if it is for the server to annouce the smallest value that an administrator could conceivably set for a particular user. If the intent is the former, than this will be problematic for servers that are not tightly coupled with their directory, as it effectively forces the server to scan a list of all user settings at each log on time. I'll talk to Randy to get clarification, and perhaps come up with some clarification wording in regards to this. Another minor nit is the wording: "If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks." I'd like to see the wording changed to something like: "The client SHOULD reissue the CAPA command after authenticating to check for active down-negotiation attacks and to get any per user capability settings." -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Wednesday, July 08, 1998 6:30 PM To: drums@cs.utk.edu; ietf-smtp@imc.org Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org Subject: [Off Topic] Need review for POP3 extension mechanism I apologize for an off-topic posting. Please send replies to ietf-pop3ext@imc.org, not to the drums or ietf-smtp lists. On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt , for Proposed Standard status. Nobody has commented on the document. I am reluctant to recommend that IESG approve this document without more evidence of support. So I'm asking for more review... Should the document be adopted as is? Does it need more wordsmithing? Are all of these capabilities needed? Are all of the capabilities defined with sufficient precision? Should the document be standards track or should it be Informational or Experimental? Should the extension mechanism be separated from (and perhaps a different status from) the extensions themselves? If the document is approved for Proposed, should all of the proposed extensions be included? Or should some of the extensions be moved to a separate Informational or Experimental? Which ones? In the absence of more community input, my recommendation would be to direct the authors to remove all of the capabilities from this document, except those which are already defined in standards-track documents. Additional capabilities could be defined in a separate experimental or informational RFC. thanks! Keith Moore APPS co-AD ------_=_NextPart_001_01BDB527.C46A0970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Off Topic] Need review for POP3 extension mechanism

I apologize for such a late response, but i have been = out of the office for the last few weeks.

I agree with the others who view this as being a = useful draft, and second the motion that it should go as proposed = instead of informational or experimental.

Although the list has not had a lot of dicussion on = it, I know Randy has been discussing this with various people at venues = like the ietf, so it has been getting review.  My biggest concern = was the former LMOS setting allowed for expiration settings to be based = on the command used to acccess the msg, which Randy has addressed with = the new EXPIRE setting.

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

The draft states:
"If the expiration policy might differ per user = (that is, the EXPIRE argument might change after authentication), the = server MUST announce in the AUTHENTICATION state the smallest value = which might be used.  The server should announce the more accurate = value in the TRANSACTION state.

It is unclear to me whether the intent of this is to = force the server to keep track of the smallest setting a user currently = has set, or if it is for the server to annouce the smallest value that = an administrator could conceivably set for a particular user.  If = the intent is the former, than this will be problematic for servers = that are not tightly coupled with their directory, as it effectively = forces the server to scan a list of all user settings at each log on = time.

I'll talk to Randy to get clarification, and perhaps = come up with some clarification wording in regards to this.

Another minor nit is the wording:
"If the authentication step negotiates an = integrity protection layer, the client SHOULD reissue the CAPA command = after authenticating to check for active down-negotiation = attacks."

I'd like to see the wording changed to something = like:
"The client SHOULD reissue the CAPA command = after authenticating to check for active down-negotiation attacks and = to get any per user capability settings."



-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Wednesday, July 08, 1998 6:30 PM
To: drums@cs.utk.edu; ietf-smtp@imc.org
Cc: moore@cs.utk.edu; ietf-pop3ext@imc.org
Subject: [Off Topic] Need review for POP3 extension = mechanism


I apologize for an off-topic posting. 
Please send replies to ietf-pop3ext@imc.org, not to = the drums or ietf-smtp lists.

On May 18, a Last Call was issued on for document = draft-gellens-pop3ext-05.txt ,
for Proposed Standard status.  Nobody has = commented on the document.  I am
reluctant to recommend that IESG approve this = document without more evidence
of support.

So I'm asking for more review...

Should the document be adopted as is?  Does it = need more wordsmithing?
Are all of these capabilities needed?
Are all of the capabilities defined with sufficient = precision?

Should the document be standards track or should it = be Informational or
Experimental?

Should the extension mechanism be separated from (and = perhaps a different
status from) the extensions themselves?

If the document is approved for Proposed, should all = of the proposed extensions
be included?  Or should some of the extensions = be moved to a separate
Informational or Experimental?   Which = ones?

In the absence of more community input, my = recommendation would be to direct
the authors to remove all of the capabilities from = this document, except those
which are already defined in standards-track = documents.  Additional capabilities
could be defined in a separate experimental or = informational RFC.

thanks!

Keith Moore
APPS co-AD

------_=_NextPart_001_01BDB527.C46A0970-- From owner-ietf-smtp@imc.org Wed Jul 22 15:22:30 1998 Delivery-Date: Wed, 22 Jul 1998 15:22:30 -0400 Return-Path: owner-ietf-smtp@imc.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA18083 for ; Wed, 22 Jul 1998 15:22:29 -0400 (EDT) Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA07063; Wed, 22 Jul 1998 15:22:20 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA27456 for ietf-smtp-bks; Wed, 22 Jul 1998 12:11:44 -0700 (PDT) Received: from odd.qualcomm.com (odd.qualcomm.com [129.46.2.48]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA27452; Wed, 22 Jul 1998 12:11:42 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by odd.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id MAA20867; Wed, 22 Jul 1998 12:12:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2FBF98FC7852CF11912A0000000000010B37E591@DINO> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Wed, 22 Jul 1998 12:08:00 -0700 To: "Mike Gahrns (Exchange)" From: Randall Gellens Subject: RE: [Off Topic] Need review for POP3 extension mechanism Cc: "'ietf-pop3ext@imc.org'" , drums@cs.utk.edu, ietf-smtp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-smtp@imc.org Precedence: bulk At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote: >I do have one minor concern regarding the current wording of the >EXPIRE setting. > >The draft states: >"If the expiration policy might differ per user (that is, the EXPIRE >argument might change after authentication), the server MUST announce >in the AUTHENTICATION state the smallest value which might be used. >The server should announce the more accurate value in the TRANSACTION >state. > >It is unclear to me whether the intent of this is to force the server >to keep track of the smallest setting a user currently has set, or if >it is for the server to annouce the smallest value that an >administrator could conceivably set for a particular user. If the >intent is the former, than this will be problematic for servers that >are not tightly coupled with their directory, as it effectively forces >the server to scan a list of all user settings at each log on time. The intent is to let the client know that the server does permit mail to be left on the server, and to present a value which is the smallest which might be set for the user. This could be the smallest value currently in use for any user (so only one value per server), or even the smallest value which the server permits to be set for any user. This way a client can decide (because the user has told the client to leave mail on the server for a larger number of days) if it needs to reissue CAPA after authenticating and/or warn the user. >Another minor nit is the wording: >"If the authentication step negotiates an integrity protection layer, >the client SHOULD reissue the CAPA command after authenticating to >check for active down-negotiation attacks." > >I'd like to see the wording changed to something like: >"The client SHOULD reissue the CAPA command after authenticating to >check for active down-negotiation attacks and to get any per user >capability settings." The intent is to not require clients to issue two CAPA commands. The client pretty much has to issue one before authenticating, to learn which SASL mechanisms are supported, but doesn't have to issue on afterwards, unless the first CAPA reveals that the server supports some capabilities whose parameters might change after authentication, and the client needs the most accurate values (it might be able to use the more general ones), or the client wants to check for down-negotiation attacks. A simple client that only uses a few basic SASL mechanisms, for example, and only needs to know if the server supports TOP, UIDL, and allows mail to be left on the server, doesn't need to issue two CAPAs. (A client which only uses plaintext or APOP could issue only one CAPA, after authenticating.) From owner-ietf-smtp@imc.org Wed Jul 22 23:52:11 1998 Delivery-Date: Wed, 22 Jul 1998 23:52:12 -0400 Return-Path: owner-ietf-smtp@imc.org Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA29454 for ; Wed, 22 Jul 1998 23:52:11 -0400 (EDT) Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA09359; Wed, 22 Jul 1998 23:52:02 -0400 (EDT) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00846 for ietf-smtp-bks; Wed, 22 Jul 1998 20:42:57 -0700 (PDT) Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00842; Wed, 22 Jul 1998 20:42:55 -0700 (PDT) Received: by tide03.microsoft.com; id UAA17039; Wed, 22 Jul 1998 20:43:45 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma017036; Wed, 22 Jul 98 20:43:44 -0700 Received: from red-01-imc.dns.microsoft.com ([157.54.1.197]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id UAA28977; Wed, 22 Jul 1998 20:53:56 -0700 (PDT) Received: from popdog.exchange.microsoft.com (POPDOG [172.30.236.242]) by red-01-imc.dns.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id PKF6X2L1; Wed, 22 Jul 1998 20:43:44 -0700 Received: from mikega9 (mikega9.dns.microsoft.com [157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 37DWQA4C; Wed, 22 Jul 1998 20:43:49 -0700 Message-ID: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com> From: "Mike Gahrns" To: "Randall Gellens" Cc: , , Subject: Re: [Off Topic] Need review for POP3 extension mechanism Date: Wed, 22 Jul 1998 20:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-smtp@imc.org Precedence: bulk *** within >At 9:18 PM -0700 7/21/98, Mike Gahrns (Exchange) wrote: > >>I do have one minor concern regarding the current wording of the >>EXPIRE setting. >> >>The draft states: >>"If the expiration policy might differ per user (that is, the EXPIRE >>argument might change after authentication), the server MUST announce >>in the AUTHENTICATION state the smallest value which might be used. >>The server should announce the more accurate value in the TRANSACTION >>state. >> >>It is unclear to me whether the intent of this is to force the server >>to keep track of the smallest setting a user currently has set, or if >>it is for the server to annouce the smallest value that an >>administrator could conceivably set for a particular user. If the >>intent is the former, than this will be problematic for servers that >>are not tightly coupled with their directory, as it effectively forces >>the server to scan a list of all user settings at each log on time. > >The intent is to let the client know that the server does permit mail >to be left on the server, and to present a value which is the smallest >which might be set for the user. This could be the smallest value >currently in use for any user (so only one value per server), or even >the smallest value which the server permits to be set for any user. *** If it is the smallest value which the server permits to be set for any user, I am happy with it. Would it be possible for you to update the draft with the above paragraph? If I had the question, I am sure others will... The more precise we are now with things, will save us interoperability grief later and it really is just a minor clarification so we won't need to worry about another last call. (The smallest value currently in use by any user on a server is problematic for us, but we do not have any objections if other servers want to present this value if they can easily calculate it) This should not pose any interop problems either. Basically, if a client wants to get the accurate setting, they need to re-issue the CAPA command after authenticating, so i do not really think it matters too much what was presented in the unauthenticated state. Having said that, perhaps a better solution would be to define another arguement called "USER". If a client does a CAPA and gets an EXPIRE USER, in the unauthenticated state, it knows that the server supports per user expiry settings. It explicitly informs the user when they need to re-issue the CAPA command after authentication due to per user options. >This way a client can decide (because the user has told the client to >leave mail on the server for a larger number of days) if it needs to >reissue CAPA after authenticating and/or warn the user. *** this is assuming that the client ui has something that allows the user to specify the number of days to leave mail on the server. I believe some clients just have a "leave mail on server" option. In this case, I guess the client will always need to reissue the CAPA command after authentication. The interop problem I see is the following: The client is running against a server where expiry is set on a per user setting. Let's say the server allows the admin to specify per user expiry settings. For the client that is logged on, the per user expiry is set to 30. However, on the server he is running against, there is a user who has expiry set to 15. Or it is a server, where the lowest expiry setting is not available, so the server reports what the theoretical minimum it can be set to, lets say 1. Unless things are spelled out explicitly within your draft, I can see a client issueing only a single CAPA before authentication. Without it doing another CAPA after authentication, the client would be spitting out bogus warnings for the user saying "your messages will be deleted from the server after 15 days" when really the setting is for 30 days. Being really explicit in the draft will ensure that client writers don't make that mistake. > > >>Another minor nit is the wording: >>"If the authentication step negotiates an integrity protection layer, >>the client SHOULD reissue the CAPA command after authenticating to >>check for active down-negotiation attacks." >> >>I'd like to see the wording changed to something like: >>"The client SHOULD reissue the CAPA command after authenticating to >>check for active down-negotiation attacks and to get any per user >>capability settings." > >The intent is to not require clients to issue two CAPA commands. The >client pretty much has to issue one before authenticating, to learn >which SASL mechanisms are supported, but doesn't have to issue on >afterwards, unless the first CAPA reveals that the server supports some >capabilities whose parameters might change after authentication, and >the client needs the most accurate values (it might be able to use the >more general ones), or the client wants to check for down-negotiation >attacks. *** Agreed. The point I was making is that it does not hurt to call out in the doc the need to recheck parameters that might change after authentication. The wording you have only mentions down negotiation attacks. A simple client that only uses a few basic SASL mechanisms, >for example, and only needs to know if the server supports TOP, UIDL, >and allows mail to be left on the server, doesn't need to issue two >CAPAs. (A client which only uses plaintext or APOP could issue only >one CAPA, after authenticating.) Agreed. And perhaps this adds more fuel to returning USER when there are per user settings.