Dovrei aspettarmi che le connessioni SASL Indy Imap funzionino?

Question

Nella mia funzione di controllo delle email, supporto sia POP3 SSL che IMAP SSL. Mentre il protocollo SSL Pop3 che utilizza SASL funziona da un po 'di tempo, non ho mai ottenuto IMAP SSL utilizzando SASL per funzionare, anche se il codice per SASL dovrebbe essere molto simile tra POP3 e IMAP. La mia comprensione è stata che non dovevo aspettarmi che funzionasse fino a quando non è stato corretto this issue. Bene, il problema è stato risolto, quindi ho pensato di dare un'altra occhiata a rendere SASL funzionante per IMAP. Ho aggiornato e ricostruito Indy e ho decommentato tutto il mio codice SASL, e ora trovo quando invio il comando Login, sto ottenendo un timeout di lettura in IdIMAP4 (anche con il timeout impostato su un tempo generoso (in il quartiere di 20-30 secondi) che è circa 5 volte più lungo di un'autentica su POP3 con SASL.

Passando attraverso il codice nel debugger, appare la riga che causa il timeout di lettura nella funzione function PerformSASLLogin_IMAP(ASASL: TIdSASL; AEncoder: TIdEncoder; in linea 1358:

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

Considerando che questo intero metodo era nuovo nelle revisioni indicati in tale segnalazione, sono abbastanza sicuro che ho aggiornato Indy con successo, e la mia logica per la creazione di meccanismi di SASL e whatno t è molto simile a ciò che funziona per POP3 (ad eccezione di cose come l'uso di IMAT AuthStype iatSASL invece di Pop3 AuthType patSASL). Allora, perché potrei avere un timeout di lettura qui? Come posso risolvere se è il mio codice o Indy che non funziona correttamente? se cambio IMAP.AuthType in iatUserPass o DEF_IMAP4_AUTH la connessione ha esito positivo. Non riesco a trovare informazioni aggiornate sul fatto che dovrei aspettarmi che SASL con IMAP funzioni adesso, a parte il suggerimento che la segnalazione di bug venga chiusa come risolta.

Edit: domande di Per Remy Nella sua replica, qui' la conversazione TCP catturato da Wireshark quando ho impostato per la connessione con SASL senza 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 

Answer 1

per quanto ne so, TIdIMAP SASL sta ora lavorando bene (considerando che sono colui che l'ha implementato). Non ho accesso a nessun server IMAP che utilizza SASL, quindi non ho potuto testarlo da solo, ma questa è la prima volta che ho sentito di problemi con esso negli ultimi mesi che l'implementazione fissa è esistita.

Tuttavia, senza vedere il traffico di socket effettivo, non è possibile sapere se il server sta inviando alcuna risposta o se TIdIMAP non sta semplicemente leggendo la risposta correttamente. Puoi fornire un log effettivo dei comandi/risposte? Utilizzare uno sniffer di pacchetti, come Wireshark, o collegare uno dei componenti TIdLog... di Indy alla proprietà TIdIMAP.Intercept.

Aggiornamento: È un bug in TIdIMAP4.GetInternalResponse(). Non gestisce correttamente la linea +. Ho controllato una correzione per SVN di Indy.