Gmail rejette les courriels. Openspf.net échoue aux tests

J'ai eu un problème avec Gmail.

Il a débuté après qu'un de nos PC infectés de Troie a envoyé un spam pour un jour à partir de notre adresse IP.

Nous avons résolu le problème, mais nous sums entrés dans 3 lists noires. Nous l'avons également corrigé. Mais toujours chaque fois que nous envoyons un courrier électronique à Gmail, le message est rejeté:

J'ai donc vérifié à nouveau le manuel de Google Bulk Sender et j'ai constaté une erreur dans notre dossier SPF et l'avons corrigé. Google dit que tout devrait s'arranger après un certain time, mais cela n'arrive pas. 3 semaines déjà passées, mais nous ne pouvons toujours pas envoyer de courrier électronique à 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 bien, mais les problèmes sont liés au nom de sous-domaine corp.delo-company.com).

Le domaine Delo-company.com possède plusieurs loggings 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 l'ai défini pour tous les tests uniquement, c'était avant tout)

Ces loggings concernent notre server Exchange 2003 d'entreprise au 82.209.198.147. Son nom LAN est s2.corp.delo-company.com afin que ses salutations HELO / EHLO soient également s2.corp.delo-company.com.

Pour passer la vérification EHLO, nous avons également créé certains loggings 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" 

Comme je comprends, les vérifications SPF devraient être transmises de cette façon: le server s2 se connecte à MX du récepteur (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX dit Ok et vérifie SPF de HELO / EHLO. Il fait NSlookup pour s2.corp.delo-company.com et obtient les loggings DNS ci-dessus. Les loggings TXT indiquent que s2.corp.delo-company.com devrait être uniquement de IP 82.209.198.147. Donc, il devrait être adopté.

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

Peut-être existe-t-il également un contrôle 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 emails sont rejetés par Gmail.

Donc, j'ai vérifié MXtoolbox.com – il dit que tout va bien, j'ai passé http://www.kitterman.com/spf/validate.html Python check, j'ai fait 25port.com e-mail test. C'est aussi bien:

 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-classs: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 il FALLE tout le time, peu importe les loggings 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 Gmail deux fois, mais rien ne se passe.

Nous n'émettons pas de spam, seulement des courriels pour nos clients. 2 ou 3 fois, nous avons fait des courriels de masse (comme les salutations du Nouvel An et les promotions de ventes) des adresses corp.delo-company.com, mais ils sont tous conforms au Guide de l'Expéditeur en vrac de Gmail (je veux dire SPF, Open Relays, Precedence: Bulk et Unsubscribe Mots keys). Donc, ce 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 server échoue également à ce test. Voici le résultat: http://bit.ly/wYr39h . Voici un autre http://bit.ly/ypWLjr

J'ai également essayé d'envoyer des e-mails à partir de ce server manuellement 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 c'est 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 

3 Solutions collect form web for “Gmail rejette les courriels. Openspf.net échoue aux tests”

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

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

Après 50 jours d'essayer et de google pour une solution, Gmail a commencé à accepter nos courriels. Ils passent à la boîte de réception de manière normale (ils ne sont pas étiquetés comme spam).

Je n'ai effectué aucun changement ou aucun autre essai au cours des 15 derniers jours. Je ne sais pas si c'est une bureaucratie ou des algorithms qui prennent tant de time, mais à mon avis, cela a duré 10 fois plus longtime qu'il ne le faudrait. Une pénalité de 5 jours pour notre faible security suffit.

En passant, unlocktheinbox.com passe le test, le test openspf.org continue de signaler un échec. On dirait que ma situation est trop complexe pour le test. Je réparerais mes noms PTR et HELO pour correspondre au nom de domaine.

Cependant, il a fallu une semaine après que nous avons demandé à notre FAI de changer PTR et il rest inchangé … Un autre problème de bureaucratie.

Merci pour l'aide de tous.

pourrait-il être parce que vous n'utilisez que des loggings TXT, sans logging de type SPF?

pour citer RFC 4408:

Il est reconnu que la pratique actuelle (en utilisant un logging TXT) est
pas optimal, mais il est nécessaire car il existe un certain nombre de DNS
implémentations de server et de résolveur d'usage courant qui ne peuvent pas gérer
le nouveau type de RR. Le système de deux loggings fournit un path en avant
à la meilleure solution d'utilisation d'un type RR réservé à cet effet.

Un nom de domaine compatible SPF DEVRAIT avoir des loggings SPF à la fois RR
les types. Un nom de domaine compatible DOIT avoir un record d'au less un
type. Si un domaine comporte des loggings des deux types, ils DOIVENT avoir
contenu identique.

  • Windows Server 2003 Enterprise - Comment puis-je append un logging SPF à DNS?
  • Domaine CNAME dans un autre domaine, mais gardez-vous différents loggings SPF pour les deux?
  • Les en-têtes "via" et "en count" sont-ils déterminés par DKIM et SPF?
  • SPF - dois-je mettre en œuvre?
  • Pourquoi l'échec logiciel par défaut échoue dans gmail
  • Spf Un logging pour un second domaine
  • DKIM et SPF pour un sous-domaine
  • Quelle est la différence entre tous et tous dans un logging DNS SPF?
  • Blackberry & SPF
  • Pourquoi mon courrier est-il marqué comme un spam?
  • Le courrier marqué comme spam (Gmail / Hotmail): IP non sur la list noire, DKIM Valid, SPF Valid et DMARC valide
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.