IndySockets / Indy

Indy - Internet Direct
https://www.indyproject.org
451 stars 153 forks source link

Fix for #208 - TIdSMTP - correctly handle answer, if Initial-Response is not supported #530

Open jaenicke opened 5 months ago

jaenicke commented 5 months ago

Fix for #208 - If Initial-Response is not supported, the server might fail to handle the request completely or the server might ask for the username, because the server does not handle the provided username after AUTH LOGIN.

At the moment, the login is cancelled at this moment, so it does not work at all.

So I added functionality to answer the request for the username correctly and continue. Note: The encoded string 'Username:' is hardcoded directly in the code at the moment. A constant would be better, but I did not know where to put it correctly.

In addition I added a property CanAttemptIR to TIdSMTP, so one can switch off the try with IR in case the server cannot handle this at all. This was supported already, but the functionality was not exposed, because this parameter was always set to True.

rlebeau commented 5 months ago

The change you propose for IdSASLCollection.pas really belongs in IdSASLLogin.pas instead, as such prompt handling is specific to the AUTH LOGIN command and not to other SASLs.

However, better handling of the AUTH LOGIN prompts was implemented in IdSASLLogin.pas 2 years ago in commit c9cf49, so this ticket really no longer applies to TIdSASLLogin and is still open as other SASLs still need to be reviewed for IR handling.

In the existing sasl-oauth branch, there is a new SASLCanAttemptInitialResponse property added to TIdPOP3. Such a property could be added to TIdSMTP, but I don't think it is necessary since SMTP doesn't have the same problem with detecting IR support that POP3 has. IdSASLCollection.pas already has logic in place to handle IR failure in POP3.