Le email inviate al dominio Gmail improvvisamente non sono conformi a RFC 2822, è possibile ignorare Google Apps?

10

Quattro giorni fa le e-mail inviate ai nostri account Gmail tramite i nostri servizi di posta dell'ISP hanno iniziato a essere respinte a causa del fatto che non erano denuncianti di RFC 2822.

Il seguente messaggio a non è stato recapitato. Il motivo del problema:
5.3.0 - Altro problema con il sistema di posta 550-'5.7.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Il nostro sistema ha rilevato che \ n5.7.1 questo messaggio è non conforme a RFC 2822 . Per ridurre la quantità di spam \ n5.7.1 inviata a Gmail, questo messaggio è stato bloccato. Per ulteriori informazioni, consultare le specifiche \ n5.7.1 RFC 2822.
iw4si27447595pac.153 - gsmtp '

È frustrante perché queste e-mail funzionano bene da oltre un anno, suppongo che Google abbia aumentato i loro filtri nell'ultima settimana.

L'indirizzo email a cui stiamo tentando di inviare appartiene al nostro account Google Apps for Business. Mi chiedo, c'è un modo per ignorare il filtro di conformità RFC 2822 per consentire alle e-mail di passare?

Finora, l'aggiunta del nome di dominio degli ISP alla whitelist di spam nelle impostazioni di Gmail (nel pannello di controllo delle app) non ha funzionato.

Il registro telnet per il messaggio rifiutato in questione è:

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 la pena notare che la macchina che invia le e-mail non ha la possibilità di aggiungere server smtp che richiedono una password, quindi dobbiamo usare il server del nostro ISP ...

— OrangeBox

12

RFC2822 dice Data: e da: sono richieste le intestazioni (sezione 3.6). Sembra che Google ti lascerà andare semplicemente aggiungendo un'intestazione Da: però, ad esempio:

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

— probabilmente
fonte

ah, grazie dovrò vedere se lo sviluppatore del software può apportare questa modifica. Sai se è possibile sovrascrivere i filtri lato server di posta Gmails quando usi Gapps?

— OrangeBox

6

Guarda i duplicati Da: intestazioni o Rispondi a: intestazioni che non coincidono. Lo stesso problema è stato riscontrato da un numero di utenti di Outlook per Mac che avevano erroneamente migrato ulteriori informazioni sull'intestazione dai precedenti account client di posta. Vedi http://hintsforums.macworld.com/showthread.php?p=718579

— Steve Hoge
fonte

Grazie per la risposta! Ho votato per eccesso ma non ho accettato perché spero di trovare un modo per ignorare il filtro visto che stiamo utilizzando Google Apps for Business. qualche idea?

— OrangeBox,

@OrangeBox Non credo che ci sia un'opzione, ma perché non presentare una richiesta di feedback con Google ?

— poolie,

Una cosa interessante è che le Fromintestazioni multiple sono state consentite da RFC822, ma non sono più consentite da RFC2822 (pubblicato nel 2001).

— poolie,

1

Ho uno script PHP che invia notifiche ogni giorno, con campi creati da un database. Alla fine di ogni campo, il programmatore aveva usato \r\nper terminare le righe (sia i caratteri di ritorno a capo che quelli di avanzamento riga). Questo non ha alcun senso, ma ha funzionato fino ad ora.

Ho eliminato il \rpersonaggio e all'improvviso le mie e-mail sono ora conformi a RFC 2822.

— user2375103
fonte

1

Questo è un bug qualunque cosa stia facendo la validazione. RFC 822 teoricamente consentiva caratteri CR e LF separati, che non sono terminazioni di riga, ma RFC 2822 rimuove questa funzione. RFC 2822 sezione 2.3 afferma che "CR e LF DEVONO presentarsi solo insieme come CRLF; NON DEVONO apparire in modo indipendente nel corpo".

Quello che ha fatto il programmatore è il reclamo RFC 2822 e la tua versione no. Come sviluppatore preferisco i feed a riga singola ma l'utilizzo di CRLF nell'e-mail è un requisito assoluto. Idealmente un MUA capirà ogni ragionevole limite di linea.

— Duncan Simpson
fonte