Question Gmail rejette les emails. Openspf.net échoue aux tests


J'ai un problème avec Gmail.

Cela a commencé après qu'un de nos PC infecté par un cheval de Troie ait envoyé du spam pendant une journée à partir de notre adresse IP.

Nous avons résolu le problème, mais nous sommes entrés dans 3 listes noires. Nous avons corrigé ça aussi. Mais chaque fois que nous envoyons un email à Gmail, le message est rejeté:

J'ai donc consulté à nouveau le guide de Google Bulk Sender et trouvé une erreur dans notre enregistrement SPF et je l'ai corrigé. Google dit que tout devrait bien se passer après un certain temps, mais cela ne se produit pas. 3 semaines se sont déjà écoulées mais nous ne pouvons toujours pas envoyer d'e-mails à Gmail.

Notre configuration MX est un peu complexe, mais pas trop: nous avons un nom de domaine delo-company.com, il a son propre mail @ delo-company.com (celui-ci convient, mais les problèmes concernent le nom de sous-domaine corp.delo-company.com).

Le domaine Delo-company.com a plusieurs enregistrements DNS pour le sous-domaine:

corp                     A     82.209.198.147
corp                     MX    20 corp.delo-company.com
corp.delo-company.com    TXT   "v=spf1 ip4:82.209.198.147 ~all" 

(Je mets tout à des fins de test seulement, c’était avant tout)

Ces enregistrements concernent notre serveur d'entreprise Exchange 2003 au 82.209.198.147. Son nom de réseau local est s2.corp.delo-company.com. Ses salutations HELO / EHLO sont également s2.corp.delo-company.com.

Pour réussir la vérification EHLO, nous avons également créé des enregistrements dans le DNS de delo-company.com:

s2.corp                  A     82.209.198.147
s2.corp.delo-company.com TXT   "v=spf1 ip4:82.209.198.147 ~all" 

