Gmail rejette les e-mails. Openspf.net échoue aux tests

J'ai un problème avec Gmail.

Cela a commencé après qu'un de nos PC infectés par des chevaux 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 également corrigé cela. Mais chaque fois que nous envoyons un e-mail à Gmail, le message est rejeté:

J'ai donc vérifié à nouveau le guide de Google Bulk Sender et trouvé une erreur dans notre enregistrement SPF et corrigé. Google dit que tout devrait bien se passer après un certain temps, mais cela ne se produit pas. Trois 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 est très bien, mais les problèmes sont avec le nom de sous-domaine corp.delo-company.com).

Le domaine Delo-company.com possède 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" 

(J'ai réglé ~ tout à des fins de test uniquement, c'était -tout avant)

Ces enregistrements concernent notre serveur d'entreprise Exchange 2003 au 82.209.198.147. Son nom LAN est s2.corp.delo-company.com, donc ses salutations HELO / EHLO sont également s2.corp.delo-company.com.

Pour passer le contrôle 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 passées de cette manière: Le serveur s2 se connecte à MX du destinataire (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX dit OK et fait une vérification SPF de HELO / EHLO. Il fait NSlookup pour s2.corp.delo-company.com et obtient les enregistrements DNS ci-dessus. TXT records indique que s2.corp.delo-company.com ne devrait provenir que de l'IP 82.209.198.147. Il faut donc l'adopter.

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.

Il y a peut-être aussi une vérification rDNS, mais je ne suis pas sûr de ce qui est vérifié HELO ou RCPT FROM.

Notre record 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 va bien, mais de toute façon, tous les e-mails sont rejetés par Gmail.

Donc, j'ai vérifié MXtoolbox.com - ça dit que tout va bien, j'ai passé http://www.kitterman.com/spf/validate.html Vérification Python, j'ai fait le test de courrier électronique de 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, peu importe les enregistrements SPF que je fais:

<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, uniquement des emails pour nos clients. 2 ou 3 fois, nous avons envoyé des e-mails en masse (comme les vœux du Nouvel An et les promotions de vente) à partir des adresses corp.delo-company.com, mais ils étaient tous conformes au guide de l'expéditeur en vrac de Gmail (je veux dire SPF, relais ouverts, priorité: vrac et désabonnement Mots clés). Donc, cela ne devrait pas poser de 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. Voici le résultat; en voici un de plus.

J'ai également essayé d'envoyer manuellement des e-mails à 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 j'obtiens:

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

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

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

Après 50 jours d'essais et de recherche de solutions sur Google, Gmail a commencé à accepter nos e-mails. Ils passent dans la boîte de réception de manière normale (ils ne sont pas marqué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 la bureaucratie ou certains 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 faible sécurité suffit.

Soit dit en passant, 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 a déjà pris une semaine après que nous ayons demandé à notre FAI de changer le PTR et cela reste inchangé ... Encore un problème de bureaucratie.

Merci pour l'aide de tout le monde.

Serait-ce parce que vous utilisez uniquement des enregistrements TXT, sans enregistrement de type SPF?

pour citer RFC 4408:

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

Un nom de domaine conforme SPF DEVRAIT avoir des enregistrements SPF des deux
types RR . 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
un contenu identique.