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

10

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 es no cumple con RFC 2822 . Para reducir la cantidad de spam \ n5.7.1 enviado a Gmail, este mensaje ha sido bloqueado. Por favor revise \ n5.7.1 RFC 2822 especificaciones para más información.
iw4si27447595pac.153 - gsmtp '

Es frustrante porque estos correos electrónicos han estado funcionando 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: account@OurISP.net
250 sender ok 
RCPT TO: admin@googleappsdomain.com
250 recipient ok 
RCPT TO: admin@DifferentGoogleAppsDomain.com
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

gmail google-apps spam-prevention

— OrangeBox
fuente

Vale la pena señalar que la máquina que envía los correos electrónicos no tiene la capacidad de agregar servidores smtp que requieren una contraseña, por lo que tenemos que usar el servidor de nuestro ISP ...

— OrangeBox

12

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: <account@OurISP.net>   <-- 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

— probablemente
fuente

ahh, gracias, tendré que ver si el desarrollador del software puede hacer este cambio. ¿Sabes si es posible anular los filtros laterales del servidor de correo de Gmail cuando se usan Gapps?

— OrangeBox

6

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

— Steve Hoge
fuente

¡Gracias por la respuesta! He votado a favor pero no acepto porque espero encontrar una manera de anular el filtro ya que estamos usando Google Apps para empresas. ¿Alguna idea?

— OrangeBox

@OrangeBox No creo que haya una opción, pero ¿por qué no presentar una solicitud de comentarios con Google ?

— Poolie

Una cosa interesante es que FromRFC822 permitió múltiples encabezados, pero RFC2822 ya no los permite (publicado en 2001).

— Poolie

1

Tengo un script 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\npara finalizar las líneas (caracteres de retorno de carro y avance de línea). Esto no tiene ningún sentido, pero funcionó hasta ahora.

Saqué el \rpersonaje y de repente mis correos ahora cumplen con RFC 2822.

— usuario2375103
fuente

1

Esto es un error, lo que sea que esté haciendo la validación. RFC 822 teóricamente permitió caracteres CR y LF separados, que no son extremos de línea, pero RFC 2822 elimina esta característica. La sección 2.3 del RFC 2822 dice que "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 las alimentaciones de línea única, pero usar CRLF en el correo electrónico es un requisito absoluto. Idealmente, un MUA comprenderá cualquier final de línea razonable.

— Duncan Simpson
fuente