In alcuni ambienti Outlook è molto lento nel notificare la presenza di nuova posta.
Il guasto riguarda tutti i servizi di posta elettronica che consentono la sincronizzazione (protocollo IMAP), sia che si tratti di servizi SaaS di posta elettronica che di software per server di posta elettronica. Succede anche con gli stack Microsoft, con Exchange su IMAP e, cosa rilevante perché dimostrabile, con Office 365 stesso.
Questo articolo spiega la falla di Outlook e presenta alcune soluzioni per mitigare questa falla che è esclusiva di Outlook e non consente di agire sul lato server per risolverla.
Il video seguente mostra il guasto, con la spiegazione delle cause, nello scenario in cui lo stack è tutto Microsoft (Outlook collegato a un account Office 365).
Per attenuare il problema, suggeriamo le seguenti alternative
- Le due soluzioni indicate nel video: consultare qualsiasi altra cartella di Outlook e tornare a Posta in arrivo forza l’aggiornamento (fare clic sul pulsante Invia/Ricevi non aiuta), così come mettere Outlook offline e poi tornare online;
- Mantenete Outlook e integratelo con un notificatore di e-mail. Un’applicazione che rimane nell’area di notifica di Windows e controlla solo la presenza di nuova posta;
- Ignorate le notifiche di Outlook e affidatevi a quelle del cellulare;
- Cambiare completamente l’applicazione di posta elettronica (consigliamo Thunderbird della Mozilla Foundation, gratuito per uso commerciale).
Descrizione tecnica dell’incidente di Outlook
Alla base dell’incidente c’è l’incapacità di Outlook di riprendersi da un’interruzione della connessione push-mail TCP. Quando una connessione push-mail cade, Outlook non si riprende mai senza un intervento e quindi non riceve notifiche di nuova posta.
La descrizione dell’errore di Outlook è lunga perché spiega l’errore da zero, serve come riferimento e non è essenziale per un utente di Outlook per agire sul problema.
Che cos’è una connessione TCP e come può interrompersi?
Internet è una rete a pacchetti commutati. L’unità di base dell’informazione è un pacchetto di dati. Immaginate una busta, con un mittente e un destinatario e un insieme indivisibile di dati (dell’ordine delle decine di KB). La rete garantisce che tenta di consegnare un pacchetto e garantisce che se lo consegna, lo consegna alla destinazione giusta. Non garantisce che un pacchetto sia effettivamente consegnato, né l’ordine tra pacchetti sequenziali. È possibile che il mittente emetta A,B,C e che arrivi a destinazione C,A,B, oppure che arrivi C,B.
Uno dei livelli di rete superiori, il TCP, utilizza la rete Internet Protocol (IP) per produrre un canale ordinato di dati. Introduce fondamentalmente due garanzie: l’ordinamento dei pacchetti e la consegna garantita. A tal fine, introduce uno stato nel mittente e nel destinatario: un numero di sequenza. Il mittente conosce sempre il numero dell’ultimo pacchetto di cui è stata confermata la ricezione e il numero dell’ultimo pacchetto inviato. Il ricevitore conosce il numero dell’ultimo pacchetto ricevuto. Questo è sufficiente per ordinare dei tentativi per garantire la consegna e per smistare i pacchetti al ricevitore. Se si mette tutto insieme, si ottiene un circuito simile ai vecchi circuiti telefonici (ma digitale).
Una connessione TCP “cade” quando uno dei punti perde lo stato. Ad esempio, se un client cambia rete e ottiene un nuovo indirizzo IP, le connessioni TCP cadono, perché il server non sa nulla del “nuovo” client che appare. Ad esempio, un telefono cellulare che passa dalla rete wi-fi alla rete mobile perde tutte le connessioni TCP.
Per complicare ulteriormente le cose, poiché non esistono indirizzi IP per tutti i dispositivi connessi alla rete, è stata introdotta un’ulteriore complessità che ha creato più attori sulla connessione TCP: le reti private e i NAT (Network Address Translation). Se si osserva un PC sulla rete interna, si nota che l’IP proviene da un intervallo privato (192.168.*.* o 10.*.*.* in genere). Questi IP non esistono nei nodi di Internet. Sono stati riservati alle reti locali. Prima di “parlare” con la rete Internet pubblica, devono essere tradotti in un IP pubblico. In genere questo compito è svolto dal router in uscita della rete locale, fornito dall’ISP, che ha un IP pubblico che sarà condiviso da tutti i PC della rete locale. A tal fine, il router dispone di una tabella di stato che associa ogni connessione TCP a un indirizzo IP della rete interna.
Se un router esaurisce la memoria per la tabella di stato (chiamata tabella NAT), libera memoria “dimenticando” alcune connessioni TCP. Queste connessioni “cadono”. I router scelgono le connessioni che sono rimaste inattive più a lungo nel tentativo di causare poche interruzioni del servizio, ma non è garantito che la connessione sia effettivamente inattiva. Il mittente e il destinatario non sono a conoscenza di questa caduta, finché non provano a comunicare.
Le connessioni e-mail IMAP sono connessioni TCP. La modalità operativa è fondamentalmente la seguente: il client apre la connessione, si aggiorna sullo stato del server (quali nuovi messaggi ci sono, quali messaggi sono stati cancellati, l’elenco delle cartelle, ecc. In questa modalità, attende una notifica dal server che indica che lo stato è cambiato (in genere, che è arrivato un nuovo messaggio). Questa connessione TCP è aperta e si interrompe senza alcuna comunicazione. È un candidato ovvio per un router che vuole liberare spazio sul tavolo NAT. Quindi, calano regolarmente.
Il fatto che una connessione IMAP cada nello stato IDLE è considerato normale. È inutile cercare di lavorare sulla rete per evitare che le connessioni cadano. Si tratta di un lavoro infruttuoso, perché si lotterebbe contro un comportamento predefinito.
Quando una connessione IMAP IDLE cade, il client non riceve la notifica della nuova posta. Il server, quando invia la notifica, otterrà una risposta dal router che non ha una connessione aperta e chiuderà la connessione (l’errore è solitamente “connessione resettata dal peer”). La connessione deve essere riaperta dal client, quindi il server non può fare nulla e attende che il client risolva la caduta della connessione. Poiché è considerato normale, client e server inviano regolarmente (ogni 5 minuti) un NOOP. In pratica, un comando per dire “sono ancora qui”, per testare la connessione. Se il comando fallisce, il protocollo prevede che il client apra una nuova connessione.
È qui che si trova il fallimento di Outlook. Quando NOOP non riesce, Outlook non apre una nuova connessione. Perde la connessione che aveva con il server e non si apre più. Lo apre solo quando un’azione dell’utente lo costringe a farlo. Il pulsante Invia/Ricevi è inefficace; tutto ciò che fa è elencare le cartelle di uso speciale (Bozze, Cestino, ecc.), ma non la Posta in arrivo. Outlook è “pigro” e presume di non dover controllare la Posta in arrivo perché è coperta dalla connessione IMAP inattiva (che nel frattempo è fallita).
Le due azioni che hanno come effetto collaterale la riapertura della connessione IMAP da parte di Outlook sono:
- Aprire un’altra cartella e riaprire la Posta in arrivo (ad esempio, fare clic su Bozze e tornare alla Posta in arrivo)
- Mettere Outlook in modalità offline e poi di nuovo in modalità online.