VPN connessa ma IMAP non si sincronizza? Controlla questi tre livelli
Raggiungere il server di posta, completare la stretta di mano TLS, autenticarsi e selezionare una casella sono eventi separati. Trova il livello che ha fallito.
Connettiti alla VPN dell’ufficio, apri il client di posta e osserva la posta in arrivo rifiutarsi di aggiornarsi mentre la webmail si carica normalmente. La diagnosi abituale è che la VPN lascia passare il traffico ma blocca la posta, oppure che la password dell’account è cambiata. Entrambe le ipotesi saltano la struttura di ciò che fa un client IMAP. Raggiungere l’host, completare TLS, autenticarsi e selezionare una casella sono quattro eventi diversi, e la VPN possiede solo il primo.
Il mito: una connessione significa un accesso
La convinzione è che, una volta alzato il tunnel e quando il server di posta risponde, la casella sia effettivamente aperta. Non lo è. La VPN fornisce un percorso verso il servizio; non effettua l’accesso e non seleziona una cartella. Un client può fermarsi al quarto di questi passaggi con un tunnel perfettamente funzionante e una password valida.
È in questo vuoto che vivono realmente la maggior parte delle segnalazioni «IMAP non funziona con la VPN».
Tre stati IMAP e dove i client si bloccano
IMAP definisce uno stato non autenticato, uno stato autenticato e uno stato selezionato, e i comandi sono validi solo nello stato che li consente. Una connessione può anche iniziare già autenticata quando il server offre la pre-autenticazione, quindi l’assenza di una richiesta di password non dimostra nulla. Selezionare una casella sposta la sessione da autenticata a selezionata, e solo allora i comandi che agiscono sui messaggi hanno un bersaglio.
Un client che si autentica correttamente e poi non riesce a selezionare la cartella configurata sembrerà un errore di sincronizzazione mentre il server si comporta correttamente. Cartelle rinominate, un provider che mappa «posta in arrivo» in modo diverso o permessi di accesso mancanti finiscono tutti qui. La risposta NO etichettata del server è la prova, e non è la stessa risposta di una password rifiutata.
TLS precede la conversazione IMAP
Con TLS implicito sulla porta 993, la stretta di mano TLS si completa prima che venga inviato qualsiasi comando IMAP, per questo un problema di certificato produce un errore che parla di fiducia e non di posta. Il nome host della posta deve essere validato rispetto al certificato come un nome host web; un tunnel che preserva il traffico non rende valido un certificato non valido.
Il testo dell’errore separa i casi. Un timeout di connessione significa che il SYN non si è mai completato. Un errore TLS significa che la connessione TCP ha funzionato e la stretta di mano no. Una risposta IMAP NO o BAD significa che entrambe sono riuscite e che il livello protocollo ha rifiutato qualcosa. Annota quale hai visto prima di cambiare qualsiasi impostazione.
La posta in cache non prova nulla
Un client di posta mostra i messaggi già scaricati indipendentemente dal fatto che oggi riesca a raggiungere il server, quindi una casella che viene visualizzata dice solo che l’archiviazione locale funziona. Qualsiasi test reale deve forzare un’operazione sul server: aggiorna una cartella, scarica un messaggio mai scaricato o invia un comando che il client emetterebbe solo dopo aver selezionato la casella.
Usa un controllo non distruttivo. Aggiornare una cartella e leggere il registro errori dell’account è meglio che eliminare e riaggiungere l’account, il che dimostra soprattutto che la schermata di configurazione funziona ancora.
Invio e webmail sono protocolli diversi
Inviare posta è invio, non IMAP. Usa un servizio separato e di solito una porta separata con il proprio modo TLS e la propria autenticazione, quindi una casella di uscita funzionante non dimostra che la casella IMAP sia stata selezionata, e una casella di uscita rotta non incolpa IMAP.
La webmail è di nuovo diversa. Può riuscire sulla stessa VPN perché è una sessione HTTPS verso un front-end web, il che non dice nulla sull’host IMAP, sulla porta o sul modo TLS del client desktop.
Per un passaggio di consegne, annota quattro risultati separatamente: il percorso VPN, il risultato dell’endpoint di posta e di TLS, il risultato dell’autenticazione dell’account e il risultato della selezione della casella. Tieni credenziali e contenuto dei messaggi fuori dalla nota. Quella registrazione dice alla persona successiva se la correzione appartiene alla rete, al certificato, all’account o alla configurazione delle cartelle, senza indebolire nessuno dei due livelli di protezione.