2

(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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.