Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wptelegram domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wp-pagenavi domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114

Notice: Функция _load_textdomain_just_in_time вызвана неправильно. Загрузка перевода для домена kirki была запущена слишком рано. Обычно это индикатор того, что какой-то код в плагине или теме запускается слишком рано. Переводы должны загружаться при выполнении действия init или позже. Дополнительную информацию можно найти на странице «Отладка в WordPress». (Это сообщение было добавлено в версии 6.7.0.) in /home/u632055791/domains/itg.az/public_html/wp-includes/functions.php on line 6114
Реализация DKIM для Exchange Server 2013

Реализация DKIM для Exchange Server 2013

При построении современной почтовой системы нужно учитывать множество факторов, чтобы защитить получателей/отправителей почтовой системы от спамовых и фишинговых почтовых сообщений. Все мы хорошо знаем о Sender Policy Framework (SPF), который позволяет проверить не подделан ли домен отправителя почтового сообщения, но изощренность злоумышленников ставит перед нами новые задачи которые можно, а главное нужно решать с помощью стандартов DomainKeys Identified Mail (DKIM) и Domain-based Message Authentication, Reporting and Conformance (DMARC).

Для более глубокого понимая технологий советую просмотреть видео Дмитрия Разборнова DMARC, DKIM.

В этой же заметке мы подробно рассмотрим внедрение в реально работающую почтовую систему технологий DKIM и DMARC на базе почтовой системы Exchange Server 2013.

До недавнего времени в нашей компании использовалась схема исходящей почтовой корреспонденции Exchange Server 2013 –-> почтовый релей Exim 4.x (Linux Debian 7.x x64) –> интернет.  На почтовом релее был реализован агент DKIM, который успешно подписывал всю исходящую почту. К сожалению Exchange 2013 не имеет своего встроенного механизма, который может реализовывать подобное.

В свою очередь я пристально слежу за развитием проекта dkim-exchange, который очень бодро развивается и реализует поддержку DKIM в самых последних версиях Exchange.

При установке Exchange DKIM Signer на Exchange сервер устанавливается транспортный агент:

1
Единственной задачей этого агента является создание электронной цифровой подписи для письма, которое отправлено внешним получателям.

Таким образом мы решили отказаться от схемы с релеем и установить агента Exchange DKIM Signer непосредственно на Exchange сервер.

Установка агента Exchange DKIM Signer

1) Идем по ссылке и скачиваем файл Source Code (zip)

2

2) Распаковываем ZIP архив.

3) Открываем от имени администратора Exchange Management Shell  и переходим в распакованную папку.

4) Перед тем, как запустить PowerShell скрипт .install.ps1, зададим политику выполнения PowerShell скриптов:

Set-ExecutionPolicy Unrestricted

5) Запускаем скрипт установки  .install.ps1

20

Setup нам предлагает запустить Configuration.DkimSigner.exe, чтобы сконфигурировать агента, но мы не будем этого делать сейчас, нажимаем Enter. 

6) Теперь можно убедиться в том, что агент удачно установился в системе:

21

Конфигурирование агента Exchange DKIM Signer

1) Идем в папку “C:Program FilesExchange DkimSigner”  и запускаем Configuration.DkimSigner.exe и видим:

7
На скриншоте выше видно, что я использую не самую последнюю версию программы, произведем обновление после конфигурирования и проверки работоспособности агента. 

2) Нажимаем кнопку Configure:

8

Выбираем Exchange DkimSigner и понижаем приоритет до самого низкого. Это значит, что почтовое сообщение будет обрабатываться в последнюю очередь этим агентом, когда у письма будут окончательно сформированы все заголовки почтового сообщения, из документации:

Make sure that the priority of the DkimSigner Agent is quite low so that no other agent messes around with the headers. Best set it to lowest priority

3) Переходим на вкладку DKIM Settings и переключаем алгоритм хеширования на RsaSha256, Body Canonicalization, Header Canonicalization выставляем в Simple, из документации:

Possible values for HeaderCanonicalization and BodyCanonicalization are Simple (recommended) and Relaxed

Более подробно про параметры Body Canonicalization, Header Canonicalization можно прочитать вспецификации DKIM

На вкладке DKIM Settings так же можно настроить заголовки почтового сообщения, которые будут подписываться. Оставим все по умолчанию.

9
Не забываем нажать кнопку Save configuration.

4) Переходим на вкладку Domain Settings и удаляем домены по умолчанию example.com и example.org. Следующим шагом добавляем наш почтовый домен кнопкой Add и заполняем основные поля. Поле Domain Name  — это имя вашего почтового домена, например для адресов типа UserName@company.com это поле примет значение company.com

