MKB phpBB

Источник: https://habrahabr.ru/post/106589/

Настройка DKIM

Здравствуйте.
Хочу поделиться своим небольшим опытом прикручивания DKIM (DomainKeys Identified Mail) к своему домену и почтовому серверу.

Мы имеем:
Платформа: Windows WebServer 2008;
Сервер DNS: Bind 9.7;
Почтовый сервер: hMailServer 5.3.3. http://www.hmailserver.com/

Задача:
Разобраться в системе подписи сообщений DKIM, что бы gmail признал её валидной и выдал заветные: dkim=pass.

Начнем с начала. Что такое DKIM вообще и что нам нужно, что бы наша почтовая система отправляла почту с поддержкой DKIM.

Из описания DKIM в Wiki:

DomainKeys Identified Mail метод E-mail аутентификации.
Технология DomainKeys Identified Mail (DKIM) объединяет несколько существующих методов антифишинга и антиспама с целью повышения качества классификации и идентификации легитимной электронной почты. Вместо традиционного IP-адреса, для определения отправителя сообщения DKIM добавляет в него цифровую подпись, связанную с именем домена организации. Подпись автоматически проверяется на стороне получателя, после чего, для определения репутации отправителя, применяются «белые списки» и «чёрные списки».
В технологии DomainKeys для аутентификации отправителей используются доменные имена. DomainKeys использует существующую систему доменных имен (DNS) для передачи открытых ключей шифрования.

Для работы с DKIM нам нужно:
Поддержка DKIM почтовым сервером для подписывания отправляемой почты;
Получение пары приватного и публичного ключа;
Занесение в DNS домена необходимых записей о наличии поддержки DKIM.

С поддержкой DKIM почтовым серверов всё вполне понятно. hMailServer с версии 5.1 поддерживает подпись исходящей корреспонденции ключом.

Теперь необходимо найти, как сформировать пару секретного и публичного ключа. После перебора нескольких вариантов я остановился на web-утилите сервиса port25.com которая, кроме формирования необходимых ключей, так же генерирует и подсказку по DNS записям:
www.port25.com/support/support_dkwz.php

Небольшое пояснение по поводу некого поля «domain selector». Данное поле позволяет привязать к одному домену несколько DKIM записей для разных нужд (например для разных почтовых серверов). В моём случае у меня только один почтовый сервер и у меня нет необходимости в селекторе, так что в роли селектора я выбрал просто «mail».

Полученный приватный ключ сохраняем на сервер в папку, к которой имеет доступ почтовый сервер. Публичный ключ в принципе можно не сохранять в виде файла. Он нам пригодиться только для внесения необходимой записи в DNS. В конфигурации домена в hMailServer нам необходимо указать путь к приватному файлу ключа, а так же указать выбранный селектор (напомню, я в виде селектора взял «mail»).

В файле DNS-зоны нам необходимо указать записи вида:

_domainkey.example.com. TXT "t=s; o=~;"
mail._domainkey.example.com. TXT "k=rsa\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQmO9AuWRbWPgl/jzDPQodrLfFLFqYYi6bCBnsTOCOJQrFbGgiR1C01j4zLw8XgG3rQ0WAaeg6Z/y39Ah7IONfs5gQuK6eGZMmYwIsZyz2dQoUDmDLCb1WygpkrqsCbyPw3SWGihM4iChOwo7Ovo2mTOWOf5ejeZcP2qqNb9nRMQIDAQAB"

Где «mail» перед _domainkey во второй записи — это не что иное, как наш выбранный селектор, а длинный набор символов в той же записи идущий после «p=» — это наш публичный ключ.

Вроде бы всё. Теперь попробуем отправить письмо с нашего почтового сервера на почту gmail, так как доподлинно известно, что gmail проверяет DKIM. Смотрим в полученное письмо в gmail и видим заветные строки:
Authentication-Results: mx.google.com; spf=pass (google.com: domain of example@example.com designates 123.123.123.123 as permitted sender) smtp.mail=example@example.com; dkim=pass header.i=@example.com

Поздравляем меня с успешным покорением DKIM ))), чего и вам желаю. Удачи.

UPD: Для получения пары ключей без использования внешних сервисов можно воспользоваться OpenSSL:
openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного

Спасибо lorc за дополнение.

UPD 2: Небольшое дополнение от nshopik:
Так же можно у домена прописать ADSP запись (RFC5617) — это позволит принимающему серверу понять, должно ли ваше письмо быть подписано или нет.
Запись выгладит таким образом:
_adsp._domainkey.example.com. TXT "dkim=all"

Значений dkim= может быть три:
all — Все письма должны быть подписаны
discardable — Не подписанные письма не должны приниматься
unknown — Аналогично отсутствию записи
dkim, e-mail, антиспам

Примечания:
Mear 21 октября 2010 в 15:57 0
SPF у меня тоже стоит, но даже совместно с DKIM, например, тот же mail.ru так же продолжает помещать сообщения в спам. Зато DKIM дает возможность использовать для рассылок вот это:
https://habrahabr.ru/blogs/google/101440/

А какая связь между DKIM и List-Unsubscribe?
Mear 21 октября 2010 в 16:13 0
Как я понимаю (и как следует из этого комментария в той теме) гугл не будет принимать отписку в случае отсутствия DKIM:

