SPF für E-Mails, die aufgrund der Client-IP anstelle der Server-Nachricht in Google Mail importiert wurden, fehlgeschlagen, wenn über SMTP von einer lokalen Box zu einer anderen gesendet wurde

Wir haben ein Linux (Debian) VPS mit Domain (sagen wir example.com mit MX mail.example.com), auf dem SPF eingerichtet ist. Es läuft Taubenschlag + Exim. Darüber hinaus gibt es noch Direct Admin.

Wenn ich eine Mail an einen fremden Server sende, ist alles in Ordnung. Die Nachricht enthält eine Server-IP, und die SPF-Prüfung funktioniert einwandfrei.

Einige Daten geändert (Domain etc.):

Received: from mail.example.com (mail.example.com. [188.40.153.39])
    by mx.google.com with ESMTPS id ***.7.2015.02.18.04.09.46
    for <*@gmail.com>
    (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Wed, 18 Feb 2015 04:09:47 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 188.40.153.39 as permitted sender) client-ip=188.40.153.39;

Wenn ich es jedoch von einem lokalen Postfach an ein anderes lokales Postfach sende und dann über POP3 E-Mails an Google Mail erhalte, habe ich ein Problem mit SPF, da eine Nachricht die ursprüngliche Client-IP-Adresse enthält und die SPF-Prüfung fehlschlägt.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of [email protected] does not designate 82.160.100.10 as permitted sender) [email protected]
Received-SPF: fail (google.com: domain of [email protected] does not designate 82.160.100.10 as permitted sender) client-ip=82.160.100.10;

82.160.100.10 ist die IP des ursprünglichen Absenders.

Aufgrund dieses Problems wird unsere interne Korrespondenz in Google Mail in der Regel als Spam für Personen markiert, die ihre Kontrollkästchen aktivieren.

Irgendwelche Ideen, wie man das behebt?

BEARBEITEN: Header der Testmail (geänderte IPs und Domain)

1) E-Mail von einer Box zur anderen gesendet - Header vom Thunderbird-Client:

Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 19 Feb 2015 11:41:20 +0100
Received: from nat10.net08-g2.isko.net.pl ([82.160.100.10] helo=[11.0.0.22])
    by mail.example.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
    (Exim 4.83)
    (envelope-from <[email protected]>)
    id 1YOOPC-0005Ud-Qq
    for [email protected]; Thu, 19 Feb 2015 11:41:20 +0100
Message-ID: <[email protected]>
Date: Thu, 19 Feb 2015 11:41:18 +0100
From: Head Developer <[email protected]>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Zbyszek <[email protected]>
Subject: This is test
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

2) Gleiche Mail nach Erhalt per Google Mail (durch automatischen regulären Import per POP3):

Delivered-To: *@gmail.com
Received: by 10.140.86.210 with SMTP id p76csp775880qgd;
    Thu, 19 Feb 2015 02:47:12 -0800 (PST)
X-Received: by 10.140.102.165 with SMTP id w34mr10762910qge.26.1424342832562;
    Thu, 19 Feb 2015 02:47:12 -0800 (PST)
Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of [email protected] does not designate 82.160.100.10 as permitted sender) [email protected]
Received-SPF: fail (google.com: domain of [email protected] does not designate 82.160.100.10 as permitted sender) client-ip=82.160.100.10;
Received: by 10.224.31.8 with POP3 id w8mf619596qac.5;
    Thu, 19 Feb 2015 02:47:12 -0800 (PST)
X-Gmail-Fetch-Info: [email protected] 2 mail.example.com 110 [email protected]
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 19 Feb 2015 11:41:20 +0100
Received: from nat10.net08-g2.isko.net.pl ([82.160.100.10] helo=[11.0.0.22])
    by mail.example.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
    (Exim 4.83)
    (envelope-from <[email protected]>)
    id 1YOOXn-0005j5-Tm
    for [email protected]; Thu, 19 Feb 2015 11:41:20 +0100
Message-ID: <[email protected]>
Date: Thu, 19 Feb 2015 11:41:18 +0100
From: Head Developer <[email protected]>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Zbyszek <[email protected]>
Subject: This is test
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Bearbeiten: einige zusätzliche Informationen

