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

Randall Gellens <randy@Qualcomm.Com> Fri, 10 July 1998 23:32 UTC

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 <ietf-pop3ext@imc.org>; 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: <v04100e34b1cc517ae778@[129.46.136.131]>
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 <mel@demo.ru>
From: Randall Gellens <randy@Qualcomm.Com>
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.