Re: draft-rose-pop3-again-02.txt

[Steve Dorner <[e-mail]>]

At 1:23 PM 6/22/94, Mark Crispin wrote:
>> Because it is simpler for the server to not accept new connections.
>
>Actually, in an inetd-based implementation on UNIX, it is not.  A POP3 server
>is not the TCP/IP listener.... its choice is pretty
>much limited to closing the connection silently unless a -ERR is permitted.

I don't see that you're allowed to close the connection silently.  I think
you have to wait to give your -ERR on the user or pass or auth commands.

Permitting -ERR as a banner would be a fine thing by me.  I wildly guess
that many clients would pick this up anyway, by virtue of the fact that
ignoring it would probably be a special case.  I know Eudora works that
way.

>If it must be accurate, it should say so.  If it's only an estimate, it should
>say so.  All accurate figures qualify as valid estimates, but not all valid
>estimates qualify as accurate.

While I don't take sides on the accuracy/inaccuracy issue in the protocol,
I don't think that giving estimates should cause a robust client any
significant problem, provided the estimates are within small integral
factors of the truth.

The fact that this is not spelled out in big letters may be partially my
doing.  I know at one point I suggested that the language should be left
alone.  The current language doesn't permit estimates, but nor does it
really bang on the exactness issue.  This allows estimates to be a venal
sin, rather than a mortal one.  Yeah, that's twisted, but I still like it.
:-)

>POP3 is chock-full of optional commands and facilities.  A server has no way
>of knowing what is supported unless it tries one of the optional commands and
>sees what happens.

Hmmm.  I guess I can't imagine clients NOT implementing the POP3 optional
commands, except for the new ones APOP, UIDL, and AUTH.  I wouldn't object
to making them not optional (except for APOP, UIDL, and AUTH).  Does anyone
have servers that don't implement them?

APOP is sorta knowable in advance, because the greeting is required to have
message-id syntax.  Anyone perverse enough to use that greeting but not
support APOP deserves to have old PDP-11's lobbed in his general direction.

In any case, *I* don't find it a burden to just try the commands.  I
wouldn't oppose a capability command, but I probably wouldn't use it,
either.

>The problem is that my server only uses a single space.  I haven't heard of
>any interoperability problems, but I'm going to have to add code to fix this.
>
>So much for minimal server footprint!

What, you didn't implement the parser with scanf?  :-)  Sauce for the goose
is often not sauce for the gander.

>We should find out, and if not, I propose a reduction in the protocol
>consistant with its minimalist goals stated by Marshall.

Requiring a single space would solve the spaces-in-passwords problem.  It
would simplify my parser (but my parser isn't complicated anyway).  It
would simplify Mark's parser.  On the other hand, if there are servers out
there using scanf (popper, surprisingly, doesn't), it would make them MORE
complicated.

I don't care.

>A clarification or tightening of the requirement is needed.  Basically, you
>should not consider the user logged in unless you can ``lock'' the mailbox in
>the POP3 sense.  Agreed?

Sounds good to me.

I'm answering this next bit with what I want to see in a server.  Whether
more words needs to be added to the document to make it say this (assuming
people agree with me), I dunno.

> Case 2: Can get read but not write.  Not sure what to do.

I think the right thing to do is to let the user login but refuse DELE
commands.  Eudora wouldn't like this at all, but I see that as my problem
rather than the server's.

> Case 3: Can get no access at all.  Not sure what to do.

The user is not logged in.

>Is it better to close the TCP connection in case 2/3 happen, or should I say
>zero messages

Aieeeeeeeeeeeee!  Don't say 0 messages, pretty please!  This would cause me
a lot of heartache.  Refuse the login.

>> This memo makes no requirement on what follows the maildrop size.
>> Minimal implementations should just end that line of the response with
>> a CRLF pair.  More advanced implementations may include other
>> information.
>
>Looks good.  Are there any ``more advanced implementations'' which include
>such other information, or should that provision be flushed?

I've always thought that the paragraph that permits this followed by the
paragraph that "STRONGLY" discourages it was odd.  I wouldn't mind seeing
this whole "extended listing" concept nuked.  But it doesn't really matter
to me.

--
Steve Dorner, Qualcomm Incorporated
 "There's nothing wrong with you that can't be cured
  with a little Prozac and a polo mallet." - Woody Allen