Die Zustellungsmethode ist SMTP (ich sende eine E-Mail von Thunderbird zu Hause über die Mailbox [email protected] an eine andere Mailbox auf demselben Server [email protected])
82.160.100.10 ist meine Home-IP, nat10.net08-g2.isko.net.pl ist mein Home-Hostname, der in diese IP aufgelöst wird
10.140.102.165 ist die IP-Adresse des Google Mail-Servers
11.0.0.22 ist die lokale IP in meinem Heimnetzwerk
Die IP des Mailservers war in keinem der Header enthalten (wenn sie dort wäre, wäre sie 188.40.153.39).
Der Hostname mail.example.com zeigt auf die IP des Mailservers
Die Domain-IP war in keinem der Header enthalten (wenn sie dort wäre, würde ich sie in 85.17.23.59 ändern).
Domain hat einen richtigen MX-Eintrag (der auf die Subdomain mail.example.com verweist)
SPF-Datensatz: "v = spf1 a mx ip4: 188.40.153.39 -all"

Bearbeiten: Nicht abgedeckte IPs als nicht so sensibel

ip dovecot exim spf gmail Zbyszek
quelle

Wenn Sie " lokales Postfach" sagen, meinen Sie damit eine E-Mail-Adresse auf demselben Computer, die eine lokale Zustellungsmethode verwendet und nur den lokalen Teil der Adresse ohne die Domäne verwendet? Somit wird die Domain lokal statt über SMTP geliefert? Wenn ja, wird dies erwartet, wenn nein, erläutern Sie bitte das Problem und Ihr Setup.

Sebix

Ja, das Zielpostfach befindet sich auf demselben Computer. Ich frage mich, ob es eine Methode gibt, um sie entweder so zu konfigurieren, dass die Nachricht die IP des Servers anstelle der IP des Clients enthält, oder die SPF-Prüfung für solche Nachrichten zu deaktivieren (was beim Importieren von E-Mails wahrscheinlich auf Google Mail-Seite ist, aber ich bin mir nicht 100% sicher , weiß nicht, wie ich es überprüfen soll).

Zbyszek

Ich habe Frage mit Überschriften aktualisiert

Zbyszek

meta.serverfault.com/q/963/126632

Michael Hampton

Nur zur Korrektur unterstützt GMail das Abrufen von E-Mails über IMAP nicht . Es ruft Ihre E-Mail über POP3 ab .

Masegaloeh

Antworten:

Haftungsausschluss: Diese Antwort war eine Spekulation, bis die GMail-Person sie bestätigte.

Sieht so aus, als würde GMail Ihre abgerufene E-Mail hier falsch behandeln. Einige Leute berichten auch über ähnliche Fälle mit Ihnen hier , hier oder hier

Das Problem ist: GMail setzt beim Scannen von E-Mails nach dem Abrufen über POP3 auch SPF-Maßnahmen ein.

Normalerweise erfolgt die SPF-Überprüfung in SMTP-Transaktionen, indem die Domänenteile der Absenderadresse und der Client-IP-Adresse überprüft werden. In POP3 muss GMail den Header analysieren und den letzten ReceivedHeader finden.

Received: from nat10.net08-g2.* ([*.160.100.10] helo=[11.0.0.22])
    by mail.example.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
    (Exim 4.83)
    (envelope-from <[email protected]>)
    id 1YOOXn-0005j5-Tm
    for [email protected]; Thu, 19 Feb 2015 11:41:20 +0100

Dies ist die ursprüngliche E-Mail, die von Ihrem Server abgerufen wurde. Es heißt, dass Ihre E-Mail E-Mails von dem *.160.100.10Absender [email protected] akzeptiert . In dieser Phase gibt Google Mail vor, Ihr Server zu sein, und überprüft Domänenteile der Absenderadresse (example.com) und der Client-IP-Adresse (* .160.100.10). Das Ergebnis wurde erwartet:

SPF-Softfail, da die Domain [email protected] * .160.100.10 nicht als zulässigen Absender bestimmt

Um dieses Problem zu umgehen, können Sie Google Mail-Filter so einstellen, dass Ihre E-Mail niemals als Spam markiert wird.

masegaloeh
quelle

Danke für die Information. Ich frage mich, ob es einen besseren Weg als diese Problemumgehung gibt. Akzeptiert diese Antwort am Montag, wenn keine bessere Lösung für das Problem gefunden wird.

Zbyszek

Wie sendet der Client (* .160.100.10) eine E-Mail an exim? Durch Submission Port 587? Oder per SMTP-Port 25?