Si je comprends bien, les vérifications SPF doivent être transmises de cette manière: Le serveur OUT s2 se connecte à MX du destinataire (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX dit Ok et effectue une vérification SPF de HELO / EHLO. Il fait NSlookup pour s2.corp.delo-company.com et obtient les enregistrements DNS ci-dessus. Les enregistrements TXT indiquent que s2.corp.delo-company.com ne devrait provenir que de l’IP 82.209.198.147. Donc, il devrait être adopté.

Ensuite, notre serveur s2 dit RCPT FROM: Le serveur Rcp.MX` le vérifie également. Les valeurs sont les mêmes, elles doivent donc également être positives.

Peut-être y a-t-il aussi un contrôle rDNS, mais je ne suis pas sûr de ce qui est coché HELO ou RCPT FROM.

Notre enregistrement PTR pour 82.209.198.147 est:

147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.

Pour moi, tout semble aller bien, mais de toute façon, tous les courriels sont rejetés par Gmail.

Donc, j'ai vérifié MXtoolbox.com - il dit que tout va bien, j'ai réussi http://www.kitterman.com/spf/validate.html Vérification Python, j'ai testé le courrier électronique 25port.com. C'est bien aussi:

Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <check-auth@verifier.port25.com>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <supruniuk-p@corp.delo-company.com>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass header.From=supruniuk-p@corp.delo-company.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_001_01CCF89E.BE02A069"
Subject: test
Date: Fri, 2 Mar 2012 21:03:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <4C9EB1DB67831A428B2E14052F4A418707E1FF@s2.corp.delo-company.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <supruniuk-p@corp.delo-company.com>
To: <check-auth@verifier.port25.com>

J'ai également vérifié avec spf-test@openspf.net, mais cela échoue tout le temps, quels que soient les enregistrements SPF que je crée:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <spf-test@openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p@corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

J'ai rempli le formulaire Gmail deux fois, mais rien ne se passe.

Nous n'envoyons pas de spam, mais uniquement des emails pour nos clients. Deux ou trois fois, nous avons envoyé des e-mails en masse (comme des voeux du Nouvel An et des promotions commerciales) à partir d'adresses corp.delo-company.com, mais ils correspondaient tous au Guide de l'expéditeur en masse de Gmail (SPF, Relais ouverts, Priorité: En vrac et désabonnement). Mots clés). Donc, cela ne devrait pas être un problème.

Aidez-moi, s'il vous plaît. Qu'est-ce que je fais mal?

UPD: J'ai également essayé le test Unlocktheinbox.com et le serveur échoue également à ce test. Ici est le résultat; ici est un de plus.

J'ai également essayé d'envoyer manuellement des courriels à partir de ce serveur via telnet et tout va bien. Voici ce que je tape:

220 mx.google.com ESMTP g15si4811326anb.170
HELO s2.corp.delo-company.com
250 mx.google.com at your service
MAIL FROM: <supruniuk-p@corp.delo-company.com>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <pablomedok@gmail.com>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test
.
250 2.0.0 OK 1330795021 g15si4811326anb.170
QUIT
221 2.0.0 closing connection g15si4811326anb.170

Et voici ce que je reçois:

Delivered-To: pablomedok@gmail.com
Received: by 10.227.132.73 with SMTP id a9csp96864wbt;
        Sat, 3 Mar 2012 09:17:02 -0800 (PST)
Received: by 10.101.128.12 with SMTP id f12mr4837125ann.49.1330795021572;
        Sat, 03 Mar 2012 09:17:01 -0800 (PST)
Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (s2.corp.delo-company.com. [82.209.198.147])
        by mx.google.com with SMTP id g15si4811326anb.170.2012.03.03.09.15.59;
        Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Received-SPF: pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) client-ip=82.209.198.147;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) smtp.mail=supruniuk-p@corp.delo-company.com
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <4f52520c.0f53640a.77bf.5626SMTPIN_ADDED@mx.google.com>
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test

11
2018-03-02 20:45


origine


Avez-vous essayé de changer l’enregistrement TXT de ip4:82.209.198.147 à mx? Comme vous, je ne vois pas d'erreur, mais cela vaut peut-être la peine d'essayer. - James O'Gorman
Essayé mx pour corp: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: Adresse du destinataire rejetée: Tests SPF: Mail-From Result = "permerror" : Mail de = "supruniuk-p@corp.delo-company.com" HELO nom = "s2.corp.delo-company.com" HELO Result = "softfail" Remote IP = "82.209.198.147">> - pablomedok
Et mx pour s2.corp. <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: adresse du destinataire refusée: tests SPF: résultat de mailing = "softfail": mail de = " supruniuk-p@corp.delo-company.com "HELO name =" s2.corp.delo-company.com "HELO Result =" softfail "Remote IP =" 82.209.198.147 "> Les deux sont Softfail. - pablomedok
Avez-vous un DSN (Delivery Status Notification) pour un message renvoyé? Pouvez-vous le poster? Vous ne dites pas si vous savez avec certitude que SPF est la raison pour laquelle Gmail refuse votre courrier électronique. - kls
Je peux vous le donner, mais c'est en russe: Сообщение не было получено одним или несколькими получателями. Тема: test de 22 Отправлено: 03.03.2012 00:07 Сообщение не получили следующие получатели: pablomedok@gmail.com на 03.03.2012 00:08 Ошибка связи с сервером электронной почты получателя по протоколу SMTP. Обратитесь к системному администратору. <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] Notre système a détecté un taux inhabituel de> Le message est rompu après la première ligne. J'ai vu les bûches, après il y a QUIT - pablomedok


Réponses:


Microsoft a un bon wizzard. Peut-être que cela peut suggérer des changements?

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/


2
2018-03-22 10:26



Oui je le sais. Merci - pablomedok


Après 50 jours d’essai et de recherche de solution sur Google, Gmail a commencé à accepter nos courriels. Ils passent dans la boîte de réception de manière normale (ils ne sont pas étiquetés comme spam).

Je n’ai apporté aucune modification ni aucun autre essai au cours des 15 derniers jours. Je ne sais pas si c'est de la bureaucratie ou des algorithmes qui prennent si longtemps, mais à mon avis, cela a pris 10 fois plus de temps que prévu. Une pénalité de 5 jours pour notre sécurité faible suffit.

Par ailleurs, unlocktheinbox.com passe maintenant le test, le test openspf.org signale toujours un échec. On dirait que ma situation est trop complexe pour le test. Je corrigerais mes noms PTR et HELO pour qu'ils correspondent au nom de domaine.

Cependant, cela prenait déjà une semaine après avoir demandé à notre fournisseur d'accès Internet de modifier le PTR et cela n'a toujours pas changé ... Un autre problème de bureaucratie.

Merci pour l'aide de tous.


2
2018-03-22 21:53





Cela pourrait-il être dû au fait que vous n'utilisez que des enregistrements TXT, sans enregistrement de type SPF?

pour citer la RFC 4408:

Il est reconnu que la pratique actuelle (utilisation d’un enregistrement TXT) est
  pas optimal, mais il est nécessaire car il existe un certain nombre de DNS
  implémentations de serveur et de résolveur d'usage courant qui ne peuvent pas gérer
  le nouveau type de RR. Le schéma de type à deux enregistrements fournit un chemin de transfert
  à la meilleure solution d'utiliser un type de RR réservé à cet effet.

Un nom de domaine compatible SPF DEVRAIT avoir des enregistrements SPF des deux RR
  les types. Un nom de domaine conforme DOIT avoir un enregistrement d'au moins un.
  type. Si un domaine a des enregistrements des deux types, ils DOIVENT avoir
  contenu identique.


1
2018-03-03 19:04



Notre panneau de contrôle d'hébergement ne prend pas en charge le type d'enregistrement SPF (uniquement a, aaaa, cname, ns, mx, srv, txt). Mais ce n'était pas un problème avant. Je ne comprends tout simplement pas pourquoi certains services passent et d’autres échouent. Et pourquoi l'envoi manuel de messages via Telnet a-t-il réussi à partir du même serveur? On dirait qu'il y a un problème avec les paramètres Exchange. - pablomedok