Как правильно использовать домен внутренней ретрансляции в MS Exchange чтобы получать письма от Mail.ru?

Question

[webmatpoc]

Mail.ru включил строгий DMARC не так давно.
Это хорошо, большое спасибо что развиваете сервис, так держать!

20.05.2016 столкнулся с тем что до почтовых адресов @firma.ru перестала доходить почта с адресов @mail.ru @list.ru и вообще со всех адресов почтового сервиса mail.ru (почту для бизнеса это не коснулось)

Часть адресов почты @firma.ru размещена на google apps
Другая часть на корпоративном почтовом сервере MS Exchange 2010

MX записи домена @firma.ru сообщают всему миру что любое письмо надо слать на Exchange

В Exchange домен @firma.ru настроен как домен внутренней ретрансляции.
-для домена @firma.ru создан соединитель отправки в котором указано что нужно нужно выполнять маршрутизацию почты через промежуточные узлы гуглопочты
-для домена @firma.ru в корпоративном DNS указаны MX записи гуглопочты

Когда приходит письмо на [e-mail], Exchange ищет адрес [e-mail] в своем списке и если находит - кладет письмо туда.
Если не находит - шлет в гугл.

Схема очень давняя, рабочая, проверенная. Была )

Сейчас так не работает если прилетает письмо от @mail.ru на адресата, ящик которого в гуглопочте.

Возвращается ответ
mx.google.com #550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain's 550-5.7.1 DMARC policy
Оно и понятно. нельзя слать от лица mail.ru серверам которые не разрешены DMARC

Пользователи @firma.ru у которых почта на google apps там не просто так.. переводить их на Exchange нельзя по ряду причин.

Надеюсь что есть какой то способ прогонять письма через себя как и раньше не нарушая DMARC, может быть кто то уже решал такую проблему.
Буду рад и признателен, если ответит Владимир Дубровин

Answer 1

[Владимир Дубровин]

Обычные редиректы не должны менять содержание письма, а значит не должны портить DKIM-сигнатуру и DMARC в такой ситуации не мешает прохождению письма. Бывают ошибки типа https://support.microsoft.com/en-us/kb/2993556 которые Microsoft устраняет, попробуйте установить последние сервис паки и rollup update'ы.

Возможно именно в вашей конфигурации по каким-то причинам письмо перестраивается, например в настройках формата стоит принудительное изменение формата на RTF/HTML. Я не силен в настройках Exchange, но проверьте чтобы этого не происходило. Попробуйте отправить письмо с любого другого адреса на получателей на обеих серверах, сравните diff'ом результат, чтобы понять, почему бьется DKIM.

И имйте ввиду, что если бьется DKIM-сигнатура письма, значит вы не получаете письма не только от mail.ru, но и от yahoo, aol, linkedin, facebook, Вконтакте, paypal и много кого еще, включая письма от самого гугла (@google.com) - т.к. на всех этих доменах тоже строгий DMARC.

Comments

[Max Kostikov]

Как раз проблема в том, что ничего в заголовках не перестраивается и Exchange выступает отправителем от имени домена mail.ru что запрещено его политикой DMARC.

[Владимир Дубровин]

Скорей всего вы путаете DMARC с SPF или Sender-ID. Политика DMARC не запрещает отправлять письма, которые проходят авторизацию. Если вы получите письмо от Mail.Ru например на ящик на Yandex а потом переотправите его со своего сервера, который не имеет никакого отношения ни к Yandex ни к Mail.Ru на любой другой e-mail, например на GMail - это письмо дойдет, потому что в нем будет валидная сигнатура DKIM.

можете предоставить оригиналы двух писем в виде eml полученных на exchange и на google apps?

[Max Kostikov]

Владимир Дубровин: У меня имеется аналогичная конфигурация на базе Exim, когда часть ящиков размещены локально, а часть на Gmail. Только что проверил - почта с mail.ru туда проходит на ура. Видимо, действительно в транзите изменяются подписанные DKIM заголовки.
Вы правы, а я был выше не прав.

Answer 2

[akelsey]

DMARC это технология DKIM + SPF как минимум.
Т.е. у вас проблема с SPF, а не с DKIM, т.к. ваш сервис не входит в диапазоны
"v=spf1 ip4:94.100.176.0/20 ip4:217.69.128.0/20 ip4:128.140.168.0/21 ip4:188.93.58.0/24 ip4:195.211.128.0/22 ip4:188.93.59.0/24 ip4:128.140.170.0/24 ip4:178.22.92.0/23 ip4:185.5.136.0/22 ip4:5.61.237.0/26 ip4:5.61.237.128/25 ip4:5.61.236.0/24 ~all"
гугл режектит почту, хоть и у мейл.ру не строгое (~all - т.е. решение принять должна принимающая сторона) соответствие, гугл окончательно решает что есть спам, а что не спам.

