Re: POP3 woes

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]