(из-за проблемы со спам-фильтром SO некоторые имена были заменены)
Предыстория: у нас есть небольшой сервер (около 50 пользователей, в журналах ниже упоминается как metalab.ifmoru), мы разрешаем выполнять перенаправление на внешние сервисы, например, gmailcom. Тем не менее, мы используем установку с двумя серверами: Edge (напрямую подключенным к Интернету) и Mailbox (за брандмауэром) с использованием Microsoft Exchange 2013. У нас есть правильные записи SPF и DKIM, с оценкой 10 из 10 на mail-tester. В реальных случаях исходящая доставка - это нормально, ничего не сообщалось, кроме ...
Проблема: некоторые внешние отправители (mailru в журналах ниже, Yahoo в этом списке тоже) используют строгую политику DMARC, и перенаправление через наш сервер отклоняется с типичным сообщением об ошибке, подобным этому:
mx.google.com возвращает сообщение об ошибке:
Неаутентифицированная электронная почта от mailru не принимается из-за политики DMARC домена. Пожалуйста, свяжитесь с администратором домена mailru, если это была легальная почта. Пожалуйста, перейдите по ссылке, чтобы узнать об инициативе DMARC. 62si7948506lfu.198 - gsmtp
Расследование: по определению от dmarc.org
Политика DMARC позволяет отправителю указать, что его сообщения защищены SPF и / или DKIM, и сообщает получателю, что делать, если ни один из этих методов аутентификации не пройден - например, нежелательная почта или отклонение сообщения.
Чтобы проверить SPF и DKIM еще раз, я отправляю сообщение в мой почтовый ящик Google. Выглядит хорошо, у всех есть
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
Хорошо, давайте проверим заголовок перенаправленного сообщения с других серверов без строгой политики DMARC. Иногда, если выглядит тоже хорошо:
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
Тем не менее, иногда это не удается из-за части DKIM:
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
Эксперимент:
1) Настройте перенаправление на google с нашего сервера (metalab.ifmoru) на gmailcom
2) Настройка перенаправления на Google с сервера Zimbra (другой адрес) на gmailcom
3) Отправьте одно письмо от mailru с указанными выше адресами в поле From .
Результат: редирект через наш сервер отклонен, редирект прохождения Zimbra проходит нормально. При проверке заголовков SMTP я обнаружил один и тот же блок заголовка для 1) сообщения в папке входящих сообщений на нашем сервере 2) на сервере Zimbra 3) в перенаправленном сообщении, поступающем из Zimbra. Вот:
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>
Что касается отклоненного сообщения, та же самая часть выглядит совсем по-другому - порядок был изменен, некоторые заголовки с чередованием UTF-8, некоторые превратились в кодировку koi-8, орфография x-тегов была изменена с Camel-Case на более низкий и т. д .:
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
Похоже, что MS Exchange нарушает DKIM, переписывая заголовки. Итак, вопрос : как сохранить заголовки от перезаписи во время перенаправления через MS Echange?
Начальные попытки:
1) Подпись отправителя DKIM была повреждена в среде Exchange Server 2013, CU6 должен решить эту проблему. Не помогает Использование CU9 на данный момент.
2) Добавьте ms-Exch-Send-Headers-Routing к отправляющим соединителям. Он контролирует сохранение полученных заголовков в сообщениях. Не помогает
Проверено с:
PS C:\Windows\system32> Get-SendConnector | Get-ADPermission | where {$_.ExtendedRights -like "*routing*"} | fl user, extendedrights
Добавление ссылки Не достаточно репутации для публикации. Ключевые слова для поиска
- Заголовок межсетевого экрана Exchange 2013
- Как удалить информацию внутренней маршрутизации из заголовков в Exchange
- Exchange 2013: применение межсетевого экрана заголовка
- Использование перезаписи заголовка с Exchange Server
- Перезапись адресов на пограничных транспортных серверах