MS Exchange bricht DKIM während der E-Mail-Weiterleitung

(aufgrund von Problemen mit dem SO-Spam-Filter wurden einige Namen ersetzt)

Hintergrund: Wir haben einen kleinen Server (etwa 50 Benutzer, in den Protokollen unten als metalab.ifmoru bezeichnet), wir können eine Weiterleitung zu externen Diensten, z. B. gmailcom, durchführen. Trotzdem verwenden wir ein Setup mit zwei Servern: Edge (direkt mit dem Internet verbunden) und Mailbox (hinter der Firewall) unter Verwendung von Microsoft Exchange 2013. Wir verfügen über korrekte SPF- und DKIM-Datensätze mit einer Bewertung von 10 von 10 beim Mail-Tester. In realen Fällen ist die Auslieferung in Ordnung, es wurde nichts gemeldet, außer ...

Das Problem: Einige externe Absender (Mailru in Protokollen unten, Yahoo in dieser Liste auch) verwenden strikte DMARC-Richtlinien. Die Weiterleitung über unseren Server wird mit einer typischen Fehlermeldung wie der folgenden abgelehnt:

mx.google.com gibt eine Fehlermeldung zurück:

Nicht authentifizierte E-Mails von mailru werden aufgrund der DMARC-Richtlinie der Domäne nicht akzeptiert. Bitte wenden Sie sich an den Administrator der mailru-Domain, wenn dies eine legitime Mail war. Bitte besuchen Sie den Link zu Google, um mehr über die DMARC-Initiative zu erfahren. 62si7948506lfu.198 - gsmtp

Untersuchung: Per Definition von dmarc.org

Mit einer DMARC-Richtlinie kann ein Absender anzeigen, dass seine Nachrichten durch SPF und / oder DKIM geschützt sind, und er teilt dem Empfänger mit, was zu tun ist, wenn keine dieser Authentifizierungsmethoden besteht (z. B. Junk oder Ablehnung der Nachricht).

Um SPF und DKIM noch einmal zu überprüfen, schicke ich eine Nachricht an meinen Google-Posteingang. Sieht gut aus, sie haben alle:

Authentication-Results: mx.google.com; dkim=pass header.i=@metalab.ifmoru; spf=pass (google.com: domain of XXXXXXX@metalab.ifmoru designates 77.234.203.179 as permitted sender) smtp.mailfrom=XXXXXXXX@metalab.ifmoru; dmarc=pass (p=NONE dis=NONE) header.from=metalab.ifmoru 

Ok, lasst uns den Header der umgeleiteten Nachricht von anderen Servern überprüfen, ohne eine strikte DMARC-Richtlinie. Manchmal, wenn es auch gut geht:

Received-SPF: pass (google.com: domain of noreply@github.com designates 192.30.252.199 as permitted sender) client-ip=192.30.252.199; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@github.com; spf=pass (google.com: domain of noreply@github.com designates 192.30.252.199 as permitted sender) smtp.mailfrom=noreply@github.com; dmarc=pass (p=NONE dis=NONE) header.from=github.com 

Manchmal scheitert es am DKIM-Teil:

Authentication-Results: mx.google.com; dkim=pass header.i=@metalab.ifmoru; dkim=neutral (body hash did not verify) header.i=@gmailcom; spf=pass (google.com: domain of XXXXXXXXXX@metalab.ifmoru designates 77.234.203.179 as permitted sender) smtp.mailfrom=XXXXXXXXXXXX@metalab.ifmoru; dmarc=fail (p=NONE dis=NONE) header.from=gmailcom 

Experiment:

1) Richten Sie die Umleitung auf Google von unserem Server (metalab.ifmoru) auf gmailcom ein

2) Richten Sie die Weiterleitung an Google von einem Zimbra-Server (einige andere Adressen) an Google Mailcom ein

3) Senden Sie einen Brief von mailru mit den oben genannten Adressen im FromFeld.

