web-dev-qa-db-fra.com

Les e-mails envoyés au domaine Gmail ne sont plus conformes à la norme 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 serveurs de messagerie de notre fournisseur de services Internet ont commencé à être rejetés car ils n'étaient pas le plaignant RFC 2822.

Le message suivant à était non distribuable. La raison du problème:
5.3.0 - Autre problème lié au système de courrier électronique 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 n'est pas conforme à la norme RFC 2822. Pour réduire la quantité de courrier indésirable\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 courriels fonctionnent bien depuis plus d’un an. Je suppose que Google a renforcé leurs filtres au cours de la semaine écoulée.

L’adresse e-mail à laquelle nous essayons d’envoyer appartient à notre compte Google Apps for Business. Je me demande s'il existe 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 du fournisseur d'accès à la liste blanche de courrier indésirable 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: [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
gmailgoogle-appsspam-prevention
10
OrangeBox

RFC2822 dit Date: et De: les en-têtes sont obligatoires (section 3.6). Il semble que Google vous laissera sortir en ajoutant simplement un en-tête De: par exemple:

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

Surveillez les doublons de: en-têtes ou Reply-to: en-têtes qui ne se 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

6
Steve Hoge

Ceci est un bug quel que soit le processus de validation. La RFC 822 autorisait théoriquement les caractères CR et LF séparés, qui sont pas fins de lignes, mais la RFC 2822 supprime cette caractéristique. La section 2.3 de la RFC 2822 stipule que "CR et LF DOIVENT apparaître uniquement ensemble comme 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 nécessité absolue. Idéalement, une MUA comprendra toute fin de ligne raisonnable.

1
Duncan Simpson

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

J'ai sorti le caractère \r et soudain mes mails sont maintenant conformes à la norme RFC 2822.

1
user2375103