Masegaloeh

Auf SMTP-Port 25

Zbyszek

Ja, mit STARTTLS

Zbyszek

Zunächst denke ich, dass Sie versuchen können, die Google Mail-SPF-Prüfung zu umgehen, indem Sie etwas in den Header einfügen, das angibt, dass der Client eine authentifizierte SMTP-Sitzung verwendet hat . Es sieht jedoch so aus, als hätten Sie bereits einen ESMTPA-Header in Ihrer E-Mail, und Google Mail ignoriert ihn immer noch :(. Die richtige Spam-Prüfung berücksichtigt diese Art von Header bei der Berechnung der Spam-Bewertung. Beispiel: SpamAssasin reduziert die Bewertung authentifizierter E-Mails, wenn ein ESMTPA-Header vorhanden ist in Received Header.

Masegaloeh

Es scheint ein Fehler zu sein, dass Google Mail den ESMTPA im Received-Header nicht berücksichtigt, um anzuzeigen, dass der MUA ein vertrauenswürdiger Host ist. Einige mögliche Problemumgehungen kommen in den Sinn:

Verwenden Sie Split-MX, dh eine Exim-Instanz zum Empfangen und Weiterleiten von authentifizierten Clients und eine zweite zum Empfangen in Postfächer. Dadurch wird die von Google Mail erwartete ISP-zu-ISP-E-Mail simuliert, und in den Headern befindet sich eine IP-Adresse, die mit dem SPF-Datensatz übereinstimmt.
Fügen Sie oben einen empfangenen Header hinzu, der die obige Übertragung simuliert, indem Sie add_header = hinzufügen Received: by 10.224.31.8 with ESMTP ....
Wenn die Benutzer ihre E-Mails in Google Mail über POP abrufen, leiten Sie stattdessen eine Kopie an ihr Google Mail-Konto weiter.

Cedric Knight
quelle

(2) sieht interessant aus, können Sie näher erläutern, warum 10.224.31.8?. (3) ist für uns keine Option, da es ein weiteres Problem gibt, viele Spediteure von einem Server mit einer IP zu haben. Google Mail neigt dazu, zu glauben, dass es sich um "unerwünschte Massen-E-Mails" handelt, und beginnt, uns eine Ratenbeschränkung aufzuerlegen (Hosting) aktiver Newsletter eines unserer Kunden hilft wahrscheinlich nicht)

Zbyszek

Entschuldigung, ich habe 10.224.31.8 gesehen und angenommen, dass es sich um eine private Adresse Ihres Mailservers handelt, aber es sieht aus wie Google Mail. Wenn Sie eine separate öffentliche Adresse haben, die Sie verwenden könnten, fälschen Sie diese möglicherweise. Die Leitung müsste RFC 5322 entsprechen und realistisch genug sein, um von z. B. SpamAssassin als Relais interpretiert zu werden.

Cedric Knight

Ok, danke, muss es bald ausprobieren. Kennen Sie eine Möglichkeit, dies nur für problematische Mails zu konfigurieren, z. von lokalen Boxen zu anderen lokalen Boxen? Oder muss ich das für alle eingehenden E-Mails tun?

Zbyszek

@Zbyszek Sieht so aus, als müssten Sie dies in jeder E-Mail tun, deren Absenderdomäne den richtigen SPF-Datensatz veröffentlicht hat.

Seien

Verwenden Sie stattdessen die Funktion add_header von exim, anstatt received_header_textdiese vorgeschlagene Lösung zu verwenden .

Masegaloeh

Ich hatte das gleiche Problem und habe es mithilfe des folgenden Google-Dokuments behoben. Dies könnte Ihnen ebenfalls helfen und einen Versuch wert sein.

https://support.google.com/a/answer/33786?hl=de

Sie müssen den folgenden Datensatz zu Ihrem vorhandenen SPF-TXT-Datensatz hinzufügen. Auf diese Weise kann Google die Quelle der E-Mail-Adresse ermitteln.

include:_spf.google.com

Sie müssen Ihren SPF-Datensatz also wie folgt aktualisieren.

SPF-Aufzeichnung: "v=spf1 a mx ip4:188.40.153.39 include:_spf.google.com -all"

Versuchen Sie dann, die E-Mail zu senden, und sie sollte direkt in Ihrem Posteingang landen, wenn Ihre IP einen guten Ruf hat.

Digin Dominic
quelle