Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA24367 for ietf-pop3ext-bks; Fri, 20 Mar 1998 10:20:14 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA24363 for ; Fri, 20 Mar 1998 10:20:13 -0800 (PST) Received: from localhost (llundbla@localhost) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with SMTP id KAA08967; Fri, 20 Mar 1998 10:19:52 -0800 (PST) Date: Fri, 20 Mar 1998 10:19:52 -0800 (PST) From: Laurence Lundblade To: Steve Atkins cc: ietf-pop3ext@imc.org Subject: Re: comments on draft-gellens-pop3ext-02.txt In-Reply-To: <3.0.1.32.19980319184857.00b55e00@no3.superb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Not sure where this was discussed but you're right it was :-) Whatever anyone thinks about XTND XMIT, I think discussion about it should be decoupled from the POP extension mechanism. The current draft certainly does not absolutey preclude it or anything like it even though it discourages it. Given that the language is only a suggestion that it will be hard to get such a thing through the IESG I would hope this isn't a problem. LL On Thu, 19 Mar 1998, Steve Atkins wrote: > Chris newman wrote: > >On Thu, 12 Mar 1998, Tom Killalea wrote: > > > >> Given recent discussion on the GRIP WG list (grip-wg@uu.net) arising > >> from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not* > >> a draft sanctioned by that group) does it make sense to explicitly > >> discourage/deprecate XTND XMIT and indicate why it's a bad idea ? > > > >The draft says enough about this in the "Future Extensions to POP3" > >section. It makes it quite clear that extensions which duplicate > >capabilities supplied by IMAP or SMTP are strongly discouraged. Since > >"XTND XMIT" duplicates SMTP functionality (defectively to bat), it > >is therefore strongly discouraged and there's no way it could ever be > >standardized. > > That's exactly why I'm lurking here... > > It's quite clear (to me, anyway) that XTND XMIT doesn't duplicate > SMTP functionality (SMTP doesn't usually have sender authentication). > > Whilst fixing SMTP to require authentication would be ideal that's > a lot less likely to happen than standardising a POP3 or IMAP send > extension. (Not neccesarily using XTND XMIT type protocol - as you say, > it's broken). > > I get the impression that this has been 'discussed' at length somewhere > before - if someone could point me at an archive, or give me the gist > of the argument I'd appreciate it. > > Cheers, > Steve > -- > -- Steve Atkins -- steve@blighty.com > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id QAA04550 for ietf-pop3ext-bks; Thu, 19 Mar 1998 16:17:28 -0800 (PST) Received: from apprentice.qualcomm.com (apprentice.qualcomm.com [129.46.2.86]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id QAA04546 for ; Thu, 19 Mar 1998 16:17:27 -0800 (PST) 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 QAA29061; Thu, 19 Mar 1998 16:16:48 -0800 (PST) Message-Id: In-Reply-To: <3.0.1.32.19980319184857.00b55e00@no3.superb.net> References: <199803122108.NAA20701@cypress.nwnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro 4.0 for Macintosh Date: Thu, 19 Mar 1998 16:08:20 -0800 To: Steve Atkins From: Randall Gellens Subject: Re: comments on draft-gellens-pop3ext-02.txt Cc: ietf-pop3ext@imc.org Sender: owner-ietf-pop3ext@imc.org Precedence: bulk At 6:48 PM -0500 3/19/98, Steve Atkins wrote: >Whilst fixing SMTP to require authentication would be ideal that's >a lot less likely to happen than standardising a POP3 or IMAP send >extension. (Not neccesarily using XTND XMIT type protocol - as you say, >it's broken). I disagree; there is a proposal for an AUTH command in SMTP (using SASL) and I haven't heard any objections to it. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id PAA04375 for ietf-pop3ext-bks; Thu, 19 Mar 1998 15:51:30 -0800 (PST) Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id PAA04371 for ; Thu, 19 Mar 1998 15:51:29 -0800 (PST) Received: from dangermouse (d4.dial-14.mbo.ma.ultra.net [146.115.100.68]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with SMTP id SAA09835 for ; Thu, 19 Mar 1998 18:51:06 -0500 (EST) Message-Id: <3.0.1.32.19980319184857.00b55e00@no3.superb.net> X-Sender: blighty@no3.superb.net X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 19 Mar 1998 18:48:57 -0500 To: ietf-pop3ext@imc.org From: Steve Atkins Subject: Re: comments on draft-gellens-pop3ext-02.txt In-Reply-To: References: <199803122108.NAA20701@cypress.nwnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Chris newman wrote: >On Thu, 12 Mar 1998, Tom Killalea wrote: > >> Given recent discussion on the GRIP WG list (grip-wg@uu.net) arising >> from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not* >> a draft sanctioned by that group) does it make sense to explicitly >> discourage/deprecate XTND XMIT and indicate why it's a bad idea ? > >The draft says enough about this in the "Future Extensions to POP3" >section. It makes it quite clear that extensions which duplicate >capabilities supplied by IMAP or SMTP are strongly discouraged. Since >"XTND XMIT" duplicates SMTP functionality (defectively to bat), it >is therefore strongly discouraged and there's no way it could ever be >standardized. That's exactly why I'm lurking here... It's quite clear (to me, anyway) that XTND XMIT doesn't duplicate SMTP functionality (SMTP doesn't usually have sender authentication). Whilst fixing SMTP to require authentication would be ideal that's a lot less likely to happen than standardising a POP3 or IMAP send extension. (Not neccesarily using XTND XMIT type protocol - as you say, it's broken). I get the impression that this has been 'discussed' at length somewhere before - if someone could point me at an archive, or give me the gist of the argument I'd appreciate it. Cheers, Steve -- -- Steve Atkins -- steve@blighty.com Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA03473 for ietf-pop3ext-bks; Thu, 19 Mar 1998 13:54:52 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA03469 for ; Thu, 19 Mar 1998 13:54:51 -0800 (PST) Received: from elwood.innosoft.com ("port 50118"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IUUPNQGWD28Y5DFR@INNOSOFT.COM> for ietf-pop3ext@imc.org; Thu, 19 Mar 1998 13:52:32 PST Date: Thu, 19 Mar 1998 13:54:20 -0800 (PST) From: Chris Newman Subject: Re: comments on draft-gellens-pop3ext-02.txt In-reply-to: <199803122108.NAA20701@cypress.nwnet.net> To: Tom Killalea 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 Thu, 12 Mar 1998, Tom Killalea wrote: > > Note that there is no APOP capability, even though APOP is an > > optional command in [POP3]. Clients discover server support of > > APOP by the presence in the greeting banner of an initial challenge > > enclosed in angle brackets ("<>"). Therefore, an APOP capability > > would introduce two ways for a server to announce the same thing. > > I think that having two ways to announce the same thing is a lesser sin > than returning an incomplete list with a dependence on another > mechanism to complete the list. I disagree. Having two ways to announce a capability introduces a "Silly State" (see draft-newman-protocol-design-01.txt). What does an APOP client do if APOP is in the capability list, but there's no challenge in the greeting banner? The fact is it can't do anything because APOP isn't supported. That means looking for "APOP" in the capability list is meaningless even if we did add it. Human readability comes second to correct design, and while human readability would dictate a complete list of capabilities, correct design dictates otherwise. > Given recent discussion on the GRIP WG list (grip-wg@uu.net) arising > from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not* > a draft sanctioned by that group) does it make sense to explicitly > discourage/deprecate XTND XMIT and indicate why it's a bad idea ? The draft says enough about this in the "Future Extensions to POP3" section. It makes it quite clear that extensions which duplicate capabilities supplied by IMAP or SMTP are strongly discouraged. Since "XTND XMIT" duplicates SMTP functionality (defectively to bat), it is therefore strongly discouraged and there's no way it could ever be standardized. - Chris Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id MAA16777 for ietf-pop3ext-bks; Fri, 13 Mar 1998 12:19:41 -0800 (PST) Received: from adept.qualcomm.com (adept.qualcomm.com [129.46.2.41]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id MAA16773 for ; Fri, 13 Mar 1998 12:19:40 -0800 (PST) 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 MAA27186; Fri, 13 Mar 1998 12:18:23 -0800 (PST) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro 4.0 for Macintosh Date: Fri, 13 Mar 1998 12:00:56 -0800 To: Laurence Lundblade From: Randall Gellens Subject: Re: LMOS Cc: ietf-pop3ext@imc.org Sender: owner-ietf-pop3ext@imc.org Precedence: bulk At 10:37 AM -0800 3/13/98, Laurence Lundblade wrote: >I'm having trouble designing sensible UI for the three values for new, >top'd and retr'd. While it's likely that new and top'd will have the same >value, you still have to design sensible UI for when they're not. So about >about LMOS-fully-fetched, and LMOS-not-fully-fetched? Then require new and >top'd messages to be considered as not-fully-fetched. But a TOPped message might really be fully-fetched. At RFC 1939 warns, if a server is implementing some form of message expiration, users might start using TOP in lieu of of RETR as a way around the policy. As a result, some sites might have a policy that treats TOP and RETR as "seen". The current draft recommends that there be only two categories of messages, and allows TOP to be placed in either. We could make this a SHOULD. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id KAA15795 for ietf-pop3ext-bks; Fri, 13 Mar 1998 10:48:47 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id KAA15791 for ; Fri, 13 Mar 1998 10:48:46 -0800 (PST) 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 KAA25650 for ; Fri, 13 Mar 1998 10:47:53 -0800 (PST) X-Sender: llundbla@nala.qualcomm.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Mar 1998 10:37:07 -0800 To: ietf-pop3ext@imc.org From: Laurence Lundblade Subject: LMOS Sender: owner-ietf-pop3ext@imc.org Precedence: bulk I'm having trouble designing sensible UI for the three values for new, top'd and retr'd. While it's likely that new and top'd will have the same value, you still have to design sensible UI for when they're not. So about about LMOS-fully-fetched, and LMOS-not-fully-fetched? Then require new and top'd messages to be considered as not-fully-fetched. LL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA25105 for ietf-pop3ext-bks; Thu, 12 Mar 1998 17:42:16 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA25101 for ; Thu, 12 Mar 1998 17:42:15 -0800 (PST) Received: from [129.46.136.131] (randy-mac.qualcomm.com [129.46.136.131]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id RAA15064; Thu, 12 Mar 1998 17:41:17 -0800 (PST) Message-Id: In-Reply-To: <199803122108.NAA20701@cypress.nwnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora Pro 4.0 for Macintosh Date: Thu, 12 Mar 1998 17:40:28 -0800 To: Tom Killalea From: Randall Gellens Subject: Re: comments on draft-gellens-pop3ext-02.txt Cc: ietf-pop3ext@imc.org Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Thanks for your comments, Tom. > However, some extensions are necessary (such as ones that provide > improved security [POP-AUTH]), while others are very desirable in > certain situations. In either case a means for discovering server > behavior is needed. Thanks for the wording suggestions. >> The maximum length of a command is increased from 45 characters (4 >> character command, single space, 40 character argument) to 255 >> octets. > >I think such a fundamental change, if it's really needed, would belong in >a revision of 1939 rather than in the extension mechanism document. I don't think so; if a server supports CAPA it must also support commands up to 255 octets; if it doesn't support CAPA, it can be limited to 45. SMTP extensions routinely increase the maximum length of various commands. >I'm uncomfortable with the advertisement of TRANSACTION state-only >capabilities while still in the AUTHORIZATION state. The draft says that a server can have capabilities which are not visible unless the CAPA command is issued in TRANSACTION state, as long as this is stated in the description of the capability, that is, in the RFC which documents it. This way clients which don't care about any auth-invisible caps don't have to issue two CAPA commands. Clients pretty much have to issue a CAPA in auth, so they can learn which auth mechanisms the server supports. >My concern is that potential attackers could use the information gleaned >(including but not limited to IMPLEMENTATION information) to zone in on >servers running vulnerable implementations, servers that implement XTND >XMIT and are potential UBE injection points, etc. This is an old debate (putting implementation info in the banner exposes holes) and I really don't want to get into it. I think the draft allows server writers to come down on either side, and client writers have the tools to cope. >the SHOULD be identical to the command >keyword. OK. SHOULD it is. >> S: IMPLEMENTATION "Shlemazle Plotz v302" > >Have I seen this before, Laurence ? :-) Just my attempt at being cute. A shlemazle server probably will plotz. >> Note that there is no APOP capability, even though APOP is an >> optional command in [POP3]. Clients discover server support of >> APOP by the presence in the greeting banner of an initial challenge >> enclosed in angle brackets ("<>"). Therefore, an APOP capability >> would introduce two ways for a server to announce the same thing. > >I think that having two ways to announce the same thing is a lesser sin >than returning an incomplete list with a dependence on another >mechanism to complete the list. APOP is really an outdated mechanism. SASL is the way to go, and that uses CAPA tags. I think APOP interoperates OK now; there is a way to announce it that works. I can't see client writers changing their ACAP code to look at CAPA tags instead. >to configure a mail check interval SHOULD use this capability to >determine the minimum permissible interval. Servers which OK, I'm happy with a SHOULD here. >Given recent discussion on the GRIP WG list (grip-wg@uu.net) arising >from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not* >a draft sanctioned by that group) does it make sense to explicitly >discourage/deprecate XTND XMIT and indicate why it's a bad idea ? (Do you mean the discussion a few weeks ago, or has there been new stuff that I missed?) I really don't want to get into XTND XMIT. I don't think any mention of it belongs in this draft. Some ISPs love it, lots of IETF people hate it. The "X" mechanism allows it without taking a stand. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id RAA24971 for ietf-pop3ext-bks; Thu, 12 Mar 1998 17:21:24 -0800 (PST) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id RAA24967 for ; Thu, 12 Mar 1998 17:21:23 -0800 (PST) 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 RAA12763; Thu, 12 Mar 1998 17:20:24 -0800 (PST) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: <199803122108.NAA20701@cypress.nwnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Mar 1998 17:03:51 -0800 To: Tom Killalea From: Laurence Lundblade Subject: Re: comments on draft-gellens-pop3ext-02.txt Cc: Randy Gellens , ietf-pop3ext@imc.org Sender: owner-ietf-pop3ext@imc.org Precedence: bulk At 1:08 PM -0800 3/12/98, Tom Killalea wrote: > >>5. The CAPA Command >> >> The POP3 CAPA command returns a list of capabilities supported by >> the POP3 server. It is available in both the AUTHORIZATION and >> TRANSACTION states. Additional capabilities MAY become available >> in the TRANSACTION state, but all capabilities listed in the >> AUTHORIZATION state MUST also be available. If a capability >> available in the TRANSACTION state is not available in the >> AUTHORIZATION state, this MUST be stated in the capabilities >> description. > >I'm uncomfortable with the advertisement of TRANSACTION state-only >capabilities while still in the AUTHORIZATION state. > >My concern is that potential attackers could use the information gleaned >(including but not limited to IMPLEMENTATION information) to zone in on >servers running vulnerable implementations, servers that implement XTND >XMIT and are potential UBE injection points, etc. > >Maybe I'm paranoid (okay, I am), but I think it would be worthwhile to >have two distinct commands, say CAPA and CAPT, for advertising supported >capabilities available in the AUTHORIZATION and TRANSACTION states >respectively. There's nothing that requires advertisement in the AUTHORIZATION state. How about listing this as a security concern? In the interest of simplicity, I was hoping only clients looking for particular TRANSACTION state extensions would have to do the second look up. > >> Section 3 describes the CAPA response using [ABNF]. When a >> capability response describes an optional command, the >> is usually, but is not required to be, identical to the command >> keyword. CAPA response tags are case-insensitive. > >the SHOULD be identical to the command >keyword. > >> S: IMPLEMENTATION "Shlemazle Plotz v302" > >Have I seen this before, Laurence ? :-) It wasn't me despite previous geographic associations :-) > >>6. Initial Set of Capabilities > >> Note that there is no APOP capability, even though APOP is an >> optional command in [POP3]. Clients discover server support of >> APOP by the presence in the greeting banner of an initial challenge >> enclosed in angle brackets ("<>"). Therefore, an APOP capability >> would introduce two ways for a server to announce the same thing. > >I think that having two ways to announce the same thing is a lesser sin >than returning an incomplete list with a dependence on another >mechanism to complete the list. Would be OK with me. I kind of agree with Chris who suggested taking it out though. It's more code and complexity if the APOP options is advertised and their's no cookie in the banner. You have to parse the cookie before the options anyway. I can't think of any reason to have the cookie without advertising APOP. LL Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.7.3) id NAA22995 for ietf-pop3ext-bks; Thu, 12 Mar 1998 13:10:45 -0800 (PST) Received: from cypress.nwnet.net (cypress.nwnet.net [192.80.13.56]) by mail.proper.com (8.8.8/8.7.3) with ESMTP id NAA22991 for ; Thu, 12 Mar 1998 13:10:43 -0800 (PST) Received: from cypress.nwnet.net (localhost [127.0.0.1]) by cypress.nwnet.net (970819888) with ESMTP id NAA20701; Thu, 12 Mar 1998 13:08:56 -0800 (PST) Message-Id: <199803122108.NAA20701@cypress.nwnet.net> To: randy@Qualcomm.Com cc: ietf-pop3ext@imc.org From: Tom Killalea Subject: comments on draft-gellens-pop3ext-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20698.889736935.1@cypress.nwnet.net> Date: Thu, 12 Mar 1998 13:08:56 -0800 Sender: owner-ietf-pop3ext@imc.org Precedence: bulk Congratulations on a very welcome draft. Suggestions below. >1. Introduction > > Because one of the most important features of POP3 is its > simplicity, it is not desirable to have a lot of extensions. > However, some extensions are necessary (such as ones that provide > improved security [POP-AUTH]), some are very desirable in certain > situations, and a means for discovering server behavior is needed. Because one of the most important features of POP3 is its simplicity, it is desirable that extensions be few in number. However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In either case a means for discovering server behavior is needed. >4. Parameter and Response Lengths > > This specification increases the length restrictions on commands > and parameters imposed by RFC 1939. > > The maximum length of a command is increased from 45 characters (4 > character command, single space, 40 character argument) to 255 > octets. I think such a fundamental change, if it's really needed, would belong in a revision of 1939 rather than in the extension mechanism document. >5. The CAPA Command > > The POP3 CAPA command returns a list of capabilities supported by > the POP3 server. It is available in both the AUTHORIZATION and > TRANSACTION states. Additional capabilities MAY become available > in the TRANSACTION state, but all capabilities listed in the > AUTHORIZATION state MUST also be available. If a capability > available in the TRANSACTION state is not available in the > AUTHORIZATION state, this MUST be stated in the capabilities > description. I'm uncomfortable with the advertisement of TRANSACTION state-only capabilities while still in the AUTHORIZATION state. My concern is that potential attackers could use the information gleaned (including but not limited to IMPLEMENTATION information) to zone in on servers running vulnerable implementations, servers that implement XTND XMIT and are potential UBE injection points, etc. Maybe I'm paranoid (okay, I am), but I think it would be worthwhile to have two distinct commands, say CAPA and CAPT, for advertising supported capabilities available in the AUTHORIZATION and TRANSACTION states respectively. > Section 3 describes the CAPA response using [ABNF]. When a > capability response describes an optional command, the > is usually, but is not required to be, identical to the command > keyword. CAPA response tags are case-insensitive. the SHOULD be identical to the command keyword. > S: IMPLEMENTATION "Shlemazle Plotz v302" Have I seen this before, Laurence ? :-) >6. Initial Set of Capabilities > Note that there is no APOP capability, even though APOP is an > optional command in [POP3]. Clients discover server support of > APOP by the presence in the greeting banner of an initial challenge > enclosed in angle brackets ("<>"). Therefore, an APOP capability > would introduce two ways for a server to announce the same thing. I think that having two ways to announce the same thing is a lesser sin than returning an incomplete list with a dependence on another mechanism to complete the list. >6.4. LOGIN-DELAY capability > > CAPA tag: > LOGIN-DELAY > > Arguments: > minimum seconds between logins > > authentication will be accepted. Clients which permit the user > to configure a mail check interval can use this capability to > determine the minimum permissible interval. Servers which to configure a mail check interval SHOULD use this capability to determine the minimum permissible interval. Servers which >7. Future Extensions to POP3 > > Capabilities beginning with the letter "X" are reserved for > experimental non-standard extensions and their use is discouraged. > All other capabilities MUST be defined in a standards track or IESG > approved experimental RFC. Given recent discussion on the GRIP WG list (grip-wg@uu.net) arising from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not* a draft sanctioned by that group) does it make sense to explicitly discourage/deprecate XTND XMIT and indicate why it's a bad idea ? >8. Extended POP3 Response Codes > > POP3 is currently only capable of indicating success or failure to > most commands. Unfortunately, clients often need to know more > information about the cause of a failure in order to gracefully > recover. This is especially important in response to a failed > login (there are widely-deployed clients which attempt to decode > the error text of a PASS command result, to try and distinguish > between "unable to get maildrop lock" and "bad login"). > This specification amends the POP3 standard to permit an optional > response code, enclosed in square brackets, at the beginning of the > human readable text portion of an "+OK" or "-ERR" response. This is very welcome. >10. Security Considerations > > A capability list can reveal information about the server's > authentication capabilities which can be used to determine if > certain attacks will be successful. As I said above, full capabilities disclosure should be restricted until the TRANSACTION state is entered. >12. Full Copyright Statement > > Copyright (C) The Internet Society 1998. All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain > it or assist in its implmentation may be prepared, copied, implementation Cheers, Tom. -- Tom Killalea (425) 649-7417 Verio Northwest tomk@nw.verio.net