16

Поле Selector – это произвольная строка которая добавляется к имени домена. С помощью поля Selectorправильно идентифицируется public key в TXT записи на DNS сервере:

51

Если взять наше значение из поля Selector и посмотреть на Email Headers, то мы увидим тег s= который имеет значение из поля Selector, тег d= имеет значение указывающие на наш почтовый домен. Таким образом сервер получатель понимает какой именно public key на нашем DNS сервере нужно проверять.

rsz_52

Следующим шагом генерируем ключевую пару (public key и private key). Private key будет храниться строго на сервере, и с его помощью будет подписываться вся исходящая почта. Нажимаем кнопку Generate Key  и Exchange DKIM Signer предлагает нам сохранить *.xml файл в папку keys, что мы и делаем:

17
В итоге должно получиться три файла в папке keys для нашего почтового домена:

  • MailDomain.ru.xml
  • MailDomain.ru.xml.pub – файл содержит public key, в будущем мы разместим его в TXT-записи на нашем внешнем DNS сервере.
  • MailDomain.ru.xml.pem — файл содержит private key.

После сохранения *.xml файла не забываем нажать на кнопку Save Domain.

Далее Exchange Dkim Signer предлагает нам создать TXT-запись на внешнем DNS сервере который обслуживает наш почтовый домен:

41
В панели хостинг провайдера вашего DNS сервера создаем TXT запись:
42

Обратите внимание на то, что запись публичного ключа разделена кавычками (стрелочка под номером два). Когда я впервые настраивал TXT запись на DNS сервере, то столкнулся с проблемой, что электронно-цифровая подпись письма не проходила проверку на принимающем почтовом сервере.

После нескольких попыток перенастройки самого агента и TXT-записи DNS сервера, было принято решение написать в тех.поддержку DNS хостинг провайдера. Ответ от тех.поддержки был таким:

Размер записи превышает 255 символов и поэтому не обрабатывается. Вам нужно разбить на несколько IN TXT:

recname IN  TXT "foobar" "baz" "blivit" "alpha" ... "zulu"

После разбиения TXT-записи публичного ключа кавычками, письма стали успешно проходить проверку электронно-цифровой подписи на принимающем почтовом сервере.

Не все DNS хостинг провайдеры требуют разбивать TXT-запись менее чем на 255 символов, так как некоторые из них это делают прозрачно для пользователя.

После создания TXT-записи в DNS желательно подождать 5-8 минут и уже потом проверять работоспособность.

 

Проверка агента Exchange DKIM Signer

Отправим тестовые письма на известные почтовые домены gmail.com и yandex.com:

24
На скриншоте выше видно, что отработала только SPF запись.

Теперь посмотрим, как будет выглядеть скриншот после включения агента:

25

Получающий сервер, в данном случае gmail.com, определил, что почтовое сообщение было отправлено через действительный почтовый домен (SPF) и им же подписано (DKIM).

Посмотрим, как yandex.ru определяет, что сообщение имеет достоверную цифровую подпись:

33
Посмотрим на Email Headers на сервере получения gmail.com:

27

Посмотрим в логи агента на сервере Exchange:

28
Из представленных скриншотов выше можно сделать вывод, что мы удачно сконфигурировали агента и вся исходящая почта у нас имеет достоверную электронную цифровую подпись.

Кстати, более детальную информации по вашему почтовому домену и задействованных на нем технологиях можно получить отправив письмо на адрес mailtest@unlocktheinbox.com

 

Обновление агента Exchange DKIM Signer

Обновление реализуется очень легко. На скриншоте ниже видно, что я использую не последнюю версию агента. Чтобы это исправить, нужно просто нажать на кнопку Upgrade:

29

Обновление происходит быстро и не должно возникнуть проблем. Если у вас не получилось корректно обновиться, то всегда можно сохранить ключи и переустановить программу заново. Перезагрузка сервера не требуется.

Сколько я не тестировал обновление программы, оно завершалось удачей в 100% случаев:30

 

Удаление агента Exchange DKIM Signer

Удаление возможно через PowerShell скрипт .Uninstall.ps1 который находится там же, где и .Install.ps1, но в документации написано, что это нерекомендуемый способ удаления.

Простой и рекомендуемый способ удалить агента – это запустить Configuration.DkimSigner.exe из папки «C:Program FilesExchange DkimSigner», нажать на кнопку Configure, выбрать агента DkimExchange Signer и нажать кнопку Uninstall:

32
При успешном удалении вы увидите сообщение:

33

 

Итак, на практическом примере мы установили, сконфигурировали, проверили работу, обновили, удалили DKIM Signing Agent for Microsoft Exchange Server.