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
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