И наверное тут ничего не сделать, дальше с такими схемами будет только хуже, ибо спамеры уже всех достали.

Comments

[Владимир Дубровин]

нет, это не так. Для DMARC достаточно любой авторизаии, подойдет и SPF и DKIM. Поскольку DMARC проверяет соответствие (align) домена с From:, то сохранить SPF на пересылках невозможно в принципе, т.к. даже если перезаписать envelope-from на свой и добиться прохождиния SPF - будет нарушен align. Поэтому для пересылок очень важно сохранять структуру письма, чтобы не нарушать DKIM-сигнатуру.

[akelsey]

Владимир Дубровин: понял, спасибо, буду знать.

Answer 3

[webmatpoc]

Добрый день!
Большущее Спасибо, всем кто откликнулся!
Echange 2010 действительно не был обновлен последним апдейтом. Был предпоследний.
Удалось выполнить обновление до 13 Rollup'а
К сожалению, ничего не изменилось..
Провел несколько экспериментов, хочу с вами поделиться.

Используя публичный ящик на мэйлру:
1. Через веб интерфейс пробовал создавать письма с текстом и без текста в теле письма. отключал оформление и очищал формат (Кнопки "Расширенное оформление/убрать оформление" и кнопка "Очистить форматирование" когда "Расширенное оформление" включено)
2. Через MS Outlook пробовал отправлять письма в HTML/Простой текст/RTF так же с вариациями с текстом и без текста

Все письма отправленные с Мэйлру вернулись со одной и той же ошибкой про DMARC

После этого воспользовался публичным ящиков на Яндекс. Чтобы смотреть оригинал письма отправленного с Яндекс когда оно дойдет на Gmail.

1. Через веб интерфейс пробовал создавать письма с текстом и без текста в теле письма. отключал оформление и очищал формат (Кнопки "Оформить письмо/отключить оформление" и кнопка "Убрать форматирование" когда кнопка "Оформить письмо" нажата)
ВСЕГДА в письме дошедшем до gmail есть такие сроки:
Authentication-Results: mx.google.com;
dkim=fail header.i=@yandex.ru;
spf=softfail (google.com: domain of transitioning [e-mail] does not designate XXX.XXX.XXX.XXX as permitted sender) smtp.mailfrom=[e-mail];
dmarc=fail (p=NONE dis=NONE) header.from=yandex.ru

При этом блок DKIM-Signature в письмах с Мэйлру и в письмах с Яндекс не изменяется.
Для проверки отправляю письмо сразу на два ящика домена @firma.ru
один в Exchange другой на Gmail. Блок DKIM-Signature один в один. может как то надо их особым образом сравнивать?

НО! это еще не все ))
Нашлась последовательность действий которая таки дает dmarc=pass
надо зайти в отправленные, зайти в письмо, нажать ответить
удалить текст в теле письма и отправить
тогда
Authentication-Results: mx.google.com;
dkim=pass header.i=@yandex.ru;
spf=softfail (google.com: domain of transitioning [e-mail] does not designate XXX.XXX.XXX.XXX as permitted sender) smtp.mailfrom=[e-mail];
dmarc=pass (p=NONE dis=NONE) header.from=yandex.ru

Получается что Exchange что то меняет в теле письма все же? как то его переформатирует?
Не нашел такой настройки в Exchange еще. Может быть найду еще )
Если честно, я так и не понимаю почему например ответ на письмо в веб почте Яндекс проходит проверку DMARC.
------------------------------------------
Через полтора месяца удалось провести тестирование в окружении свежеустановленного Exchange 2013
результат тот же.

Comments

[webmatpoc]

Не сообразил сразу попробовать. Включил переадресацию для почтового ящика в Exchange на ящик в Gmail. Отправил почту с Мэйлру. Письмо на Gmail пришло..
хотя там
Authentication-Results: mx.google.com;
dkim=neutral (body hash did not verify) header.i=@mail.ru;
spf=softfail (google.com: domain of transitioning [e-mail] does not designate XXX.XXX.XXX.XXX as permitted sender) smtp.mailfrom=[e-mail];
dmarc=fail (p=REJECT dis=NONE) header.from=mail.ru
Запись dkim=neutral (body hash did not verify) означает что Gmail не проверял ХЭШ тела письма видимо, а почему интересно?
Понятнее не стало конечно.

[Владимир Дубровин]

webmatpoc: нет, эта запись означает, что хэш тела письма не проходит проверку. Яндекс пока не поддерживает DMARC.