Las listas de correo ¿condenadas a desaparecer?

El futuro inmediato del correo electrónico parece que apunta en esa dirección. Las medidas de seguridad que se están desarrollando para evitar los crecientes ataques de spam suponen trabas para la comunicación por correo y los sistemas de comunicación en grupo tradicionales, como las listas de correo.

El email es un protocolo de envío de mensajes muy veterano conocido como SMTP. En este protocolo los mensajes son texto plano, incluídas las imágenes y toda la información para el envío (responder, calificación de spam, etc.) se va añadiendo al principio del mensaje como metadatos según el mensaje va pasando por los diferentes sistemas.

Esta información también llamada "cabeceras del mensaje" se puede trucar con relativa facilidad y muchas mentes malignas han venido aprovechándose de esta debilidad para enviar correo malicioso o spam.

Un caso que se da muy a menudo es la suplantación de identidad. Se puede crear un correo enviado a fulanito@midominio.com haciéndote pasar por menganito@midominio.com, aunque el mensaje se envíe realmente desde spammer@otrodominio.com.

Seguridad creciente

Para reducir las posibilidades de engañar a los sistemas se han venido implementando varias medidas de seguridad a lo largo de los años. El antispam es una de ellas. Aceptar correos solo enviados a través de una conexión segura (SSL), aceptar solo correo enviado desde una IP de servidor y no desde una IP doméstica y otras cuantas comprobaciones... que no son infalibles.

Las Listas Negras son otra de las medidas de seguridad comunes. Consisten en múltiples listas de dominios e IP, mantenidas por diferentes organizaciones, que no tienen comunicación entre ellas, ni si quiera criterios comunes. Muchos proveedores configuran su servidor de correo para consultar estas listas y ver si la IP de otrodominio.com o el propio dominio está en alguna de ellas. Si aparece, el proveedor puede decidir si aumentar la puntuación de SPAM o directamente rechazar el mensaje.

Recientemente se están potenciando otras medidas, sobre todo por los grandes proveedores de correo gratuito: Yahoo, Gmail y Microsoft (léase yahoo.com, yahoo.es, gmail.com, hotmail.com, hotmail.es, outlook.com, msn.com, etc.).

Estas medidas persiguen dos objetivos: primero, asegurar que el email que se envía está realmente enviado desde una dirección permitida; segundo, qué hacer con los que no cumplen la regla, rechazarlos, ponerlos en cuarentena o nada y dejar pasar el mensaje.

Estás técnicas se implementan gradualmente y de manera encadenada. En primer lugar estaría el convenio SPF (https://es.wikipedia.org/wiki/Sender_Policy_Framework), seguidamente iría el mecanismo de autenticación DKIM (https://es.wikipedia.org/wiki/DomainKeys_Identified_Mail) que solo funciona con SPF correctamente implementado y por último otro mecanismo de validación y autenticación DMARC (https://en.wikipedia.org/wiki/DMARC), que sin las otras dos medidas correctamente configuradas no funciona.

Menos DKIM, que requiere que el servidor de correo firme con una clave única por dominio el correo saliente de ese dominio, todas ellas son configuradas en el dominio de envío como registros de tipo TXT.

Así pues y volviendo al ejemplo de suplantación de identidad, nos encontrábamos que el servidor de correo en midominio.com recibe un correo para fulanito@midominio.com desde menganito@midominio.com. Si implementásemos las últimas medidas en seguridad los pasos serían:

1. El servidor de correo comprobará en el registro del dominio de tipo SPF si otrodominio.com puede enviar como si fuera midominio.com. Si no es así puede aceptar o rechazar y solo notificar que el envío ha sido rechazado.
2. Si acepta, comprobará que la clave DKIM (si la tiene) corresponde con la clave DKIM que se publicita para midominio.com. Si no es así puede marcar el mensaje como inseguro.
3. Y por último, con DMARC se fuerza que se cumpla tanto el SPF como el DKIM y rechazar definitivamente el mensaje.

Hay miles de servidores de correo en Internet. A día de hoy una parte muy pequeña de ellos implementa las medidas mencionadas. Alguno más SPF, solo algunos DKIM y prácticamente poquísimos DMARC. Además de establecer cada uno independientemente su propio criterio de aceptación, rechazo o rebote silencioso o no.

El panorama está así y podemos estar contentos de que la gran mayoría de correos lleguen a su destino. El problema es que las grandes operadoras que listábamos más arriba están paulatinamente forzando el cumplimiento estricto hasta el nivel DMARC. Aunque pueda parecer un movimiento positivo, hay un método de comunicación que sale gravemente perjudicado de esto: las listas o grupos de correo.

Como se ven afectadas las listas de correo

Dentro del mundo de las comunidades online, las listas de correo son una herramienta habitual e importantísima como espacios de organización, colaboración e intercambio de ideas.

Mandamos un correo a una única dirección como grupodetrabajo@midominio.com y nuestros compañeros de equipo reciben el mensaje y pueden responder al mismo creando un espacio de debate mediante mensajes de correo sin tener que añadir uno por uno todos los destinatarios del grupo a nuestro mensaje. El grupodetrabajo se convierte en una superentidad, pero no es difícil saber quién a opinado/aportado/rebatido qué, porque en la lista el remitente es el que envía, aunque al pulsar en el botón responder el destinatario real es la lista.

Ejemplo:

• fulanito@midominio.com escribe a grupodetrabajo@midominio.com
• otras 10 personas reciben el mensaje de fulanito@midominio.com en su buzón
• zipi@cualquierotro.com quiere responder al mensaje de fulanito@midominio.com
• dando a “Responder a” la dirección de respuesta es grupodetrabajo@midominio.com

En este caso, la medida DMARC prohibiría este proceso si estuviese configurada en el modo “rechazar” o “cuarentena”.

Por ejemplo, Yahoo ya ha cambiado su política DMARC al valor rechazo, con lo que los miembros de listas con correos yahoo.es/com no está recibiendo correo de esas listas.

Es previsible que en breve Gmail y Microsoft sigan el mismo camino, por lo que hay que buscar soluciones.

Algunas soluciones

La primera solución es hacer que el remitente no sea el email del que responde a la lista, si no la propia lista. Esto supone que en nuestros buzones sólamente viendo la lista de mensajes no sabríamos quién ha respondido, además los filtros de correo para organizar en carpetas dejarían de funcionar.

Este apaño parcial es el más popular entre el software de gestión de listas de correo. Consiste en cambiar el remitente de la siguiente manera:

Desde: "Fulanito via <grupodetrabajo@midominio.com>"

De esta manera en la lista de mensajes podríamos identificar quién ha escrito a la lista. Aunque no soluciona el tema de los filtros, que habría que rehacerlos de cualquiera de las maneras.

Otras soluciones son más complejas e incluyen incompatibilidad para leer los mensajes desde algunos programas de correo (como embeber el email dentro de otro email).

El uso de foros o similares basados en mensajería instantánea como RocketChat o Slack resolvería de manera automática este y otros problemas que va generando el correo SMTP. Estas soluciones pasan por un cambio organizativo que no todo el mundo está preparado para realizar, puesto que la centralización de las comunicaciones en el buzón del correo conlleva una comodidad innegable y es de facto el sistema más extendido.

El uso de foros supone muchas ventajas, pero nos obliga a utilizar una herramienta diferente a la habitual. Usando herramientas de foro estaríamos notificados por correo igualmente, pero al tratarse de mensajes directos desde la herramienta a nosotros no suponen ningún riesgo en el envío.