Google Mail lehnt E-Mails ab. Openspf.net besteht die Tests nicht

Ich habe ein Problem mit Google Mail.

Es begann, nachdem einer unserer mit Trojanern infizierten PCs einen Tag lang Spam von unserer IP-Adresse gesendet hatte.

Wir haben das Problem behoben, sind aber auf drei schwarze Listen gestoßen. Das haben wir auch behoben. Trotzdem wird die Nachricht jedes Mal abgelehnt, wenn wir eine E-Mail an Google Mail senden:

Daher habe ich den Leitfaden von Google Bulk Sender noch einmal überprüft und einen Fehler in unserem SPF-Datensatz gefunden und behoben. Google sagt, dass nach einiger Zeit alles in Ordnung sein sollte, aber das passiert nicht. Es sind bereits 3 Wochen vergangen, aber wir können immer noch keine E-Mails an Google Mail senden.

Unser MX-Setup ist etwas komplex, aber nicht zu viel: Wir haben einen Domainnamen delo-company.com, es hat eine eigene Mail @ delo-company.com (diese ist in Ordnung, aber die Probleme liegen beim Subdomainnamen corp.delo-company.com).

Die Domain Delo-company.com verfügt über mehrere DNS-Einträge für die Subdomain:

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" 

(Ich habe ~ all nur zu Testzwecken eingestellt, vorher war es alles)

Diese Datensätze gelten für unseren Exchange 2003-Unternehmensserver unter 82.209.198.147. Der LAN-Name lautet s2.corp.delo-company.com, daher lauten die HELO / EHLO-Grüße auch s2.corp.delo-company.com.

Um die EHLO-Prüfung zu bestehen, haben wir auch einige Einträge im DNS von delo-company.com erstellt:

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

Soweit ich weiß, sollten SPF-Überprüfungen folgendermaßen übergeben werden: Der Out-Server s2 stellt eine Verbindung zu MX des Empfängers her (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX sagt OK und führt eine SPF-Überprüfung von HELO / durch EHLO. Es führt NSlookup für s2.corp.delo-company.com durch und ruft die oben genannten DNS-Einträge ab. Laut TXT-Aufzeichnungen sollte s2.corp.delo-company.com nur von IP 82.209.198.147 stammen. Also sollte es weitergegeben werden.

Dann sagt unser s2-Server RCPT FROM: Rcp.MX` Server überprüft es auch. Die Werte sind gleich und sollten daher auch positiv sein.

Vielleicht gibt es auch eine rDNS-Prüfung, aber ich bin nicht sicher, was HELO oder RCPT FROM geprüft wird.

Unser PTR-Rekord für 82.209.198.147 lautet:

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

Für mich sieht alles gut aus, aber trotzdem werden alle E-Mails von Google Mail abgelehnt.

Also habe ich MXtoolbox.com überprüft - es heißt, alles ist in Ordnung, ich habe die Python-Prüfung http://www.kitterman.com/spf/validate.html bestanden und den E-Mail-Test 25port.com durchgeführt. Es ist auch gut:

Return-Path: <[email protected]>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <[email protected]>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <[email protected]>)
Authentication-Results: verifier.port25.com; spf=pass [email protected]
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) [email protected]
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass [email protected]
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: <[email protected]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <[email protected]>
To: <[email protected]>

Ich habe auch bei [email protected] nachgefragt, aber es schlägt die ganze Zeit fehl, egal welche SPF-Aufzeichnungen ich mache:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <[email protected]>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="[email protected]" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

Ich habe das Google Mail-Formular zweimal ausgefüllt, aber es passiert nichts.

Wir versenden keinen Spam, nur E-Mails für unsere Kunden. Zwei- oder dreimal haben wir Massen-E-Mails (wie Neujahrsgrüße und Verkaufsförderungsaktionen) von Adressen von corp.delo-company.com gesendet, die jedoch alle dem Handbuch für Massensender von Google Mail entsprechen (ich meine SPF, Open Relays, Vorrang: Massen- und Abbestellen) Stichworte). Das sollte also kein Problem sein.

Bitte hilf mir. Was mache ich falsch?

UPD: Ich habe auch den Unlocktheinbox.com-Test ausprobiert und der Server hat diesen Test ebenfalls nicht bestanden. Hier ist das Ergebnis; hier ist noch einer.

Ich habe auch versucht, E-Mails von diesem Server manuell über Telnet zu senden, und alles ist in Ordnung. Folgendes schreibe ich:

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

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

Und das bekomme ich:

Delivered-To: [email protected]
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: <[email protected]>
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 [email protected] 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 [email protected] designates 82.209.198.147 as permitted sender) [email protected]
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <[email protected]>
From: [email protected]
To: Pavel <[email protected]>
Subject: Test 28

This is telnet test

Microsoft hat einen schönen Zauberer. Vielleicht kann es einige Änderungen vorschlagen?

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

Nachdem Google Mail 50 Tage lang versucht hatte, nach einer Lösung zu suchen, akzeptierte Google Mail unsere E-Mails. Sie werden auf normale Weise an den Posteingang weitergeleitet (sie werden nicht als Spam gekennzeichnet).

Ich habe in den letzten 15 Tagen keine Änderungen oder andere Versuche vorgenommen. Ich weiß nicht, ob es Bürokratie oder einige Algorithmen sind, die so lange dauern, aber meiner Meinung nach hat es 10 Mal länger gedauert, als es sollte. 5 Tage Strafe für unsere schwache Sicherheit ist genug.

Übrigens besteht unlocktheinbox.com jetzt den Test, openspf.org testet immer noch einen Fehler. Sieht so aus, als wäre meine Situation für den Test zu komplex. Ich würde meine PTR- und HELO-Namen so korrigieren, dass sie mit dem Domainnamen übereinstimmen.

Es dauerte jedoch bereits eine Woche, nachdem wir unseren ISP gebeten hatten, die PTR zu ändern, und es bleibt immer noch unverändert ... Ein weiteres Bürokratieproblem.

Vielen Dank für die Hilfe aller.

Könnte es sein, dass Sie nur TXT-Datensätze ohne SPF-Datensatz verwenden?

um RFC 4408 zu zitieren:

Es wird anerkannt, dass die derzeitige Vorgehensweise (unter Verwendung eines TXT-Eintrags)
nicht optimal ist, dies ist jedoch erforderlich, da eine Reihe von häufig verwendeten DNS-
Server- und Resolver-Implementierungen
den neuen RR-Typ nicht verarbeiten können . Das Schema mit zwei Datensätzen bietet einen Vorwärtspfad
zur besseren Lösung der Verwendung eines für diesen Zweck reservierten RR-Typs.

Ein SPF-kompatibler Domänenname MUSS SPF-Einträge beider RR-
Typen enthalten. Ein kompatibler Domainname MUSS einen Datensatz von mindestens einem
Typ haben. Wenn eine Domain Datensätze beider Typen enthält, MÜSSEN sie
identischen Inhalt haben.