Issue with SASL use of Initial-Response parameter

[rlebeau]

TIdDICT, TIdIMAP4, TIdPOP3 and TIdSMTP implement SASL authentication.

It is currently unknown how the following issue affects TIdDICT, if at all.

TIdIMAP4 uses SASL's Initial-Response only if the server advertises the IMAP SASL-IR capability. No issue there.

POP3 and SMTP are affected by the same issue. POP3 and SMTP servers have no way to advertise their support for Initial-Response. TIdPOP3 gets around this by simply disabling use of Initial-Response altogether. But TIdSMTP currently enables Initial-Response unconditionally, which causes a problem.

When TIdSMTP.AuthType is set to satSASL (the issue does not affect satDefault), and TIdSASLLogin is enabled in the TIdSMTP.SASLMechanisms collection, TIdSMTP sends an AUTH LOGIN command where the username is passed in Initial-Response, like this:

AUTH LOGIN usernameInBase64

Not all SMTP servers support Initial-Response, though. If such a server replies with a username prompt instead of a password prompt, eg:

334 VXNlcm5hbWU6 ("Username:" in base64)

TIdSMTP then sends the password instead of the username, and then the server replies with a password prompt (if not a failure due to an unknown username):

334 UGFzc3dvcmQ6 ("Password:" in base64)

TIdSMTP then sends the password again, and authentication usually fails.

Many 3rd party SMTP clients do not use Initial-Response, mainly because there is currently no defined way for an SMTP server to advertise its support for Initial-Response. However, Initial-Response is formally defined as part of RFCs 2554 and 4954, "SMTP Service Extension for Authentication", and many SMTP servers do support Initial-Response.

Indy SASL components that currently implement Initial-Response, and thus are potentially affected by this issue, are:

TIdSASLAnonymous
TIdSASLExternal
TIdSASLLogin
TIdSASLNTLM
TIdSASLOTP
TIdSASLPlain
TIdSASLSKey