Re: Extended RETR - version 2

> 
> 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.

It's not obvious to me whether we need this extension or not, but I
don't see any harm in it either, and I do hear some user complaints
about wasting their money downloading a large message from scratch.
(Fortunately, my job doesn't involve user support.)

If someone has volunteered to define the extension anyway, it seems
better to ensure there're no hidden uncertainties left.

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

The statistics posted here so far only show the overhead caused by
re-transmissions as seen by ISP's.  It's likely that some users are
getting disconnected more often than some of the others.  While we
see under 1% POP3 sessions interrupted during a message transfer on
average for an ISP, there may well be over 10% such sessions for a
given user.  If that user once receives a huge message, a disconnect
during the transfer of that message is even more likely.

If we look at the statistics, it's also important to note that most
of the POP3 sessions are to empty mailboxes, and thus didn't have a
real chance to crash.  It makes more sense to count POP3 sessions
that transferred at least one message and use that when calculating
the percentage of crashed transfers.

> 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

I think there should be at least two independent implementations
before this becomes an RFC (if ever).  Then new implementations could
be checked against those two.

> to corrupted email. I suggest adding a paragraph mentioning that the offset
> is calculated by using CRLF line endings, just to make sure.

I think the reference to section 11 of RFC 1939 covers that.

> 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.

Agreed.

> 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

That would violate RFC 1939 anyway.

Signed,
Solar Designer