Am 21.04.2016 um 19:29 schrieb Brendan Cully: > On Thursday, 21 April 2016 at 10:06, Kevin J. McCarthy wrote: >> On Thu, Apr 21, 2016 at 05:19:00PM +0100, Arnt Gulbrandsen wrote: >> >>> One workaround is to send the three commands separately, not at the same >>> time. I don't like that, it slows down login in all cases and if really is >>> pipelining, then I don't feel confident that the bug only affects THIS >>> instance of pipelining. Mutt will pipeline in other cases too. >> >> I suppose we could try that, but I agree this is less than ideal, and >> Mutt does using the pipelining in other places. Is Mutt doing >> something wrong here (posed to you too Brendan)? > > I don't believe mutt's pipelining is in the wrong here, no. RFC 5161 > explicitly says: > > There are no limitations on pipelining ENABLE. For example, it is > possible to send ENABLE and then immediately SELECT, or a LOGIN > immediately followed by ENABLE.
The interesting part - if this is the initial negotiation phase - is what short-cuts the original maintainers of the faulty software that is involved have taken. This looks like server-end trouble in that either the server can't handle stuff pipelined behind the LOGIN, or more generally a server-end confusion between packets (that can contain multiple lines) and lines. Might be interesting to see what happens with the upstream server if you fuzz the CR-LF versus packet boundaries - I recall that you could nuke ProFTPd 1.2.0-pre-releases at the time if the first packet sent wouldn't contain the CR-LF. If and only if someone were to look into workarounds on the client end, it might be worth experimenting with (A) only splitting (but not synchronizing) the lines into separate writes and flushes, so that the login and/or ENABLE UTF8... request lines end up in distinct packets of their own (assuming they're pushed out and not corked and reassembled), as was - per my interpretation - proposed to Arnt by the upstream support or a side channel (if I'm reading correctly between the lines), or (B) to not pipeline anything together with the final part of an authentication command, such as a <TAG> LOGIN <USER> <PASS>, but to only continue with the client-sent requests after receiving the tagged reply to the LOGIN (or whatever other authentication) request.
