it-swarm-es.com

Los correos electrónicos enviados al dominio de Gmail de repente no cumplen con RFC 2822, ¿es posible omitirlos con Google Apps?

Hace cuatro días, los correos electrónicos enviados a nuestras cuentas de Gmail a través de los servicios de correo de nuestro ISP comenzaron a ser rechazados por no ser demandantes de RFC 2822.

El siguiente mensaje a no se pudo entregar. La razón del problema:
5.3.0 - Otro problema del sistema de correo 550-'5.7.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Nuestro sistema ha detectado que\n5.7.1 este mensaje no cumple con RFC 2822. Para reducir la cantidad de spam\n5.7.1 enviado a Gmail, este mensaje ha sido bloqueado. Consulte\n5.7.1 RFC 2822 especificaciones para obtener más información.
iw4si27447595pac.153 - gsmtp '

Es frustrante porque estos correos electrónicos han funcionado bien durante más de un año. Supongo que Google ha subido sus filtros en la última semana.

La dirección de correo electrónico a la que intentamos enviar pertenece a nuestra cuenta de Google Apps for Business. Me pregunto, ¿hay alguna forma de anular el filtro de cumplimiento RFC 2822 para permitir que lleguen los correos electrónicos?

Hasta ahora, agregar el nombre de dominio del ISP a la lista blanca de spam en la configuración de Gmail (en el panel de control de Aplicaciones) no ha funcionado.


El registro de Telnet para el mensaje rechazado en cuestión es:

220-ipmail06.adl6.xxxxx.net ESMTP 220 ESMTP; eth2958.xxx.adsl.OurISP.net [150.xxx.xxx.xx1] in MTA
HELO WINDOWS-xxxxx (<- this is our server name) 
250 ipmail06.adl6.OurISP.net 
MAIL FROM: [email protected]
250 sender ok 
RCPT TO: [email protected]
250 recipient ok 
RCPT TO: [email protected]
250 recipient ok 
DATA 
354 go ahead 
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application. . 
QUIT 
250 ok: Message 716893804 accepted
10
OrangeBox

RFC2822 dice Fecha: y De: se requieren encabezados (sección 3.6). Parece que Google te permitirá salirte con solo agregar un encabezado From: aunque, por ejemplo:

[..]
DATA 
354 go ahead 
From: <[email protected]>   <-- add this
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application.
.
QUIT 
250 ok: Message 716893804 accepted 
12
probably

Esté atento a duplicados de: encabezados o Responder a: encabezados que no coinciden entre sí. Este mismo problema fue experimentado por varios usuarios de Outlook para Mac que tenían información de encabezado adicional migrada erróneamente de cuentas de clientes de correo anteriores. Ver http://hintsforums.macworld.com/showthread.php?p=718579

6
Steve Hoge

Esto es un error, lo que sea que esté haciendo la validación. RFC 822 teóricamente permitió caracteres CR y LF separados, que son no extremos de línea, pero RFC 2822 elimina esta característica. La sección 2.3 del RFC 2822 dice "CR y LF DEBEN aparecer juntos como CRLF; NO DEBEN aparecer independientemente en el cuerpo".

Lo que hizo el programador es la queja RFC 2822 y su versión no lo es. Como desarrollador, prefiero los canales de una sola línea, pero usar CRLF en el correo electrónico es un requisito absoluto. Idealmente, un MUA comprenderá cualquier final de línea razonable.

1
Duncan Simpson

Tengo una secuencia de comandos PHP que envía notificaciones todos los días, con campos creados a partir de una base de datos. Al final de cada campo, el programador había utilizado \r\n para finalizar las líneas (tanto el retorno de carro como los caracteres de avance de línea). Esto no tiene ningún sentido, pero funcionó hasta ahora.

Saqué el carácter \r y de repente mis correos ahora cumplen con RFC 2822.

1
user2375103