Re: Extended RETR - version 2

Anders Rundegren <[email protected]> wrote:
:> >Where in the world is the above statistics from?

: Correction: the above question was meant to be referring to geographic
: location (please excuse my malformed translation).

Germany.

I have no historical data at the moment to tell us, whether the numbers are
getting better or worse. But I am quite sure that they are getting better.
>From my view there is no need for the extended RETR, but maybe others see
different statistics here.

Would be nice to have some more statistics from other parts of the world
and other types of ISPs.

Another thing: The offset and bytestuffing issue is really the killer here.
If this is not documented properly and there is only one implementation
doing it differently the whole thing is worthless, because it will lead
to corrupted email. I suggest adding a paragraph mentioning that the offset
is calculated by using CRLF line endings, just to make sure.

And another caveat: The RFC should mention that there is no guarantee that
the message numbering stays the same from one POP connection to the next.
For instance, if there is another process accessing the same mailbox at the
same time it might have deleted a message. So if the client wants to use
extended RETR it MUST use UIDL to find the right message number, which further
complicates the matter and is an easy trap for the implementor to fall into.

And a third caveat: There might be server implementations that send some
error message when dieing unexpectedly. For instance when the server gets
a signal it might send a "-ERR I am out of here" message or similar. If this
can ever happen while the server is sending the mail, the client would
probabely not notice this, take this message as part of the mail, and ask
for a retransmit with the wrong offset resulting in a corrupted mail. I don't
know of any server with this behaviour, but it is a possible szenario. So
when the author of the server implements the extended RETR, he has to make
sure, that this can never happen with his server.

Jochen
-- 
Jochen Topf - [email protected] - http://www.remote.org/jochen/