Op 1/3/2018 om 8:31 AM schreef Daniel Kenzelmann: > 3. Januar 2018 00:49, "Stephan Bosch" <step...@rename-it.nl> schrieb: > >> Op 1/2/2018 om 10:48 PM schreef Daniel Kenzelmann: >> >>> Hi, >>> >>> I'm not entirely sure whether this issue is with exim or with dovecot. >>> >>> First some background: >>> I'm using exim with dovecot-auth which in turn is using LDAP for >>> authentication. >>> >>> When using AUTH PLAIN with the optional initial response argument, >>> everything is fine. >>> >>> However when using AUTH PLAIN without the optional response argument, >>> instead of getting an empty challenge ("334 ") as per RFC i am getting >>> a "535 Incorrect authentication data". >>> >>> Example: >>> Working: >>> 220 XXXX ESMTP 2018-01-02 22:32:33+0100 >>> EHLO test >>> 250-XXXX Hello XXXXX [x.x.x.x] >>> 250-SIZE 52428800 >>> 250-8BITMIME >>> 250-PIPELINING >>> 250-AUTH PLAIN LOGIN >>> 250-CHUNKING >>> 250 HELP >>> AUTH PLAIN XXXXXXXXXXXXXXXXXXXXXXXX== >>> 235 Authentication succeeded >>> >>> NOT-WORKING: >>> 220 XXXX ESMTP 2018-01-02 22:34:37+0100 >>> EHLO test >>> 250-XXXX Hello XXXXX [x.x.x.x] >>> 250-SIZE 52428800 >>> 250-8BITMIME >>> 250-PIPELINING >>> 250-AUTH PLAIN LOGIN >>> 250-CHUNKING >>> 250 HELP >>> AUTH PLAIN >>> 535 Incorrect authentication data >>> >>> Here the SASL mechanism should return an empty challenge as per RFC >>> (i.e. "334 " in SMTP): >> This is a an error produced by Exim. I find the Exim error handling in >> Exim's implementation of the AUTH command rather peculiar. Still, I >> managed to decipher at least part of it. >> >> That error is produced when FAIL status is returned from the driver: >> >> https://github.com/Exim/exim/blob/master/src/src/smtp_in.c#L3665 >> >> This FAIL status can be returned by the driver itself, but -- in this >> case more likely -- the Dovecot driver in Exim also returns FAIL status >> when Dovecot auth service returns "FAIL": >> >> https://github.com/Exim/exim/blob/master/src/src/auths/dovecot.c#L472 >> >> So, this may very well be an issue triggered by Dovecot. What version of >> Dovecot is this? Some things were modified in initial response handling >> recently (v2.3) and I may have messed up something. >> >> Does Dovecot log anything interesting with auth_verbose and auth_debug >> enabled? >> >> Regards, >> >> Stephan. > > Hi, > > System is gentoo, > dovecot version is 2.3.0 > exim version is 4.90 > > Debug log does only show the following: > auth: Debug: auth client connected (pid=0) > auth: Debug: client in: AUTH 1 PLAIN service=smtp secured > rip=XX.XX.XX.XX lip=XX.XX.XX.XX nologin resp=<hidden> > auth: plain(?,XX.XX.XX.XX): invalid input > auth: Debug: client passdb out: FAIL 1 > > I'm not 100% sure but i think it worked earlier, so this might be connected > to the 2.3 update. (if REALLY needed i can try to confirm by downgrading > dovecot)
Ok. I know what is going on already. This commit triggers the problem: https://github.com/dovecot/core/commit/e4b72bd73bfffda7906faa248eab31f936cfc6fa That fix was added to handle the EXTERNAL SASL mechanism properly when used in ManageSieve, and somehow I didn't realize that the original comment means that Exim would also send an empty resp field for an absent initial response: https://github.com/Exim/exim/blob/master/src/src/auths/dovecot.c#L403 This is now handled as an empty initial response instead (as it should be), which -- in this case -- makes the PLAIN mechanism complain about invalid data. So, the fundamental blame lies with Exim for violating the protocol. However, I don't think it is a good idea to break compatibility like that, especially when we want to back-port this fix to Dovecot v2.2. To solve this now, we can recognize an empty initial response for service=smtp differently (EXTERNAL is not used there much I think) and perhaps make that configurable with some setting. Regards, Stephan.