(due to issue with SO spam filter some names were replaced)
Background: we have a small server (about 50 users, referenced as metalab.ifmoru in logs below), we allow to do a redirect to external services, e.g. gmailcom. Still, we use a setup with two servers: Edge (directly connected to Internet) and Mailbox (behind the firewall) using Microsoft Exchange 2013. We have a correct SPF and DKIM records, with score 10 of 10 at mail-tester. For real life cases, outgoing delivery is fine, nothing was reported except ...
The issue: Some external senders (mailru in logs below, Yahoo in this list too) use strict DMARC policy and the redirect via our server is rejected with a typical error message like this:
mx.google.com returns an error message:
Unauthenticated email from mailru is not accepted due to domain's DMARC policy. Please contact the administrator of mailru domain if this was a legitimate mail. Please visit cut some link to google to learn about the DMARC initiative. 62si7948506lfu.198 - gsmtp
Investigation: By definition from dmarc.org
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message.
To check SPF and DKIM once more I send an message to my google inbox. Looks fine, they all have:
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, let`s check the header of redirected message from other servers, without a strict DMARC policy. Sometimes if looks to be fine too:
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
However, sometimes it FAILS due to DKIM part:
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) Setup redirect to google from our server (metalab.ifmoru) to gmailcom
2) Setup redirect to google from Zimbra server (some other address) to gmailcom
3) Send a single letter from mailru with above mentioned adresses in the From field.
The result: The redirect via our server is rejected, redirect passing Zimbra goes fine. While checking SMTP headers I found the same header block for 1)message in the inbox in our server 2) on Zimbra server 3) in redirected message coming from Zimbra. Here it is:
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>
as for rejected message the same part looks very different - the order was changed, some header striped UTF-8, some turned to koi-8 encoding, x-tags spelling was changed from Camel-Case to lower, etc.:
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
It looks like that MS Exchange breakes DKIM by rewriting headers. So the question is: How to preserve headers from being rewritten during redirect via MS Echange?
Initial Attempts:
1) Sender's DKIM signature was broken in an Exchange Server 2013 environment, CU6 should solve the issue. Doesn't help. Using CU9 at the moment.
2) Add ms-Exch-Send-Headers-Routing to sending connectors. It controls the preservation of RECEIVED headers in messages. Doesn't help.
Checked with:
PS C:\Windows\system32> Get-SendConnector | Get-ADPermission | where {$_.ExtendedRights -like "*routing*"} | fl user, extendedrights
Addition links Not enought reputation to post. Keywords for search
- Header firewall Exchange 2013
- How to remove internal routing information from headers in Exchange
- Exchange 2013: Applying Header firewall
- Using Header Rewriting with Exchange Server
- Address rewriting on Edge Transport servers
