En algunos entornos Outlook tarda mucho en notificar que hay correo nuevo.
El fallo se produce en todos los servicios de correo electrónico que permiten la sincronización (protocolo IMAP), ya sean servicios SaaS de correo electrónico o software de servidor de correo electrónico. También ocurre con los stacks de Microsoft, con Exchange en IMAP y, relevante porque demostrable, con el propio Office 365.
Este artículo explica el fallo de Outlook y presenta algunas soluciones para mitigar este fallo que es exclusivo de Outlook sin posibilidad de actuar en el lado del servidor para resolverlo.
El siguiente vídeo demuestra el fallo, con explicación de las causas, en el escenario en el que la pila es toda de Microsoft (Outlook conectado a una cuenta de Office 365).
Para mitigar el problema sugerimos las siguientes alternativas
- Las dos soluciones indicadas en el vídeo: consultar cualquier otra carpeta de Outlook y volver a la Bandeja de entrada fuerza la actualización (hacer clic en el botón Enviar/Recibir no sirve de nada), así como poner Outlook fuera de línea y luego volver a conectarlo;
- Mantén Outlook y compleméntalo con un notificador de correo electrónico. Una aplicación que se queda en la bandeja de Windows y sólo vigila si hay correo nuevo;
- Ignora las notificaciones de Outlook y confía en las del móvil;
- Un cambio completo de aplicación de correo electrónico (recomendamos Thunderbird de la Fundación Mozilla, que es gratuita para uso comercial).
Descripción técnica de la caída de Outlook
La causa del fallo es la incapacidad de Outlook para recuperarse de una interrupción de la conexión TCP push-mail. Cuando se cae una conexión push-mail, Outlook nunca se recupera sin intervención y, por tanto, no recibe notificaciones de correo nuevo.
La descripción del fallo de Outlook es larga porque explicamos el fallo desde el principio, sirve de referencia y no es imprescindible para que un usuario de Outlook pueda actuar sobre el problema.
¿Qué es una conexión TCP y cómo puede romperse?
Internet es una red de conmutación de paquetes. La unidad básica de información es un paquete de datos. Imaginemos un sobre, con un emisor y un receptor y un conjunto indivisible de datos (del orden de decenas de KB). La red garantiza que intenta entregar un paquete, y garantiza que si lo entrega, lo entrega al destino correcto. No garantiza que un paquete se entregue realmente, ni garantiza el orden entre paquetes secuenciales. Es posible que el emisor emita A,B,C y llegue al destino C,A,B, o que llegue C,B.
Una de las capas de red anteriores, TCP, utiliza la red del Protocolo de Internet (IP), para producir un canal ordenado de datos. Básicamente introduce dos garantías: ordenación de paquetes y entrega garantizada. Para ello, introduce un estado en el emisor y el receptor: un número de secuencia. El emisor siempre conoce el número del último paquete cuya recepción ha sido acusada y el número del último paquete enviado. El receptor conoce el número del último paquete recibido. Esto es suficiente para ordenar reintentos que garanticen la entrega, y para clasificar los paquetes en el receptor. Si lo juntamos todo, tenemos un circuito similar a los antiguos circuitos telefónicos (pero digital).
Una conexión TCP «cae» cuando uno de los puntos pierde el estado. Por ejemplo, si un cliente cambia de red y obtiene una nueva dirección IP, las conexiones TCP se caen, porque el servidor no sabe nada del «nuevo» cliente que aparece. Por ejemplo, un teléfono móvil que pasa de wi-fi a la red móvil pierde todas las conexiones TCP.
Para complicar aún más las cosas, al no existir direcciones IP para todos los dispositivos conectados a la red, se introdujo una complejidad adicional que creó más actores en la conexión TCP: las redes privadas y los NAT (Network Address Translation). Si miras un PC de la red interna, verás que la IP es de un rango privado (192.168.*.* o 10.*.*.* normalmente). Estas IP no existen en los nodos de Internet. Se han reservado para las redes locales. Antes de «hablar» con la Internet pública, tienen que traducirse a una IP pública. Normalmente, esta tarea la realiza el router de salida de la red local, proporcionado por el ISP, que tiene una IP pública que será compartida por todos los PC de la red local. Para ello, el router dispone de una tabla de estado que asocia cada conexión TCP a una dirección IP dentro de la red interna.
Si un router se queda sin memoria para la tabla de estado (llamada tabla NAT), libera memoria «olvidando» algunas conexiones TCP. Estas conexiones «caen». Los routers eligen las conexiones que llevan más tiempo inactivas para intentar causar pocas interrupciones del servicio, pero no se garantiza que la conexión esté realmente inactiva. El emisor y el receptor no conocen esta caída hasta que intentan comunicarse.
Las conexiones de correo electrónico IMAP son conexiones TCP. El modo de funcionamiento es básicamente el siguiente: el cliente abre la conexión, se actualiza sobre el estado del servidor (qué mensajes nuevos hay, qué mensajes se han borrado, lista de carpetas, etc.) y, a continuación, pasa al modo inactivo. En este modo, espera una notificación del servidor de que el estado ha cambiado (normalmente, que ha llegado un nuevo mensaje). Esta conexión TCP está abierta, y se detuvo sin comunicación. Es un candidato obvio para un router que quiera liberar espacio en la mesa NAT. Por lo tanto, caen regularmente.
El hecho de que una conexión IMAP caiga en el estado IDLE se considera normal. No tiene sentido intentar hacer funcionar la red para evitar que se caigan las conexiones. Es un trabajo infructuoso porque estarías luchando a brazo partido para cambiar el comportamiento por defecto.
Lo que ocurre cuando se cae una conexión IMAP IDLE es que el cliente no recibirá la notificación de correo nuevo cuando se produzca. El servidor, al enviar la notificación, recibirá una respuesta del router de que no tiene ninguna conexión abierta, y cerrará la conexión (el error suele ser «conexión restablecida por el peer»). La conexión tiene que ser reabierta por el cliente, por lo que el servidor no puede hacer nada, y espera a que el cliente solucione la caída de la conexión. Como se considera normal, el cliente y el servidor envían regularmente (cada 5min) un NOOP. Básicamente, un comando para decir «sigo aquí», para probar la conexión. Si el comando falla, el protocolo prevé que el cliente abra una nueva conexión.
Aquí es donde radica el fallo de Outlook. Cuando NOOP falla, Outlook no abre una nueva conexión. Pierde la conexión que tenía con el servidor y no se abre más. Sólo se abre cuando una acción del usuario le obliga a ello. El botón Enviar/Recibir es ineficaz; lo único que hace es listar las carpetas de uso especial (Borradores, Papelera, etc.), pero no la Bandeja de Entrada. Outlook es «perezoso» y asume que no necesita comprobar la bandeja de entrada porque está cubierta por la conexión IMAP inactiva (que desde entonces ha fallado).
Las dos acciones que tienen el efecto secundario de hacer que Outlook vuelva a abrir la conexión IMAP son:
- Abre otra carpeta y vuelve a abrir la Bandeja de entrada (por ejemplo, haz clic en Borradores y vuelve a la Bandeja de entrada)
- Ponga Outlook en modo Fuera de línea y vuelva a ponerlo en modo En línea.