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.Dovrei aspettarmi che le connessioni SASL Indy Imap funzionino?
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
* OK [CAPABILITY IMAP4rev1 LITERAL + SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS AUTH = PLAIN AUTH = LOGIN] Dovecot ready. C1 CAPACITÀ * CAPACITÀ IMAP4rev1 LETTERALE + SASL-IR LOGIN-referral ID ENABLE sort = DISPLAY FILO = RIFERIMENTI FILO = REFS MULTIAPPEND deselezionare BAMBINI IDLE NAMESPACE UIDPLUS LISTA-EXTENDED I18NLEVEL = 1 CONDSTORE QRESYNC ICERCA Esort SEARCHRES all'interno del contesto = RICERCA ELENCO -STATUS QUOTA STARTTLS AUTH = PLAIN AUTH = LOGIN C1 OK Capacità completata. C2 AUTENTICAZIONE PLAIN + C3 ESCI C2 NO [ALERT] dati base64 non validi nel costante risposta –
ACK, che è difficile da leggere, Io modificare la domanda di metterlo in formattato –
Confrontando quello che sta facendo su IMAP con SASL e POP3 con SASL appare ciò che manca è il client non sta inviando la password –