Re: POP3 woes

[Peter Bloomfield <PeterBloomfield bellsouth net>]

On 02/13/2017 01:05:50 PM Mon, Albrecht Dreß wrote:
> Hi Peter:
...
> Just a "heretic" question - are we *really* sure the server is broken, of might there be a flaw in Balsa's 
> implementation, which works with some servers, but doesn't with others?  If other MUA's (Thunderbird, Apple Mail Lookout, ...) 
> support pipelining (do they?), my feeling is that a bug in the server would have been noticed.  OTOH, RFC 2449 does not look 
> complicated.  Did you completely trace the "broken" session?  If it's not encrypted (o.k., it /should/ be!), you could 
> even analyse it in Wireshark.

Good question! I've watched the dialog only with Balsa's --debug-pop option, not at the packet level. What I 
see is Balsa sending a burst of RETR commands, and the server responding to the first, terminating it with 
the usual dot-line. Balsa waits for the others, and the server waits for...something? That doesn't look like 
what I would call pipelining, but as you note the RFC is light on details about how it's supposed to work.

> > It's actually quite easy to fix for this particular server: the IMPLEMENTATION is part of the CAPA response, 
> > so we can easily detect that we're talking to jpop-0.1 and ignore its PIPELINING capability. If other servers 
> > had the same problem, we could install a blacklist, but at this point it would have only a single entry, so 
> > hard-coding seems adequate. I'm thinking of adding PopHandle::does_not_pipe.
>
> Blacklists/whitelists are *always* a bad solution IMHO.  You end up maintaining those lists most of the time. 
>  And how would you get swift updates into distos?
>
> > One alternative would be to add an "Enable pipelining" checkbox to the SMTP server dialog, but its purpose 
> > would be obscure, and it's not clear how a user would know to disable it, so I'm inclined against that solution.
>
> I think this would be better.  Just don't name the technical details of the implementation, but the intended purpose.  
> I.e. something like "Optimise for low-bandwidth connections if possible" (this was my intention of re-naming 
> the crypto options the smtp dialogue).

I agree, if reluctantly!

> Side note: Actually I didn't implement smtp pipelining (RFC 2920) in my net-client lib, basically due to the 
> considerations above, and for simpler error checking, and because the transmission is performed in 
> background.  If you feel it would be beneficial, I will add it.

Given the POP3 experience, I suggest holding off until some meaningful loss of performance is demonstrated.

Best,

Peter