Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA06243 for ietf-pop3ext-bks; Mon, 27 Jul 1998 14:42:44 -0700 (PDT) Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA06239 for ; Mon, 27 Jul 1998 14:42:42 -0700 (PDT) Received: from [129.46.219.133] (randy-mac.qualcomm.com [129.46.219.133]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA13670; Mon, 27 Jul 1998 14:43:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000901bdb74c$c62df4e0$8dff3b9d@mikega9.dns.microsoft.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Mon, 27 Jul 1998 14:40:15 -0700 To: "Mike Gahrns" From: Randall Gellens Subject: Re: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism) Cc: "Alexey Melnikov" , "Randall Gellens" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14524 for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:44: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 OAA14520 for ; Fri, 24 Jul 1998 14:44:56 -0700 (PDT) Received: by tide03.microsoft.com; id OAA05130; Fri, 24 Jul 1998 14:45:46 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma005126; Fri, 24 Jul 98 14:45:22 -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 OAA08398; Fri, 24 Jul 1998 14:55:35 -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 PKF6715M; Fri, 24 Jul 1998 14:45:22 -0700 Received: from MIKEGA9 ([157.59.255.141]) by popdog.exchange.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 37DWQYV1; Fri, 24 Jul 1998 14:45:34 -0700 Message-ID: <000901bdb74c$c62df4e0$8dff3b9d@mikega9.dns.microsoft.com> From: "Mike Gahrns" To: "Alexey Melnikov" , "Randall Gellens" Cc: 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 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" 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-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14437 for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:27:39 -0700 (PDT) Received: from dragon (ppp1663.glas.apc.org [195.218.251.151]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14430 for ; Fri, 24 Jul 1998 14:27:33 -0700 (PDT) Received: FROM demo.ru ([195.218.251.151]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 25 Jul 1998 01:25:10 +0300 Message-ID: <35B8FBB4.2435CCAE@demo.ru> Date: Sat, 25 Jul 1998 01:25:08 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Randall Gellens CC: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA14429 for ietf-pop3ext-bks; Fri, 24 Jul 1998 14:27:33 -0700 (PDT) Received: from dragon (ppp1663.glas.apc.org [195.218.251.151]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA14425 for ; Fri, 24 Jul 1998 14:27:28 -0700 (PDT) Received: FROM demo.ru ([195.218.251.151]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 25 Jul 1998 01:25:44 +0300 Message-ID: <35B8FBD8.656D4763@demo.ru> Date: Sat, 25 Jul 1998 01:25:44 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Randall Gellens CC: ietf-pop3ext@imc.org Subject: Lost mail with EXPIRE 0 (was Re: [Off Topic] Need review for POP3 extension mechanism) References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18337 for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:56:20 -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 PAA18333 for ; Thu, 23 Jul 1998 15:56:19 -0700 (PDT) Received: by tide03.microsoft.com; id PAA12595; Thu, 23 Jul 1998 15:56:52 -0700 (PDT) Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma012588; Thu, 23 Jul 98 15:56:41 -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 QAA19620; Thu, 23 Jul 1998 16:06:53 -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 PKF6X7S1; Thu, 23 Jul 1998 15:56:42 -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 37DWQLZL; Thu, 23 Jul 1998 15:56:44 -0700 Message-ID: <000801bdb68d$97814f80$8dff3b9d@mikega9.dns.microsoft.com> From: "Mike Gahrns" To: "Alexey Melnikov" , "Randall Gellens" Cc: Subject: Re: [Off Topic] Need review for POP3 extension mechanism Date: Thu, 23 Jul 1998 15:59:48 -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-pop3ext@imc.org Precedence: bulk *** 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18186 for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:30:38 -0700 (PDT) Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18182 for ; Thu, 23 Jul 1998 15:30:36 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA16827; Thu, 23 Jul 1998 15:29:18 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 23 Jul 1998 15:22:47 -0700 To: Chris Newman From: Randall Gellens Subject: Re: EXPIRE Cc: Lyndon Nerenberg , Randall Gellens , ietf-pop3ext@imc.org, Mike Gahrns Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18167 for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:29:47 -0700 (PDT) Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18163 for ; Thu, 23 Jul 1998 15:29:43 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA16800; Thu, 23 Jul 1998 15:29:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <35B7B1EC.448882AC@demo.ru> References: X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 23 Jul 1998 15:22:59 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA18055 for ietf-pop3ext-bks; Thu, 23 Jul 1998 15:14:08 -0700 (PDT) Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA18051 for ; Thu, 23 Jul 1998 15:14:07 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA02304; Thu, 23 Jul 1998 15:14:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 23 Jul 1998 15:02:25 -0700 To: Lyndon Nerenberg From: Randall Gellens Subject: Re: EXPIRE Cc: Randall Gellens , ietf-pop3ext@imc.org, Mike Gahrns Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17976 for ietf-pop3ext-bks; Thu, 23 Jul 1998 14:55:53 -0700 (PDT) Received: from dragon (ppp1666.glas.apc.org [195.218.251.154]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17972 for ; Thu, 23 Jul 1998 14:55:47 -0700 (PDT) Received: FROM demo.ru ([195.218.251.154]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 24 Jul 1998 01:58:05 +0300 Message-ID: <35B7B1EC.448882AC@demo.ru> Date: Fri, 24 Jul 1998 01:58:04 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA17800 for ietf-pop3ext-bks; Thu, 23 Jul 1998 14:16:34 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA17796 for ; Thu, 23 Jul 1998 14:16:31 -0700 (PDT) Received: from elwood.innosoft.com ("port 56195"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-11 #U3049) with SMTP id <01IZQR86OEPM99E6S3@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu, 23 Jul 1998 14:16:41 PDT Date: Thu, 23 Jul 1998 14:17:53 -0700 (PDT) From: Chris Newman Subject: Re: EXPIRE In-reply-to: To: Lyndon Nerenberg Cc: Randall Gellens , ietf-pop3ext@imc.org, Mike Gahrns Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17240 for ietf-pop3ext-bks; Thu, 23 Jul 1998 12:45:46 -0700 (PDT) Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA17236 for ; Thu, 23 Jul 1998 12:45:45 -0700 (PDT) Received: from warhol.esys.ca (warhol.esys.ca [198.161.92.20]) by rembrandt.esys.ca (2.0.4-beta-1/SMS 2.0.4-beta-1) with ESMTP id NAA07539; Thu, 23 Jul 1998 13:46:40 -0600 From: Lyndon Nerenberg Date: Thu, 23 Jul 1998 13:46:39 -0600 To: Randall Gellens Subject: EXPIRE Cc: ietf-pop3ext@imc.org, Mike Gahrns In-Reply-To: References: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com> Message-ID: X-Mailer: Simeon for Aix Motif Version Mercury a8 Build (11) MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-pop3ext@imc.org Precedence: bulk > 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA17031 for ietf-pop3ext-bks; Thu, 23 Jul 1998 12:01:22 -0700 (PDT) Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA17006 for ; Thu, 23 Jul 1998 11:58:51 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by apprentice.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id LAA20346; Thu, 23 Jul 1998 11:59:17 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <000501bdb5ec$89900bb0$8dff3b9d@mikega9.dns.microsoft.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 23 Jul 1998 11:52:14 -0700 To: "Mike Gahrns" From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00852 for ietf-pop3ext-bks; Wed, 22 Jul 1998 20:43:20 -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-pop3ext@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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA27464 for ietf-pop3ext-bks; Wed, 22 Jul 1998 12:12:11 -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-pop3ext@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.) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA11175 for ietf-pop3ext-bks; Tue, 21 Jul 1998 21:17:50 -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-pop3ext@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-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18415 for ietf-pop3ext-bks; Mon, 20 Jul 1998 16:18:18 -0700 (PDT) Received: from mysa.qualcomm.com (mysa.qualcomm.com [129.46.52.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA18411 for ; Mon, 20 Jul 1998 16:18:15 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by mysa.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA03713; Mon, 20 Jul 1998 16:17:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <35AF5B59.20984366@att.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Mon, 20 Jul 1998 16:13:23 -0700 To: Chris Newman From: Randall Gellens Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt? Cc: Tony Hansen , ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA04823 for ietf-pop3ext-bks; Fri, 17 Jul 1998 16:04:53 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA04819 for ; Fri, 17 Jul 1998 16:04:52 -0700 (PDT) Received: from elwood.innosoft.com ("port 46160"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-11 #U3049) with SMTP id <01IZIH8TEWF699E0HA@INNOSOFT.COM> for ietf-pop3ext@imc.org; Fri, 17 Jul 1998 16:04:32 PDT Date: Fri, 17 Jul 1998 16:05:46 -0700 (PDT) From: Chris Newman Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt? In-reply-to: <35AF5B59.20984366@att.com> To: Tony Hansen Cc: ietf-pop3ext@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04214 for ietf-pop3ext-bks; Fri, 17 Jul 1998 14:37:19 -0700 (PDT) Received: from dragon (ppp1166.glas.apc.org [194.154.81.112]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA04210 for ; Fri, 17 Jul 1998 14:37:15 -0700 (PDT) Received: FROM demo.ru ([194.154.81.112]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 18 Jul 1998 01:38:04 +0300 Message-ID: <35AFC43C.28A91CAA@demo.ru> Date: Sat, 18 Jul 1998 01:38:04 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism References: <199807090130.VAA28119@spot.cs.utk.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02691 for ietf-pop3ext-bks; Fri, 17 Jul 1998 10:55:48 -0700 (PDT) Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02687 for ; Fri, 17 Jul 1998 10:55:47 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by adept.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA22595; Fri, 17 Jul 1998 10:56:01 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <35AF5B59.20984366@att.com> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Fri, 17 Jul 1998 10:54:31 -0700 To: Tony Hansen From: Randall Gellens Subject: Re: any comments on draft-hansen-pop3-xtndext-00.txt? Cc: ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA00990 for ietf-pop3ext-bks; Fri, 17 Jul 1998 07:16:07 -0700 (PDT) Received: from att.com (kcgw2.att.com [192.128.133.152]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA00986 for ; Fri, 17 Jul 1998 07:16:06 -0700 (PDT) Received: by kcgw2.att.com; Fri Jul 17 08:48 CDT 1998 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by kcig2.att.att.com (AT&T/GW-1.0) with ESMTP id JAA08924 for ; Fri, 17 Jul 1998 09:08:17 -0500 (CDT) Received: from hansen.bl-els.att.com by maillennium.att.com (inetlab) with SMTP id <19980717140854un10478231e>; Fri, 17 Jul 1998 14:08:54 +0000 Message-ID: <35AF5B59.20984366@att.com> Date: Fri, 17 Jul 1998 10:10:33 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: any comments on draft-hansen-pop3-xtndext-00.txt? X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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, tony@att.com ==== 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15728 for ietf-pop3ext-bks; Thu, 16 Jul 1998 18:14:57 -0700 (PDT) Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15724 for ; Thu, 16 Jul 1998 18:14:54 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id SAA20686; Thu, 16 Jul 1998 18:14:55 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <35A69543.42E82E0B@demo.ru> References: <199807090130.VAA28119@spot.cs.utk.edu> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 16 Jul 1998 18:06:19 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA15577 for ietf-pop3ext-bks; Thu, 16 Jul 1998 18:00:50 -0700 (PDT) Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA15573 for ; Thu, 16 Jul 1998 18:00:49 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by warlock.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id RAA06358; Thu, 16 Jul 1998 17:58:20 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> <199807090130.VAA28119@spot.cs.utk.edu> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 16 Jul 1998 17:54:32 -0700 To: Laurence Lundblade From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: Randall Gellens , Steve Hole , ietf-pop3ext@imc.org, John Gardiner Myers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA11933 for ietf-pop3ext-bks; Thu, 16 Jul 1998 10:26:29 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA11929 for ; Thu, 16 Jul 1998 10:26:27 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id KAA12008; Thu, 16 Jul 1998 10:26:03 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: lgl@randy-nt4.qualcomm.com Message-Id: In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> <199807090130.VAA28119@spot.cs.utk.edu> Date: Thu, 16 Jul 1998 10:04:41 -0700 To: Randall Gellens From: Laurence Lundblade Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: Steve Hole , ietf-pop3ext@imc.org Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10146 for ietf-pop3ext-bks; Thu, 16 Jul 1998 07:05:54 -0700 (PDT) Received: from monet.esys.ca (monet.esys.ca [198.161.92.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10142 for ; Thu, 16 Jul 1998 07:05:53 -0700 (PDT) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by monet.esys.ca (2.0.4-beta-2/SMS 2.0.4-devel) with ESMTP id IAA27304; Thu, 16 Jul 1998 08:05:47 -0600 (MDT) Message-Id: <199807161405.IAA27304@monet.esys.ca> From: Steve Hole Date: Thu, 16 Jul 1998 08:04:25 -0600 To: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> <199807090130.VAA28119@spot.cs.utk.edu> Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Message-ID: 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 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:Steve.Hole@esys.ca Phone:403-424-4922 --Part9807160804.F Content-Type: Application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version) iQA/AwUBNa4Iati5Jj9Fn5KMEQL85ACgxq0Kg7FKaxRHQVH79a92+YX3/BMAn1CG CZUtzdF0PLy4SVdKuMKsQYK0 =/6hC -----END PGP SIGNATURE----- --Part9807160804.F-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA25678 for ietf-pop3ext-bks; Wed, 15 Jul 1998 18:21:07 -0700 (PDT) Received: from mail.hethmon.com (mail.hethmon.com [208.147.156.6]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA25674 for ; Wed, 15 Jul 1998 18:21:05 -0700 (PDT) Received: from mail.hethmon.com (mail.hethmon.com [208.147.156.6] ) by mail.hethmon.com (Hethmon Brothers Smtpd) ; Wed, 15 Jul 1998 21:25:32 -0400 Message-Id: <199807152125.3235110.6@mail.hethmon.com> Received: from sambo.hethmon.com by mail.hethmon.com (Hethmon Brothers Pop3d) ; Wed, 15 Jul 1998 21:25:31 -0400 To: ietf-pop3ext@imc.org X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Wed, 15 Jul 1998 21:21:32 -0400 From: Paul Hethmon Reply-To: Paul Hethmon Subject: Re: [Off Topic] Need review for POP3 extension mechanism Sender: owner-ietf-pop3ext@imc.org Precedence: bulk ** Reply to note from Keith Moore 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 phethmon@hethmon.com 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA25398 for ietf-pop3ext-bks; Wed, 15 Jul 1998 17:34:23 -0700 (PDT) Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA25394 for ; Wed, 15 Jul 1998 17:34:21 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA29230; Wed, 15 Jul 1998 17:33:57 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> <199807090130.VAA28119@spot.cs.utk.edu> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Wed, 15 Jul 1998 17:32:43 -0700 To: Steve Hole From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15480 for ietf-pop3ext-bks; Mon, 13 Jul 1998 15:23:54 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15469; Mon, 13 Jul 1998 15:23:26 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA15020; Mon, 13 Jul 1998 15:22:41 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: lgl@randy-nt4.qualcomm.com Message-Id: In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> Date: Mon, 13 Jul 1998 15:09:37 -0700 To: Jacob Palme From: Laurence Lundblade Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org, IETF mail extensions mailing list Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA15464 for ietf-pop3ext-bks; Mon, 13 Jul 1998 15:22:52 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA15460 for ; Mon, 13 Jul 1998 15:22:51 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id PAA15036; Mon, 13 Jul 1998 15:22:45 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: lgl@randy-nt4.qualcomm.com Message-Id: In-Reply-To: References: <199807090130.VAA28119@spot.cs.utk.edu> <199807090130.VAA28119@spot.cs.utk.edu> Date: Mon, 13 Jul 1998 15:17:04 -0700 To: ietf-pop3ext@imc.org, Keith Moore From: Laurence Lundblade Subject: Re: [Off Topic] Need review for POP3 extension mechanism Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA12777 for ietf-pop3ext-bks; Mon, 13 Jul 1998 09:50:59 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA12773; Mon, 13 Jul 1998 09:50:58 -0700 (PDT) Received: from elwood.innosoft.com ("port 37814"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-11 #U3049) with SMTP id <01IZCJ1NBOEQ99DUJH@INNOSOFT.COM>; Mon, 13 Jul 1998 09:51:16 PDT Date: Mon, 13 Jul 1998 09:52:32 -0700 (PDT) From: Chris Newman Subject: Re: [Off Topic] Need review for POP3 extension mechanism In-reply-to: To: Jacob Palme Cc: ietf-pop3ext@imc.org, IETF mail extensions mailing list Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA12051 for ietf-pop3ext-bks; Mon, 13 Jul 1998 08:08:55 -0700 (PDT) Received: from dragon (ppp1550.glas.apc.org [195.218.251.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA12047 for ; Mon, 13 Jul 1998 08:08:46 -0700 (PDT) Received: FROM demo.ru ([127.0.0.1]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 13 Jul 1998 18:58:16 +0300 Message-ID: <35AA2088.31FD8511@demo.ru> Date: Mon, 13 Jul 1998 18:58:16 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Randall Gellens CC: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism References: <199807090130.VAA28119@spot.cs.utk.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA17766 for ietf-pop3ext-bks; Sun, 12 Jul 1998 02:37:29 -0700 (PDT) Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA17752; Sun, 12 Jul 1998 02:36:43 -0700 (PDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.8/8.8.8) with ESMTP id LAA09126; Sun, 12 Jul 1998 11:37:02 +0200 (MET DST) X-Sender: jpalme@mail.dsv.su.se (Unverified) Message-Id: In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jul 1998 11:35:46 +0200 To: ietf-pop3ext@imc.org, IETF mail extensions mailing list From: Jacob Palme Subject: Re: [Off Topic] Need review for POP3 extension mechanism Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 ietf-pop3ext@imc.org, so please copy any replies to this message, which I should see, either to me personally or to the mailext@imc.org 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 (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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA09370 for ietf-pop3ext-bks; Fri, 10 Jul 1998 16:32:53 -0700 (PDT) Received: from frobozz.qualcomm.com (frobozz.qualcomm.com [129.46.174.26]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA09366 for ; Fri, 10 Jul 1998 16:32:51 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by frobozz.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id QAA11701; Fri, 10 Jul 1998 16:32:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <35A69543.42E82E0B@demo.ru> References: <199807090130.VAA28119@spot.cs.utk.edu> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Fri, 10 Jul 1998 16:29:02 -0700 To: Alexey Melnikov From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Cc: ietf-pop3ext@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08358 for ietf-pop3ext-bks; Fri, 10 Jul 1998 15:25:57 -0700 (PDT) Received: from dragon (ppp1215.glas.apc.org [194.154.81.161]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08352 for ; Fri, 10 Jul 1998 15:25:53 -0700 (PDT) Received: FROM demo.ru ([194.154.81.161]) BY dragon.cs.msu.su (Baikonur Mail Server) WITH ESMTP; 11 Jul 1998 02:27:16 +0300 Message-ID: <35A69543.42E82E0B@demo.ru> Date: Sat, 11 Jul 1998 02:27:16 +0400 From: Alexey Melnikov Organization: Epsylon Technologies X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism References: <199807090130.VAA28119@spot.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Sorry for delay. I forgot about Last Call, my fault. Keith Moore wrote: > 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? 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 :-)) Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07242 for ietf-pop3ext-bks; Fri, 10 Jul 1998 12:56:19 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07238 for ; Fri, 10 Jul 1998 12:56:18 -0700 (PDT) Received: from elwood.innosoft.com ("port 35558"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-11 #U3049) with SMTP id <01IZ8IMUAEE099DSO5@INNOSOFT.COM> for ietf-pop3ext@imc.org; Fri, 10 Jul 1998 12:56:09 PDT Date: Fri, 10 Jul 1998 12:57:26 -0700 (PDT) From: Chris Newman Subject: Re: [Off Topic] Need review for POP3 extension mechanism In-reply-to: To: Steve Hole Cc: ietf-pop3ext@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05080 for ietf-pop3ext-bks; Fri, 10 Jul 1998 07:38:14 -0700 (PDT) Received: from rembrandt.esys.ca (0@rembrandt.esys.ca [198.161.92.18]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05076 for ; Fri, 10 Jul 1998 07:38:13 -0700 (PDT) Received: from gallileo.esys.ca (gallileo.esys.ca [198.161.92.85]) by rembrandt.esys.ca (2.0.4-beta-1/SMS 2.0.4-beta-1) with ESMTP id IAA13965 for ; Fri, 10 Jul 1998 08:38:20 -0600 From: Steve Hole Date: Fri, 10 Jul 1998 08:37:05 -0600 To: ietf-pop3ext@imc.org Subject: Re: [Off Topic] Need review for POP3 extension mechanism In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu> References: <199807090130.VAA28119@spot.cs.utk.edu> Message-ID: X-Mailer: Simeon for Win32 Version Mercury a9 Build (12) MIME-Version: 1.0 Content-Type: Text/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-pop3ext@imc.org Precedence: bulk On Wed, 08 Jul 1998 21:30:01 -0400 Keith Moore 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:Steve.Hole@esys.ca Phone:403-424-4922 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA03520 for ietf-pop3ext-bks; Fri, 10 Jul 1998 04:05:17 -0700 (PDT) Received: from doom.qualcomm.co.nz (doom.qualcomm.co.nz [203.97.157.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA03515 for ; Fri, 10 Jul 1998 04:05:05 -0700 (PDT) Received: from [203.97.157.3] (203.97.157.3) by doom.qualcomm.co.nz with ESMTP (Eudora Internet Mail Server 2.2b1); Fri, 10 Jul 1998 23:05:20 +1200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: glenn@mail.qualcomm.co.nz Message-Id: In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu> Date: Fri, 10 Jul 1998 23:05:10 +1200 To: ietf-pop3ext@imc.org From: Glenn Anderson Subject: Re: [Off Topic] Need review for POP3 extension mechanism Sender: owner-ietf-pop3ext@imc.org Precedence: bulk >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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13882 for ietf-pop3ext-bks; Thu, 9 Jul 1998 14:51:42 -0700 (PDT) Received: from houdini.qualcomm.com (houdini.qualcomm.com [129.46.2.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA13878 for ; Thu, 9 Jul 1998 14:51:41 -0700 (PDT) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by houdini.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id OAA12736 for ; Thu, 9 Jul 1998 14:51:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <199807090130.VAA28119@spot.cs.utk.edu> X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh Date: Thu, 9 Jul 1998 14:38:50 -0700 To: ietf-pop3ext@imc.org From: Randall Gellens Subject: Re: [Off Topic] Need review for POP3 extension mechanism Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Random-Signature-Tag: v1.0a10 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA12491 for ietf-pop3ext-bks; Thu, 9 Jul 1998 12:27:44 -0700 (PDT) Received: from gw3.octel.com (gw3.octel.com [148.147.1.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA12487 for ; Thu, 9 Jul 1998 12:27:42 -0700 (PDT) Received: from curly.eng.octel.com (curly.eng.octel.com [148.147.200.26]) by gw3.octel.com (8.8.8/8.8.8) with ESMTP id MAA09872 for ; Thu, 9 Jul 1998 12:27:18 -0700 (PDT) Received: from buzz.ons.octel.com (buzz.ons.octel.com [155.184.13.4]) by curly.eng.octel.com (8.6.12/8.6.12) with ESMTP id MAA03261 for ; Thu, 9 Jul 1998 12:27:17 -0700 Received: from ex-ons0.ons.octel.com (exchange [155.184.13.159]) by buzz.ons.octel.com (8.8.6/8.8.6) with ESMTP id OAA15123 for ; Thu, 9 Jul 1998 14:27:14 -0500 (CDT) Received: by exchange.ons.octel.com with Internet Mail Service (5.5.1960.3) id <3MSRZHYD>; Thu, 9 Jul 1998 14:26:06 -0500 Message-ID: <6B57F36F4FF9D111B30A0008C7F4133711EC91@exdal1.ons.octel.com> From: "Vaudreuil, Greg M (Greg)" To: ietf-pop3ext@imc.org Subject: RE: [Off Topic] Need review for POP3 extension mechanism Date: Thu, 9 Jul 1998 14:24:39 -0500 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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:moore@cs.utk.edu] > Reply To: ietf-pop3ext@imc.org > Sent: Wednesday, July 08, 1998 8: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 > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA11100 for ietf-pop3ext-bks; Thu, 9 Jul 1998 09:26:44 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA11096 for ; Thu, 9 Jul 1998 09:26:43 -0700 (PDT) Received: from elwood.innosoft.com ("port 60319"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-11 #U3049) with SMTP id <01IZ6WZRRM2A99DOLZ@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu, 9 Jul 1998 09:25:51 PDT Date: Thu, 09 Jul 1998 09:27:08 -0700 (PDT) From: Chris Newman Subject: Re: [Off Topic] Need review for POP3 extension mechanism In-reply-to: <199807090130.VAA28119@spot.cs.utk.edu> To: ietf-pop3ext@imc.org Cc: moore@cs.utk.edu Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA19988 for ietf-pop3ext-bks; Wed, 8 Jul 1998 18:30:06 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19983; Wed, 8 Jul 1998 18:30:05 -0700 (PDT) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id VAA28119; Wed, 8 Jul 1998 21:30:01 -0400 (EDT) Message-Id: <199807090130.VAA28119@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: drums@cs.utk.edu, ietf-smtp@imc.org Subject: [Off Topic] Need review for POP3 extension mechanism cc: moore@cs.utk.edu, ietf-pop3ext@imc.org From: Keith Moore Reply-To: ietf-pop3ext@imc.org Date: Wed, 08 Jul 1998 21:30:01 -0400 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk 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