ISP. Informes Técnicos para la Recepción de Mensajes en Nora (última revisión 25.feb.2004)

Introducción:

Nora – Alnus Internet, S.L. (en adelante : NORA), en un esfuerzo por minimizar el impacto continuo que provoca el SPAM (correo no solicitado), y formando parte del conjunto de medidas que se están tomando entre los ISP (Proveedores de Servicios Internet) del mundo, estamos implementando las reglas y mecanismos más adecuados que, de acuerdo con estándares de internet (RFC), permitan bloquear a los sitios más frecuentemente generadores de SPAM y VIRUS.

Los protocolos para enviar correo SMTP a través de internet han sido establecidos hace muchos años en los siguientes documentos y posteriores revisiones:

  • RFC 821 SIMPLE MAIL TRANSFER PROTOCOL (August 1982)
  • RFC 1035 DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION (November 1987)
  • RFC 974 MAIL ROUTING AND THE DOMAIN SYSTEM (January 1986)
  • RFC 1123 Requirements for Internet Hosts — Application and Support (October 1989)
  • RFC 2821 Simple Mail Transfer Protocol (April 2001)

En estos documentos se especifica como han de configurarse los servidores que pretendan enviar y recibir correo SMTP mediante la interconexión con otros servidores SMTP. Especifican como han de llamarse, como han de estar configurados sus DNS, y que protocolo de intercambio de datos ha de seguirse.

Hasta la fecha, la normativa se venía aplicando de forma relajada, permitiendo que servidores que incumplian alguno de los protocolos pudieran enviar correo sin que supusiera ningún trastorno a quienes enviaban o recibían correo. Desde hace un tiempo para aquí, los buzones de los usuarios legítimos se ven inundados de correo no deseado y que en muchos casos además llevan virus y troyanos. A este problema se añade el que cada día son más el número de mensajes de devolución que se generan lo que esta haciendo que las colas de entrega se vean saturadas de mensajes que nunca se van a poder entregar porque el remitente, el destinatario o simplemente el servidor que los envió, ya no existe o se ha desconectado una vez que ha enviado sus mensajes.

Ante todas estas circustancias, los usuarios solicitan a su proveedor que solucionen estos problemas. Para poder atajar el problema del SPAM y VIRUS es necesario, en una primera fase, poder identificar claramente que sitios estan generando SPAM y VIRUS, y en una segunda fase, aplicar reglas y filtros que corten la conexión con dichos sitios.

La aplicación extricta de las normas que regulan los protocolos de internet mencionados anteriormente puede provocar que servidores, incorrectamente configurados, que hasta ahora venían enviando correo con regularidad, a partir de ahora, como consecuencia de la aplicación de las normas establecidas, no podrán hacerlo.

En este caso, no serán los demás quienes le impidan enviar sus mensajes, si no ellos mismos al no tener mínimamente bien configurados sus servidores.

Es muy importante resaltar que cada violación en las normas está suponiendo un agujero que los SPAMMERS aprovechan para la distribución masiva de correo, con el consiguiente coste y trastorno económico que ello supone para toda la comunidad.

REQUERIMIENTOS TECNICOS MINIMOS APLICABLES PARA DISTRIBUIR CORREO A LOS SERVIDORES DE NORA

Los siguientes requerimientos técnicos son de aplicación en las conexiones que realizan servidores de correo que pretendan enviar correo a servidores de correo de NORA y por extensión a los clientes alojados en NORA.

El fin de todas y cada una de las reglas tiene como objetivo primordial identificar de forma inequívoca los servidores de correo que tratan de enviar correo a NORA.

Las siguientes normas son de aplicación para mensajes de correo procedentes de internet que tratan de ser distribuidos a través de nuestros servidores (modalidad de correo MX).

Estas reglas NO SON APLICABLES al envío de correo por parte de nuestros clientes (correo SMTP), ni para la recepción de mensajes por nuestros clientes (correo POP e IMAP).

  • Los servidores de NORA no aceptarán conexiones de sistemas inseguros. Estos incluyen "open relays", "open proxies", "open routers" o cualquier otro tipo de sistema que se determine que esta disponible para usos no autorizados.
  • Los servidores de NORA no aceptarán conexiones de sistemas que usan direcciones IP dinámicas.
  • Los servidores de NORA pueden rechazar las conexiones desde direcciones IP que no tengan configurada correctamente su dirección directa e inversa (registros PTR, A, y MX del DNS).
  • Los servidores que deseen enviar correo a NORA necesitan tener configurados correctamente sus registros A y PTR para su servidor de correo. NO es necesario que disponga de registro MX para el servidor que envia correo.
  • Los servidores que deseen enviar correo a NORA tendrán configurados registros MX para los dominios sobre los que envían correo de forma que sea posible generar y enviar mensajes de error cuando sea preciso.
  • Los servidores que deseen enviar correo a NORA anunciarán su servidor con un FQDN "Full Qualified Domain Name" en tiempo de conexión (HELO/EHLO) y tenga el correspondiente registro PTR, A en su DNS
  • NORA puede rechazar las conexiones de servidores cuyos destinatarios sistemáticamente contengan más de un 10% de direcciones erróneas, o provoquen más de un 10% de mensajes de error (bounce messages), por ejemplo a modo enunciativo listas de correo.
  • NORA puede rechazar conexiones que no acepten un mínimo del 90% de mensajes de devolución a los remitentes de los mensajes de sus servidores (mailer-daemon failure/error messages).
  • La queja reiterada de clientes de NORA puede ser utilizada como base para rechazar las conexiones de determinados servidores.
  • NORA ofrecerá el motivo por el cual se rechaza un mensaje, en idioma ingles y/o español cuando ello fuera posible, de tal forma que los administradores de sistemas remotos puedan subsanarlos.
  • NORA no autoriza al uso de sus ordenadores y redes para aceptar, transmitir o distribuir correo no deseado SPAM conforme a la normativa vigente. Existe un buzón abuse@nora.net donde se puede informar de este tipo de incidentes. NORA puede confirmar la recepción de mensajes en este buzón o en determinados casos pedir más información a quien originó la reclamación.

La aplicación de cada una de las reglas enumeradas se hará de la forma que suponga el menor impacto posible.

Queremos resaltar que las normas RFC aplicadas están en vigor desde hace años por lo que cualquier servidor de correo deberá implementarlas desde su instalación. Máxime si hablamos de servidores instalados con posterioridad a Abril de 2001, fecha de la última revisión del protocolo de envio de correo SMTP mencionado aquí.

Los sistemas y reglas enumerados han sido adoptados ya por la mayoría de grandes ISP dentro y fuera de España.

Sugerimos a los administradores de sistemas de correo que configuren estrictamente sus servidores de correo para poder conectar con sistemas remotos, en la confianza de que entenderán que la adhesión estricta a las normas RFC de sus servidores en ningún caso les supondrá motivo de rechazo de mensajes, y el caso de no hacerlo supone facilitar a los SPAMMERS continuar con su actividad.

PREGUNTAS Y RESPUESTAS FRECUENTES

  • ¿por qué motivo no se ha dado un plazo antes de aplicar la normativa RFC?
    La normativa que se ha procedido a aplicar extrictamente, data de los años 80 y la última revisión es de Abril de 2001.

    Ningún servidor instalado posteriormente a estas fechas debería incumplirla.

  • ¿no es posible que NORA anuncie que va aplicar extrictamente las normas RFC al resto de servidores?
    Técnicamente no es posible hacer esto. En la práctica no tiene sentido anunciar que vamos a aplicar las reglas del protocolo SMTP, cuando se supone que todos los servidores SMTP tienen que guiarse por este protocolo.
  • ¿a pesar de las medidas que estan tomando continúo recibiendo SPAM?
    Como hemos dicho anteriormente, en una primera fase, tratamos de identificar realmente a los servidores que se anuncian para enviar correo, sean quienes realmente dicen ser. La aplicación de esta medida ya ha supuesto un descenso en el número de spam recibido. Curiosamente, las máquinas destinadas al SPAM, suelen estar mejor configuradas y seguir los protocolos más correctamente que los servidores de algunos clientes.
  • ¿informan de alguna manera a los remitentes de que no les admiten sus correos?
    SI, cada conexión que rechazamos recibe un mensaje indicando el motivo en español, inglés, y una referencia a esta página. El mensaje lo recibe el servidor al que rechazamos la conexión, el cual, según las normas, generará un nuevo mensaje de error para su remitente original indicándole nuestros motivos de rechazo. Es el remitente quien deberá ponerse en contacto con su administrador para subsanar las deficiencias del envío del mensaje. El único responsable de que el mensaje no se pueda entregar es el servidor remitente. Él es quien tiene la llave para solventar sus deficiencias.
  • ¿que comprobaciones debo de hacer para saber si mi servidor cumple la normativa?
    Básicamente y a modo enuciativo :

    • deberá conectar desde una dirección IP fija, NO dinámica
    • la resolución inversa de la dirección IP deberá ofrecer el mismo nombre de host/dominio.
    • el anuncio de servidor en el helo debe ser "completo", es decir, nombre de host y dominio real en internet.
    • la resolución del anuncio de servidor helo debe corresponder a la IP desde la que conecta.
    • su servidor deberá aceptar mensajes de devolución y/o error
  • el administrador de un sistema de correo necesita unos días para revisar sus servidores. ¿Hay alguna forma de que temporalmente se le acepten los correos que envía?
    Si, hemos previsto un plazo extraordinario para aquellos servidores que no pueden adaptarlos a la normativa inmediatamente. Envie un mensaje a postmaster@nora.net indicando la IP y el nombre del servidor que desea que aceptemos temporalmente.
  • Nuestra empresa ha dejado de recibir correos importantes, ¿qué podemos hacer?
    Precisamente este es el motivo por el cual tratamos de identificar inequívocamente a los servidores que nos envían correo. Nuestra meta es evitar que "cualquiera en internet" pueda enviar mensajes falseando a los remitentes legales de correo. Su empresa y aquellos que les envian "mensajes importantes" son los más interesados en que nadie pueda falsificar sus conexiones. Si tiene identificados a los remitentes de los mensajes que ha dejado de recibir, hágaselo saber. Para un administrador de un sistema es relativamente sencillo adecuar correctamente sus servidores, y no debería ponerles ningun impedimento en solucionar algo que posiblemente para ellos también es un problema.
  • ¿no deberá cada cliente determinar que es SPAM y que no lo es?
    Efectivamente, el objetivo de NORA es cada cliente pueda determinar que es SPAM y que no lo es para él. Por este motivo, en la primera fase UNICAMENTE se rechazan las conexiones de los servidores que no se puede verificar que son quien dicen ser. Desde nuestro punto de vista (recepción de mensajes) no es posible técnicamente diferenciar que es una conexión de un servidor incorrectamente configurado de un servidor que esta falseando su identidad. Permitir este tipo de conexiones, implica aceptar todo el correo que envíe a cualquier cliente, no solo a Ud.
  • ¿qué tipo de comprobaciones han de cumplir los servidores de correo?
    Se comprueba que la dirección IP corresponde al nombre de servidor que dice ser. Por ejemplo, si un servidor conecta desde una IP 1.2.3.4 diciendo que es MINISTERIO.HACIENDA.ES, se comprobará :

    1) que la dirección IP 1.2.3.4 corresponde efectivamente al servidor de correo del "Ministerio de Hacienda".
    2) se comprobará que el servidor MINISTERIO.HACIENDA.ES tiene efectivamente la IP 1.2.3.4

    Por favor no nos pida, que para su comodidad y/o la del "Ministerio de Hacienda" no realicemos esta comprobación, ni nos diga que para usted no es importante si el Ministerio de Hacienda tiene o no ese servidor. Cada minuto recibimos miles de conexiones de servidores que roban las direcciones IP y los nombres de otros servidores gracias a medidas como estas.


Cada servidor de correo es responsable de los mensajes que envia

 

 

 

 

Publicado en noticias