Cannot authenticate SMTP session when using Delta Chat

Cannot authenticate SMTP session when using Delta Chat

Hi,

First of all, thank you for the awesome service you're providing with zoho mail ;).

I've been trying to setup the Delta Chat ( https://delta.chat/en/) Android application to use on my Zoho account. For this I have generated an Application-specific password on the Zoho account. I entered the authenication details for IMAP and SMTP access into the app, however the application was unable to authenticate the SMTP session. The error message indicated that the authentication fails. The exact message from the Android log is:

W DeltaChat: T30: SMTP-login failed for user enki@fsck.pl (Login failed)

As I've independently verified that the password is working for IMAP authentication so I was sure is correct, I began investigating why it fails for SMTP. I have narrowed down the problem to the way the base-64 encoded string is sent during SMTP session authentication using SMTP AUTH PLAIN. Compare below two SMTP sessions:

Session 1, where the AUTH PLAIN string is constructed as base64(\x00 + <email> + \x00 + <password>):

220 mx.zohomail.com SMTP Server ready June 14, 2017 5:49:55 AM PDT
EHLO test
250-mx.zohomail.com Hello test (user-94-254-226-236.play-internet.pl (94.254.226.236))
250-AUTH LOGIN PLAIN
250 SIZE 22020096
AUTH PLAIN AGVua2lAZnNjay5wbABnVUlJNTRlZXVYQWc=
235 Authentication Successful
QUIT
DONE


Session 2, where the AUTH PLAIN string is constructed as base64(<email> + \x00 + <email> + \x00 + <password>):

220 mx.zohomail.com SMTP Server ready June 14, 2017 5:50:34 AM PDT
EHLO test
250-mx.zohomail.com Hello test (user-94-254-226-236.play-internet.pl (94.254.226.236))
250-AUTH LOGIN PLAIN
250 SIZE 22020096
AUTH PLAIN ZW5raUBmc2NrLnBsAGVua2lAZnNjay5wbABnVUlJNTRlZXVYQWc=
535 Authentication Failed
QUIT
DONE

As you can see the first session successfuly authenticates where Session 2 fails. The difference between both sessionsi is how the authentication string is built. As the whole authentication scheme in SMTP is based on SASL (see https://tools.ietf.org/html/rfc4616 for reference) there are 3 components to that are joined with NUL bytes to form the base64 string sent to the server:

- the authorization identity (authzid)
- the authentication identity (authcid)
- the secret

The RFC states, that the authorization identity is optional and doesn't have to be provided:

"""
2.  PLAIN SASL Mechanism

The mechanism consists of a single message, a string of [UTF-8]
   encoded [Unicode] characters, from the client to the server.  The
   client presents the authorization identity (identity to act as),
   followed by a NUL (U+0000) character, followed by the authentication
   identity (identity whose password will be used), followed by a NUL
   (U+0000) character, followed by the clear-text password.  As with
   other SASL mechanisms, the client does not provide an authorization
   identity when it wishes the server to derive an identity from the
   credentials and use that as the authorization identity.
"""

Your SMTP server however rejects authentication attempts where the authorization identity is provided and equal to the authentication identity (Session 2). Setting both authzid and authcid to the same value is perfectly valid according to the SASL LOGIN protocol specification. Because of this I believe that your SMTP server behaviour is not correct. As the SMTP client implementations vary widely across different applications, operating systems and platforms this is likely causing conneciton problems not only for me but also for other users.

You could improve the interoperability of your SMTP service by accepting the SASL authentication messages where authzid is defined and likely solve connection issues for a number of your users.

If you require some more information or testing from my side I'd be happy to help you.

Best regards,
Maciej Grela