Dovecot auth SASL for exim and plain auth issue without initial response

[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):

RFC 4954 - SMTP Service Extension for Authentication


4.  The AUTH Command

         [..]
         The optional initial response argument to the AUTH command is
         used to save a round-trip when using authentication mechanisms
         that support an initial client response. 
====>    If the initial
====>    response argument is omitted and the chosen mechanism requires
====>    an initial client response, the server MUST proceed as defined
====>    in Section 5.1 of [SASL].  In SMTP, a server challenge that
====>    contains no data is defined as a 334 reply with no text part.
====>    Note that there is still a space following the reply code, so
====>    the complete response line is "334 ".
         [..]



RFC 4422 - Simple Authentication and Security Layer (SASL)

5.  Mechanism Requirements

   SASL mechanism specifications MUST supply the following information:

   1) The name of the mechanism (see Section 3.1).  This name MUST be
      registered as discussed in Section 7.1.

   2) A definition of the server-challenges and client-responses of the
      authentication exchange, as well as the following:

     a) An indication of whether the mechanism is client-first,
        variable, or server-first. 

===>    If a SASL mechanism is defined as
===>    client-first and the client does not send an initial response
===>    in the authentication request, then the first server challenge
===>    MUST be empty
                      (the EXTERNAL mechanism is an example of this
        case).  If a SASL mechanism is defined as variable, then the
        specification needs to state how the server behaves when the
        initial client response in the authentication request is
        omitted (the DIGEST-MD5 mechanism [DIGEST-MD5] is an example of
        this case).  If a SASL mechanism is defined as server-first,
        then the client MUST NOT send an initial client response in the
        authentication request (the CRAM-MD5 mechanism [CRAM-MD5] is an
        example of this case).



Thanks,
Daniel