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

0

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.