Nuestra aplicación web envía mensajes de correo electrónico a las personas cuando alguien publica contenido nuevo. Tanto el remitente como el destinatario han optado por recibir mensajes de correo electrónico desde nuestra aplicación. Al preparar dicho mensaje, configuramos los siguientes encabezados SMTP:
DE: [email protected] PARA: [email protected] ENVIADOR: [email protected]
Elegimos usar la dirección de correo electrónico del autor en el encabezado FROM en un intento de proporcionar la mejor experiencia para el destinatario; cuando ven el mensaje en su cliente de correo, el autor es claro. Para evitar la apariencia de falsificación, agregamos el encabezado SENDER (con la dirección de correo electrónico de nuestra propia empresa) para dejar en claro que enviamos el mensaje en nombre del autor. Después de leer los RFC 822 y 2822, este parece ser un uso previsto del encabezado del remitente.
La mayoría de los servidores de correo receptores parecen manejar esto bien; el mensaje de correo electrónico se entrega normalmente (suponiendo que el buzón del destinatario exista, que no exceda la cuota, etc.). Sin embargo, al enviar un mensaje DESDE una dirección en un dominio A una dirección en el mismo dominio, algunos dominios receptores rechazan los mensajes con una respuesta como:
571 IP incorrecta - psmtp (en respuesta al comando RCPT TO)
Creo que esto significa que el servidor receptor solo vio que la dirección del encabezado FROM estaba en su propio dominio, y que el mensaje se originó en un servidor que no consideraba autorizado para enviar mensajes para ese dominio. En otras palabras, el servidor receptor ignoró el encabezado SENDER.
Tenemos una solución alternativa: la aplicación web mantiene una lista de dichos dominios que parecen ignorar el encabezado SENDER, y cuando los encabezados FROM y TO están en dicho dominio, establece el encabezado FROM en nuestra propia dirección de correo electrónico. Pero esta lista requiere mantenimiento.
¿Hay una mejor manera de lograr la experiencia deseada? Nos gustaría ser un "buen ciudadano" de la red, y todas las partes involucradas, remitentes y destinatarios, desean participar y recibir estos mensajes. Una alternativa es usar siempre la dirección de correo electrónico de nuestra empresa en el encabezado FROM y anteponer el nombre / dirección del autor al tema, pero esto parece un poco torpe.
From: authorlugar deFrom: [email protected]?Respuestas:
Estás mirando las cosas equivocadas. Esos son los encabezados de los mensajes . Deberías estar mirando el sobre SMTP . (La forma en que se especifica el sobre depende de cómo, exactamente, su aplicación envía el correo al sistema de correo. En muchos sistemas, el sobre se especifica mediante argumentos de línea de comandos al programa de utilidad de envío de correo). Dependiendo exactamente de cuándo en la transacción del protocolo decide emitir esa respuesta 571, es posible que el servidor de retransmisión SMTP ni siquiera haya visto los encabezados de los mensajes.
El texto de respuesta dice que el administrador de ese servidor de retransmisión SMTP en particular con el que está hablando ha restringido lo que puede poner en el sobre SMTP. Parece quejarse de la parte del destinatario del sobre. Pero puede estar aplazando la validación del remitente del sobre hasta la especificación del primer destinatario, por lo que puede quejarse del remitente.
Tenga en cuenta que el remitente del sobre es donde se envían los mensajes de estado de entrega, y no querrá que se dirijan a personas aleatorias de todo el mundo. (Aparte del hecho de que a muchas personas no les gusta esto, no tiene sentido que los mensajes de estado de entrega de su correo sean devueltos a nadie más que a usted). Especifíquese como el remitente del sobre.
Es incorrecto requerir
MXregistros de recursos, por cierto. Se puede ubicar un servidor de retransmisión SMTPAyAAAAregistros de recursos en ausencia deMXregistros de recursos. Ver RFC 5321 § 5.1.fuente
Podría estar equivocado, pero la causa más probable del error anterior, especialmente en el caso de Postini, es que los dominios en los que lo rechazan tienen una estricta política SPF. La mayoría de los servidores de correo con comprobación de SPF verifican solo el encabezado De: no les importará el encabezado del Remitente.
Para verificar si este es el caso, ejecute "dig + short TXT domain.com", donde domain.com es el mensaje de error. Deberías recuperar algo como:
La parte importante es el -todos. Esto significa que el propietario del dominio ha declarado que solo enviarán correos electrónicos desde los servidores que actúan como sus servidores de correo, todos los demás correos serán rechazados.
Afortunadamente, si este es el caso, puede verificar activamente antes de enviar el correo electrónico. Haga que la aplicación web haga una comprobación de SPF cuando el usuario ingrese su dirección de correo electrónico. Si existe una política estricta, agregue el dominio a su lista. No hay escasez de bibliotecas para todos los idiomas que pueden hacer comprobaciones de SPF.
fuente