Outlook: Atraso na receção de mensagens

Em alguns ambientes o Outlook é muito lento a notificar que existe nova correspondência.

A falha é transversal a todos os serviços de email que permitem sincronização (protocolo IMAP), quer serviços SaaS de email, quer software de servidor de email. Acontece também com stacks Microsoft, com Exchange em IMAP e, relevante porque demonstrável, com o próprio Office 365.

Este artigo explica a falha do Outlook e apresenta algumas soluções para mitigar essa falha que é exclusiva do Outlook não havendo qualquer hipótese de atuar do lado do servidor para a resolver.

O seguinte vídeo demonstra a falha, com explicação das causas, no cenário em que a stack é toda Microsoft (Outlook ligado a uma conta Office 365).

Para mitigar o problema sugerimos as seguintes alternativas

As duas soluções indicadas no vídeo: consultar uma qualquer outra pasta do Outlook e regressar à Inbox força o refrescamento (clicar no botão Enviar/Receber não ajuda), bem como colocar o Outlook offline e depois de novo online;
Manter o Outlook e complementá-lo com um email-notifier. Uma aplicação que fica na tray do windows e que só vigia chegada de mail novo;
Desconsiderar as notificações do Outlook e confiar nas notificações do telemóvel;
Uma troca completa da aplicação de email (recomendamos o Thunderbird da Fundação Mozilla que é gratuito para utilização comercial).

Descrição técnica da falha do Outlook

Na base da falha está a incapacidade de o Outlook recuperar de uma quebra da ligação TCP push-mail. Quando uma ligação push-mail cai, o Outlook nunca mais recupera sem intervenção, e portanto não recebe notificações de novo mail.

A descrição da falha do Outlook é longa porque explicamos a falha desde a base, serve como referência, e não é essencial para que um utilizador do Outlook atue sobre o problema.

O que é uma ligação TCP e como pode quebrar?

A Internet é uma rede de pacotes (switched packet network). A unidade básica de informação é um pacote de dados. Imagine-se um envelope, com um remetente e um destinatário e um conjunto indivisível de dados (qualquer coisa na ordem das dezenas de KB). A rede garante que tenta entregar um pacote, e garante que, entregando, entrega no destino certo. Não garante que um pacote seja mesmo entregue, nem garante a ordem entre pacotes sequenciais. É possível que o emissor emita A,B,C e chegue ao destino C,A,B, ou que chegue C,B.

Uma das camadas de rede acima, TCP, usa a rede IP (Internet Protocol), para produzir um canal ordenado de dados. Basicamente, introduz duas garantias: ordenação dos pacotes, e garantia de entrega. Para fazer isto, introduz um estado no emissor e no receptor: um número de sequência. O emissor sabe sempre o número do último pacote cuja recepção foi confirmada e o número do último pacote enviado. O receptor sabe o número do último pacote recebido. Isto é suficiente para pedir repetições de envios e garantir a entrega, e para ordenar os pacotes no receptor. Junta-se tudo, e temos um circuito similar aos circuitos antigos de telefone (mas digital).

Uma ligação TCP "cai", quando um dos pontos perde o estado. Por exemplo, se um cliente mudar de rede e receber um endereço IP novo, as ligações TCP caem, porque o servidor não sabe nada sobre o cliente "novo" que lhe aparece. Por exemplo, um telemóvel a transitar de wi-fi para rede móvel perde as ligações TCP todas.

Para complicar ainda mais as coisas, porque não há endereços IP para todos os dispositivos ligados à rede, introduziu-se uma complexidade adicional que criou mais atores na ligação TCP: redes privadas e NATs (Network Address Translation). Se se observar um PC na rede interna, verifica-se que o IP é de uma gama privada (192.168.*.* ou 10.*.*.* tipicamente). Estes IPs não existem em nodos na Internet. Foram reservados para redes locais. Antes de "falarem" com a Internet pública, têm que ser traduzidos para um IP público. Tipicamente essa tarefa é feita pelo router de saída da rede local, fornecido pelo ISP que, este sim, tem um IP público que vai ser partilhado por todos os PCs da rede local. Para fazer esta tarefa, o router tem uma tabela de estados que associa cada ligação TCP a um endereço IP dentro da rede interna.

Se um router ficar sem memória para a tabela de estados (chama-se tabela NAT), liberta memória "esquecendo" algumas ligações TCP. Estas ligações "caem". Os routers escolhem as ligações que estão há mais tempo sem atividade, numa tentativa de causar pouca disrupção de serviço, mas não é garantido que a ligação esteja de facto inativa. Emissor e recetor não sabem desta queda, até que tentem comunicar.

As ligações de email IMAP são ligações TCP. O modo de funcionamento é basicamente este: O cliente abre a ligação, atualiza-se sobre o estado do servidor (que mensagens novas há, que mensagens foram eliminadas, lista de pastas, etc), e depois entra em modo idle. Neste modo, fica à espera de uma notificação do servidor de que o estado mudou (tipicamente, que chegou uma mensagem nova). Esta ligação TCP está aberta, e parada sem comunicação. É uma candidata óbvia para um router que queira libertar espaço na tabela NAT. Por isso, regularmente caem.

O facto de uma ligação IMAP cair em estado IDLE é considerado normal. Não vale a pena tentar trabalhar a rede para evitar que as ligações caiam. É trabalho infrutífero porque se estaria a lutar contra comportamentos padrão difíceis de alterar.

O que acontece quando uma ligação IMAP IDLE cai é que o cliente não vai receber a notificação de novo mail quando esta acontecer. O servidor, quando enviar a notificação, vai receber uma resposta, do router, de que este não tem qualquer ligação aberta, e vai fechar a ligação (o erro é normalmente "connection reset by peer"). A ligação tem que ser reaberta pelo cliente, portanto o servidor não pode fazer nada, e fica à espera que o cliente corrija a queda de ligação. Por ser considerado normal, cliente e servidor regularmente (a cada 5min) mandam um NOOP. Basicamente, um comando para dizer "ainda estou aqui", para testar a ligação. Se o comando falhar, o protocolo prevê que o cliente abra nova ligação.

É aqui que que está a falha do Outlook. Quando o NOOP falha, o Outlook não abre nova ligação. Perde a ligação que tinha ao servidor, e não abre mais nenhuma. Abre-a apenas quando uma ação do utilizador obriga. O botão de Enviar/Receber é ineficaz; a única coisa que faz é listar os special-use folders (Rascunhos, Lixo, etc), mas não a Inbox. O Outlook é "preguiçoso" e assume que não precisa de verificar a Inbox porque isso está coberto pela ligação IMAP idle (que entretanto falhou).

As duas ações que têm o efeito secundário de fazer com que o Outlook reabra a ligação IMAP são:

Abrir outra pasta e abrir de novo a Inbox (ex. clicar em Rascunhos e de novo na Caixa de Entrada)
Colocar o outlook em modo Offline e de novo em modo Online.