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

Alexey Melnikov <mel@demo.ru> Mon, 13 July 1998 15:08 UTC

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 <ietf-pop3ext@imc.org>; 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 <mel@demo.ru>
Organization: Epsylon Technologies
X-Mailer: Mozilla 4.05 [en] (WinNT; I)
MIME-Version: 1.0
To: Randall Gellens <randy@Qualcomm.Com>
CC: ietf-pop3ext@imc.org
Subject: Re: [Off Topic] Need review for POP3 extension mechanism
References: <199807090130.VAA28119@spot.cs.utk.edu> <v04100e34b1cc517ae778@[129.46.136.131]>
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
------------------------------------------