2.2.13 authentication problems?

[Michael Loftis]

Our 2.2.13 frontends seem to have some...weird authentication problems with 
our (one remaining) 2.1 backend.  after some indeterminate amount of time 
or transactions they can no longer authenticate to the backends, but ONLY 
the imap proxyd's.  The error sent tot he client is Server(s) unavailable, 
and the frontend logs couldn't authenticate to backend server: bad protocol 
/ cancel -- the backend doesn't appear to see any auth attempt, jsut a 
STARTTLS ... after that I can't follow since it's TLS.

So *ANY* pointers other than "upgrade" would be appreciated.  Please note 
everything was working until we brought other 2.2 backends into production, 
so I'm thinking some bug wherein the frontends are not resetting the SASL 
state or something, and after communicating with a 2.2 backend, have 
trouble (somehow??) communicating with our 2.1 backend.  I can authenticate 
just fine manually with AUTHENTICATE PLAIN using openssl s_client, so it's 
not the backend.  It's exceedingly difficult to upgrade this particular 2.1 
box, partly because you can't migrate mailboxes off of 2.1 servers (again 
because of the TLS stuff, I patched our backends to allow PLAIN because 
there was no other option back then, we do NOT store plain text passwords 
and we're not using Kerb, so the ONLY option to us is PLAIN).



As a complete side note let me reregister an old gripe of mine -- the 
TLS/SSL/etc requirement with PLAIN is still one of the most silly things. 
Plain text between the backends on the same switch should be allowed, it 
would sure make this debuggable.  At the very least, it's a local policy 
decision, not something that should be hardcoded.  I could be using IPSEC 
between the hosts, or some other external security mechanism, or anything, 
but you make NO allowance for that.


--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler