550 5.7.1 Sender ID (PRA) Not Permitted.

Publicado el 21 de septiembre de 2014 • 4 min lectura • 830 palabras
Fallido Spf Sender ID Postmaster

Algunos de los emails que envío me vienen devueltos con el mensaje de error 'SMTP diagnostic: 550 5.7.1 Sender ID (PRA) Not Permitted'. ¿Qué es esto y qué puedo hacer al respecto?

Advertencia. Este artículo contiene información técnica acerca de cómo funcionan las comunicaciones email y acerca de algunas consideraciones sobre seguridad email. Aunque el problema planteado aquí puede ser fácilmente resuelto, por favor lee este artículo para entender sus causas y las implicaciones de cada una de las soluciones propuestas.

Sender ID es una propuesta anti-spoofing del antiguo grupo de trabajo IETF MARID que trató de unirse a Sender Policy Framework (SPF) y a Caller ID. Sender ID se define principalmente en Experimental RFC 4406, pero hay partes adicionales en RFC 4405, RFC 4407 y RFC 4408.

Sender ID intenta mejorar una deficiencia principal en SPF: que SPF no verifica las direcciones de cabecera que indica la parte que envía. Dichas direcciones de cabecera normalmente se muestran al usuario, y se utilizan para responder a los correos electrónicos. De hecho dichas direcciones de cabecera pueden ser diferentes de la dirección que SPF intenta verificar; es decir, SPF comprueba sólo la dirección del 'MAIL FROM', también llamado el remitente del sobre.

Sin embargo, hay muchos campos del encabezado de correo electrónico que son similares y que contienen todos ellos información de la parte remitente; por lo tanto, Sender ID define en el RFC 4407 una Purported Responsible Address (algo así como Dirección Pretendidamente Responsable o PRA), así como un conjunto de reglas heurísticas para determinar esta dirección de entre los muchos encabezados típicos de un correo electrónico.

Qué tiene esto que ver con mi problema

En esencia, además de verificar la dirección del 'MAIL FROM', un servidor de correo que aplique Sender ID puede también verificar si la dirección IP desde la que enviamos tu email coincide con los registros SPF de la dirección de cabecera. En caso de que tu dominio tenga un registro SPF definido como Hardfail en el que no se listen nuestras direcciones IP, tu email será rechazado como no legítimo.

Qué puedo hacer para solventar este problema

Hay varias cosas que puedes hacer:

  • Lista nuestro rango de IPs en tu registro SPF. Al hacerlo, tu registro SPF seguirá protegiendo a terceros ante emails falsificados que pretendan ser tuyos, a la vez que nos autoriza como una fuente legítima de los emails que envías. Contacta con Soporte para instrucciones.
  • Cambia tu registro SPF de Hardfail a Softfail. Al hacerlo, un email tuyo que provenga de nuestras IPs todavía podrá parecer sospechoso a los demás, pero ya será decisión del servidor de correo del destinatario el aceptarlo como legítimo o no.
  • Pídenos que actuemos. Este inconveniente del Sender ID no solo nos afecta a nosotros: afecta a cualquier servicio de redireccionamiento o de listas de correo que envía emails en nombre de otros. Consciente de ello, Sender ID debía aportar alguna forma de identificar como legítimo cualquier email legítimamente reenviado por otros. Y la hay: Sender ID propone que añadamos una línea a la cabecera del email, de manera que el servidor de correo del destinatario entienda que estamos reenviando un email originalmente enviado por ti. Esta solución sin duda resuelve el problema: sin embargo y como citamos a continuación (traducción del original de la Wikipedia), entre la comunidad de Internet no hay consenso acerca de si entra o no en conflicto con el estándard Simple Mail Transfer Protocol. Por esta razón, solamente aplicaremos esta solución bajo demanda y cuando no exista más remedio.

Cuestiones de normalización

La pra tiene la desventaja de que los que reenvían y las listas de correo sólo pueden soportarlo mediante la modificación de la cabecera del correo, por ejemplo, insertando un Sender o un Resent-Sender. Este último viola el RFC 2822 y puede ser incompatible con el RFC 822.

Con SPF, las listas de correo siguen trabajando como corresponde. Los que reenvían y que quieran soportar SPF sólo necesitan modificar el SMTP MAIL FROM y el RCPT TO, no el correo. Esto no es un concepto nuevo; con el RFC 821 original, los que reenvían siempre añaden su nombre de host en la ruta inversa del MAIL FROM.

El punto más problemático de la especificación fundamental de Sender ID es su recomendación para interpretar las políticas v=spf1 como ahora spf2.0/mfrom,pra en vez de spf2.0/mfrom.

Esta nunca fue la intención de todos los borradores SPF publicados desde el año 2003, y por un indeterminado gran número de políticas v=spf1 una evaluación para pra podría causar resultados falsos en muchos casos en los que pra y mfrom son diferentes.

Este problema técnico — de hecho sólo cuatro caracteres ,pra en la especificación principal de Sender ID — fue la base de un recurso de apelación ante la Junta de Arquitectura de Internet (IAB). Antes, en respuesta a otra apelación la IESG ya señaló que Sender ID no puede avanzar en el seguimiento de las normas IETF sin abordar la incompatibilidad con un MUST en el RFC 2822.

La mayor parte del contenido de este artículo ha sido obtenido de la Wikipedia. Para saber más, por favor visita la página de la Wikipedia sobre Sender ID.