Os e-mails enviados para o domínio do Gmail repentinamente não são compatíveis com RFC 2822. É possível ignorar o Google Apps?

10

Há quatro dias, os e-mails enviados para nossas contas do Gmail por meio dos serviços de correio do nosso provedor começaram a ser rejeitados por não serem os queixosos da RFC 2822.

A seguinte mensagem para não foi entregue. O motivo do problema:
5.3.0 - Outro problema no sistema de correio 550-'5.7.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Nosso sistema detectou que \ n5.7.1 esta mensagem é não é compatível com RFC 2822 . Para reduzir a quantidade de spam \ n5.7.1 enviada ao Gmail, esta mensagem foi bloqueada. Consulte \ n5.7.1 especificações RFC 2822 para obter mais informações.
iw4si27447595pac.153 - gsmtp '

É frustrante porque esses e-mails estão funcionando bem há mais de um ano - presumo que o Google tenha aumentado seus filtros na última semana.

O endereço de e-mail para o qual estamos tentando enviar pertence à nossa conta do Google Apps for Business. Gostaria de saber, existe uma maneira de substituir o filtro de conformidade RFC 2822 para permitir que os emails sejam enviados?

Até o momento, a adição do nome de domínio do provedor de serviços de Internet à lista de permissões de spam nas configurações do Gmail (no painel de controle do Google Apps) não funcionou.

O log do telnet para a mensagem rejeitada em questão é:

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
fonte

Vale notar que a máquina de envio de e-mails esquentar têm a capacidade de adicionar servidores SMTP que requerem uma senha, por isso temos de usar o servidor de nosso ISP ...

— OrangeBox

12

RFC2822 diz Data: e De: cabeçalhos são necessários (seção 3.6). Parece que o Google permitirá que você apenas adicione um cabeçalho De:, por exemplo:

[..]
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

— provavelmente
fonte

ahh, obrigado, vou ter que ver se o desenvolvedor do software pode fazer essa alteração. Você sabe se é possível substituir os filtros do servidor de correio do Gmail ao usar o Gapps?

— OrangeBox

6

Observe os cabeçalhos duplicados de: ou Responder para: cabeçalhos que não coincidem. Esse mesmo problema ocorreu com vários usuários do Outlook para Mac que tinham informações extras de cabeçalho migradas erroneamente de contas de cliente de email anteriores. Consulte http://hintsforums.macworld.com/showthread.php?p=718579

— Steve Hoge
fonte

Obrigado pela resposta! Votei positivamente, mas não aceitei, porque espero encontrar uma maneira de substituir o filtro, pois estamos usando o Google Apps for Business. Alguma ideia?

— OrangeBox

@OrangeBox Acho que não há uma opção, mas por que não enviar uma solicitação de feedback ao Google ?

— poolieby

Uma coisa interessante é que vários Fromcabeçalhos foram permitidos pelo RFC822, mas não são mais permitidos pelo RFC2822 (publicado em 2001).

— poolieby

1

Eu tenho um script PHP que envia notificações todos os dias, com campos criados a partir de um banco de dados. No final de cada campo, o programador costumava \r\nterminar as linhas (caracteres de retorno de carro e avanço de linha). Isso não faz sentido, mas funcionou até agora.

Tirei o \rpersonagem e, de repente, meus e-mails agora estão em conformidade com a RFC 2822.

— user2375103
fonte

1

Isso é um bug que está fazendo a validação. Teoricamente, o RFC 822 permitiu caracteres CR e LF separados, que não são finais de linha, mas o RFC 2822 remove esse recurso. A seção 2.3 da RFC 2822 diz que "CR e LF DEVEM ocorrer apenas em conjunto como LCRF; NÃO DEVEM aparecer independentemente no corpo".

O que o programador fez é a reclamação RFC 2822 e sua versão não. Como desenvolvedor, prefiro feeds de linha única, mas usar o CRLF no email é um requisito absoluto. Idealmente, um MUA entenderá qualquer extremidade razoável da linha.

— Duncan Simpson
fonte