Les e-mails envoyés au domaine Gmail ne sont soudainement pas conformes à la RFC 2822, est-il possible de les contourner avec Google Apps?

Il y a quatre jours, les e-mails envoyés à nos comptes Gmail via les services de messagerie de notre FAI ont commencé à être rejetés car ils n'étaient pas plaignants RFC 2822.

Le message suivant à n'était pas livrable. La raison du problème:
5.3.0 - Autre problème de système de messagerie 550-'5.7.1 [2001: 44b8: 8060: ff02: 300: 1: 6: 6 11] Notre système a détecté que \ n5.7.1 ce message est non conforme à RFC 2822 . Pour réduire la quantité de spam \ n5.7.1 envoyé à Gmail, ce message a été bloqué. Veuillez consulter les spécifications \ n5.7.1 RFC 2822 pour plus d'informations.
iw4si27447595pac.153 - gsmtp '

C'est frustrant, car ces e-mails fonctionnent bien depuis plus d'un an. Je suppose que Google a augmenté ses filtres la semaine dernière.

L'adresse e-mail à laquelle nous tentons d'envoyer appartient à notre compte Google Apps for Business. Je me demande, existe-t-il un moyen de remplacer le filtre de conformité RFC 2822 pour permettre aux e-mails de passer?

Jusqu'à présent, l'ajout du nom de domaine des FAI à la liste blanche de spam dans les paramètres Gmail (dans le panneau de configuration des applications) n'a pas fonctionné.

Le journal telnet du message rejeté en question est le suivant:

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

RFC2822 indique Date: et De: les en-têtes sont requis (section 3.6). Il semble que Google vous permettra de vous en sortir en ajoutant simplement un en-tête From: par exemple:

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

Recherchez les en-têtes From: ou les en-têtes Reply-to qui ne correspondent pas. Ce même problème a été rencontré par un certain nombre d'utilisateurs d'Outlook pour Mac qui avaient des informations d'en-tête supplémentaires migrées par erreur à partir de comptes clients de messagerie précédents. Voir http://hintsforums.macworld.com/showthread.php?p=718579

J'ai un script PHP qui envoie des notifications tous les jours, avec des champs construits à partir d'une base de données. À la fin de chaque champ, le programmeur avait utilisé \r\npour terminer les lignes (à la fois les caractères de retour chariot et de saut de ligne). Cela n'a aucun sens, mais cela a fonctionné jusqu'à présent.

J'ai retiré le \rpersonnage et tout à coup mes mails sont désormais conformes à la RFC 2822.

C'est un bug quoi que ce soit qui fait la validation. La RFC 822 autorisait théoriquement des caractères CR et LF séparés, qui ne sont pas des fins de ligne, mais la RFC 2822 supprime cette fonctionnalité. La section 2.3 de la RFC 2822 indique que "CR et LF NE DOIVENT se produire qu'en tant que CRLF; ils NE DOIVENT PAS apparaître indépendamment dans le corps."

Ce que le programmeur a fait, c'est la plainte RFC 2822 et votre version ne l'est pas. En tant que développeur, je préfère les flux à ligne unique, mais l'utilisation de CRLF dans le courrier électronique est une exigence absolue. Idéalement, un MUA comprendra toutes les extrémités de ligne raisonnables.