habrahabr.ru/blogs/google/101440/#comment_3143799

bes_internal 21 октября 2010 в 13:33 +1
Кто-нибудь кроме больших почтовиков это использует? Технология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
Mear 21 октября 2010 в 16:07 0
Ну например тот же hMailServer проверяет DKIM на входе и в случае её не валидности выставляет вес сообщению для оценки на спам. Тут скорее всё зависит от того, как админ настраивающий почту относиться к этому вопросу. Например ведь можно ставить подозрение на спам для писем, у которых нет DKIM, SPF и т.д. (не дотаточный для лока письма) и еще сильнее увеличивать подозрение в случае невалидных этих записей.
Хм… в случае релея письмо будет не подписано и не будет содержать DKIM и соответственно принимающая сторона не будет проверять его наличие (т.е. будет dkim=netrual, а не dkim=fail). В случае SPF например и строгого соответствия это вызовет spf=fail или spf=softfail что в любом случае хуже). Просто в случае релея, как я понимаю, мы останемся на уровне «не использование DKIM», а не привнесем доп.проблем как в случае с SPF. Поправьте меня, если я ошибаюсь )))
Да и… релеи — это скорее случай частной отсылки писем (т.е. лично человеком), а DKIM по моему будет больше полезен массовой, автоматизированной, рассылке. Где шанс быть отнесенным в спам намного выше. Так же не стоит забывать о фишинге, против чего DKIM тоже вполне хорошо себя проявляет. Тот же гугл писал в своём блоге:
https://gmailblog.blogspot.com/2008/07/ ... aypal.html

arc 21 октября 2010 в 13:38 0
вопрос конечно не по теме, но hMail поддерживает интеграцию с Active Directory?
amc 21 октября 2010 в 13:50 0
Да, hMail поддерживает интеграцию с AD.
Да, использовали в этом варианте, остались довольны.

Andrey_Zentavr 21 октября 2010 в 14:07 0
Я в основном такие штуки кручу на Postfix на юниксах.
Подход примерно тот же.
Касаемо спама — ещё пользуюсь SPF, также помимо DKIM'а — Domainkeys'ами и ещё стараюсь сделать Feedback Loops с многими крупными провайдерами (Yahoo, AOL, Microsoft).
Кстате, Yandex/Мыло.ру/Рамблер FeedbackLoop умеет? или они сразу вносят твой ИП в чёрный список и их ничего не волнует? (а-ля Gmail)
juise 21 октября 2010 в 15:44 0
Простите, а под Feedback Loops подразумеваются callout'ы?
Andrey_Zentavr 21 октября 2010 в 16:44 0
Детали можно посмотреть здесь (на английском): http://www.returnpath.net/resources/arc ... ctions.pdf

lorc 21 октября 2010 в 14:20 +2
Ох не стал бы я генерировать пары ключей на чужом сервере. Паранойя конечно, но кто помешает им теперь подписывать почту вашим ключом? Или продать ключ кому-то другому?
openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного

drunken 21 октября 2010 в 18:53 0
Даа, недавно тоже в дополнение к SPF прикрутил и DK/DKIM…
Думаете, перестала нормальная почта с моего домена сыпаться в спам на гугловских ящиках? Нет.
Mear 21 октября 2010 в 19:11 0
Хм… может вы уже в списках «не доверенных»? Не факт, что гугл моментально реагирует на изменения и появление SPF/DK/DKIM не сразу сменит статус на «доверенный».
Кстати, можно попробовать проверить, говоря выше в комментариях про List-Unsubscribe как раз говорилось про то, что эта фича работает в гугле только у «доверенных» отправителей. Попробуйте послать емайл с её поддержкой и проверьте, появиться ли ссылка на отписку.
nshopik 21 октября 2010 в 19:11 +2
Рекомендую публиковать ASDP записи в днс тоже, это позволит принимающему серверу понять, должно ли ваше письмо подписано или нет. RFC5617
Просто добавляете запись TXT _adsp._domainkey.example.com, значения у записи может быть 3 dkim=unknown, dkim=all, dkim=discardable. Первый вариант это тоже самое что у вас такой записи нету. Второй все письма должны быть подписаны и 3 не подписанные письма не должны приниматься.

zipo 21 сентября 2012 в 17:27 0
Добавлю сюда свою проблему с dkim и ее решение. Может кто найдет через поиск и поможет решить такую же проблему.
Настроил себе на сервере dkim чрез dkim-milter (dkim-filter) для postfix. Проверил — все работает, gmail в заголовках показывает dkim=pass. Радости было много, но как выяснилось не надолго.
Через время (месяц) обнаруживаю, что некоторые письма не проходят проверку dkim и в заголовках того же gmail красуется
dkim=neutral (body hash did not verify)
Это значит что хеш подписи не сходится с текушим хешем тела письма. Эта ситуаци происходит когда, что-то изменило тело письма после совершения подписи по dkim. В моем случае после фильтра dkim-milter, что-то меняло тело письма.
Ситуаций, когда что-то меняет тело может быть много, в инете достаточно много такий кейсов когда избранные письма не проходят dkim проверку.
Мой же случай оказался в том, что тело некоторых писем состовлялось из файлов, которые были с EOL (End Of Line) в формате windows, т.е. \r\n и по всей видимости постфикс после дким фильтра менял формат EOL на Unix, т.е. — \n