Should I expect Indy Imap SASL connections to work?

Question

In my email checker, I support both POP3 SSL and IMAP SSL. While Pop3 SSL using SASL has been working for some time, I never got IMAP SSL using SASL to work, even though the code for SASL should be very similar between POP3 and IMAP. My understanding was that I shouldn't expect it to work until this issue was fixed. Well, that issue's been fixed, so I thought I'd give another look at making SASL work for IMAP. I've updated and rebuilt Indy, and uncommented all my SASL code, and now I'm finding when I issue the Login command, I'm getting a read timeout in IdIMAP4 (even with the timeout set to generous amount of time (in the neighborhood of 20-30 seconds) that is about 5x longer than it takes to authenticate on POP3 with SASL.

Stepping through the code in the debugger, it appears the line causing the read timeout is in the function function PerformSASLLogin_IMAP(ASASL: TIdSASL; AEncoder: TIdEncoder; on line 1358:

AClient.SendCmd(AClient.NewCmdCounter, 'AUTHENTICATE ' + String(ASASL.ServiceName), [], True); {Do not Localize} 

Considering this entire method was new in the revisions indicated in that bug report, I'm pretty sure I've updated Indy successfully, and my logic for setting up SASL mechanisms and whatnot is very similar to what works for POP3 (except for things like using the IMAP AuthType iatSASL instead of the Pop3 AuthType patSASL). So why might I be getting a read timeout here? How could I troubleshoot whether it's my code or Indy that's not working right? if I change the IMAP.AuthType to iatUserPass or DEF_IMAP4_AUTH connection is successful. I can't seem to find up to date information about whether I should expect SASL with IMAP to be working now, other than the hint that bug report being closed as fixed.

Edit: Per Remy's questions in his reply, here' the TCP conversation captured by wireshark when I set it to connect with SASL without SSL:

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

C1 CAPABILITY

* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN

C1 OK Capability completed.

C2 AUTHENTICATE PLAIN

+ 

C3 LOGOUT

C2 NO [ALERT] Invalid base64 data in continued response

Caird

Answer 1

AFAIK, TIdIMAP SASL is now working fine (considering I'm the one who implemented it). I don't have access to any IMAP servers that use SASL so I couldn't actually test it myself, but this is the first time I have heard of any problems with it in the past several months that the fixed implementation has existed.

However, without seeing the actual socket traffic, there is no way to know if the server is sending any reply back at all, or if TIdIMAP is just not reading the reply correctly. Can you provide an actual log of the commands/responses? Either use a packet sniffer, like Wireshark, or attach one of Indy's own TIdLog... components to the TIdIMAP.Intercept property.

Update: It is a bug in TIdIMAP4.GetInternalResponse(). It is not handling the + line correctly. I have checked in a fix to Indy's SVN.

Warfeld

* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. C1 CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN C1 OK Capability completed. C2 AUTHENTICATE PLAIN + C3 LOGOUT C2 NO [ALERT] Invalid base64 data in continued response – Caird

ack, that's hard to read, i'll edit the question to put that in formatted – Caird

Comparing what it's doing on IMAP with SASL and POP3 with SASL it appears what is missing is the client is not sending the password – Caird

The problem is that TIdIMAP4.SendCmd() is not handling the + line correctly, so it ignores that line and tries to read another line is not actually being sent by the server, hense the timeout. I am looking into why. – Warfeld

A bug fix has been checked in. SASL authentication now works correctly when tested with the provided capture. – Warfeld

That bug fix seemed to do the trick. With that update, I'm now able to authenticate using SASL on the IMAP connection. – Caird