Das Ergebnis: Die Weiterleitung über unseren Server wird abgelehnt, die Weiterleitung an Zimbra funktioniert einwandfrei. Bei der Überprüfung der SMTP-Header habe ich den gleichen Headerblock für 1) Nachricht im Posteingang unseres Servers 2) auf dem Zimbra-Server 3) in der umgeleiteten Nachricht von Zimbra gefunden. Hier ist es:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=rZNB __cut__ znAs=; b=pIZR __cut__ A8aE=; Received: from [84.204.20.115] (ident=mail) by f96.i.mailru with local (envelope-from <XXXXXXXXX@mailru>) id 1byY2P-0005Ep-6D; Mon, 24 Oct 2016 08:43:09 +0300 Received: from [84.204.20.115] by e.mailru with HTTP; Mon, 24 Oct 2016 08:43:09 +0300 From: =?UTF-8? __cut__ 0=?= <XXXXXXXXXXXXX@mailru> To: =?UTF-8? __cut__ =?= <XXXXXXXXXXXXX@metalab.ifmoru> Cc: =?UTF-8? __cut__ =?= <XXXXXXXXXXXXX@corp.ifmoru> Subject: =?UTF-8 __cut__ =?= MIME-Version: 1.0 X-Mailer: mailru Mailer 1.0 X-Originating-IP: [84.204.20.115] Date: Mon, 24 Oct 2016 08:43:09 +0300 Reply-To: =?UTF-8?B?0JDQudGA0Y0=?= <XXXXXXXXXXXXX@mailru> X-Priority: 3 (Normal) Message-ID: <147 __cut__ 947@f96.i.mailru> Content-Type: multipart/alternative; boundary="--ALT--biYZ __cut__ 7789" X-95568C8E: 26815A __cut__ 65AEC6 X-E1FCDC63: 1787D815 __cut__ 84B93 X-E1FCDC64: FAAF71 __cut__ 93F4C0D9 X-Mailru-Sender: D211C __cut__ DD1EA8939684724DAF05A372A3159 X-Mras: OK X-Spam: undefined In-Reply-To: <CADQB __cut__ u2f3A@mail.gmailcom> References: <CADQ __cut__ 3A@mail.gmailcom> 

für abgelehnte Nachrichten sieht derselbe Teil sehr unterschiedlich aus - die Reihenfolge wurde geändert, einige Kopfzeilen UTF-8-gestreift, einige wandelten sich in Koi-8-Kodierung um, die Rechtschreibung der X-Tags wurde von Camel-Case in Lower usw. geändert:

From: =?koi8-r? __cut__ =?= <XXXXXXXXXXXXX@mailru> To: Kon __cut__ nko <XXXXXXXXXXXXX@metalab.ifmoru> CC: Kon __cut__ nko <XXXXXXXXXXXXX@corp.ifmoru> Subject: =?koi8-r? __cut__ ?= Thread-Topic: =?koi8-r?B __cut__ ?= Thread-Index: AQHSLb __cut__ 65w== Date: Mon, 24 Oct 2016 05:43:09 +0000 Message-ID: <0c14 __cut__ c21@post.metalab.ifmoru> References: <CADQB __cut__ 2f3A@mail.gmailcom> In-Reply-To: <CADQB __cut__ 2f3A@mail.gmailcom> Reply-To: =?koi8-r? __cut__ ==?= <XXXXXXXXXXXXX@mailru> X-MS-Has-Attach: X-MS-Exchange-Inbox-Rules-Loop: XXXXXXXXXXXXX@metalab.ifmoru X-MS-TNEF-Correlator: dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailru; s=mail2; h=References:In-Reply-To:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:Cc:To:From; bh=rZNBy4 __cut__ nAs=; b=pIZRm8 __cut__ IA8aE=; x-mailer: mailru Mailer 1.0 x-originating-ip: [84.204.20.115] authentication-results: f96.i.mailru; auth=pass smtp.auth=XXXXXXXXXXXXX@mailru smtp.mailfrom=XXXXXXXXXXXXX@mailru x-95568c8e: 26815 __cut__ 5AEC6 x-e1fcdc63: 1787 __cut__ 4B93 x-e1fcdc64: FAA __cut__ C0D9 x-mailru-sender: D2 __cut__ 3159 x-mras: OK x-spam: undefined 

Es scheint, dass MS Exchange DKIM durch das Umschreiben von Headern durchbricht. Also die Frage ist: Wie zu bewahren Header während Umleitung über MS Echange neu geschrieben werden?

Anfängliche Versuche:

1) Die DKIM-Signatur des Absenders wurde in einer Exchange Server 2013-Umgebung beschädigt. CU6 sollte das Problem beheben. Hilft nicht Momentan mit CU9.

2) ms-Exch-Send-Headers-RoutingZu sendenden Anschlüssen hinzufügen. Es steuert die Aufbewahrung von RECEIVED-Headern in Nachrichten. Hilft nicht

Geprüft mit:

PS C:\Windows\system32> Get-SendConnector | Get-ADPermission | where {$_.ExtendedRights -like "*routing*"} | fl user, extendedrights 

Additions-Links Nicht genug Reputation zum Posten. Schlüsselwörter für die Suche

• Header-Firewall Exchange 2013
• Entfernen interner Routing-Informationen aus Headern in Exchange
• Exchange 2013: Anwenden der Header-Firewall
• Verwenden der Headerumschreibung mit Exchange Server
• Adressumschreibung auf Edge-Transport-Servern