Пользователь
0,0
рейтинг
21 октября 2010 в 11:13

Администрирование → DKIM — это просто

Здравствуйте.

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

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


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

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

Для работы с DKIM нам нужно:
  1. Поддержка DKIM почтовым сервером для подписывания отправляемой почты;
  2. Получение пары приватного и публичного ключа;
  3. Занесение в 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 — Аналогично отсутствию записи
Матрозов Олег @Mear
карма
116,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (31)

  • 0
    Спасибо за пост! На знал что такое есть… Но гугл как раз все емеилы отправлят в спам… И не знал как с этим бороться =)
    • +2
      У нас настроена только SPF запись, но всем основным мейл-сервисам этого оказалось достаточно
      • 0
        SPF у меня тоже стоит, но даже совместно с DKIM, например, тот же mail.ru так же продолжает помещать сообщения в спам. Зато DKIM дает возможность использовать для рассылок вот это:
        habrahabr.ru/blogs/google/101440/
        • 0
          Ну пока mail.ru нас любит, но DKIM может и настроим от греха подальше.

          А какая связь между DKIM и List-Unsubscribe?

          • 0
            Как я понимаю (и как следует из этого комментария в той теме) гугл не будет принимать отписку в случае отсутствия DKIM:
            habrahabr.ru/blogs/google/101440/#comment_3143799
            • 0
              Если верить документации гугла, то нужно чтобы он просто считал тебя добросовестным отправителем. Возможно гугл не будет считать тебя таковым без DKIM, но прямой связи нет
              • 0
                Да, я тоже не нашел в хелпе гугла про List-Unsubscribe прямого упоминания об этом. Хотя там действительно указано, что SPF и DKIM повышают «репутацию» отправителя. В любом случае SPF+DKIM — это лучше, чем их отсутствие )))
  • +1
    Кто-нибудь кроме больших почтовиков это использует? Технология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
    • 0
      Кто-нибудь кроме больших почтовиков это использует?


      Ну например тот же hMailServer проверяет DKIM на входе и в случае её не валидности выставляет вес сообщению для оценки на спам. Тут скорее всё зависит от того, как админ настраивающий почту относиться к этому вопросу. Например ведь можно ставить подозрение на спам для писем, у которых нет DKIM, SPF и т.д. (не дотаточный для лока письма) и еще сильнее увеличивать подозрение в случае невалидных этих записей.

      <blockquoteТехнология не решает проблемы подписанных релеев. И в таком случае я не понимаю чем оно лучше spf?
      Хм… в случае релея письмо будет не подписано и не будет содержать DKIM и соответственно принимающая сторона не будет проверять его наличие (т.е. будет dkim=netrual, а не dkim=fail). В случае SPF например и строгого соответствия это вызовет spf=fail или spf=softfail что в любом случае хуже). Просто в случае релея, как я понимаю, мы останемся на уровне «не использование DKIM», а не привнесем доп.проблем как в случае с SPF. Поправьте меня, если я ошибаюсь )))

      Да и… релеи — это скорее случай частной отсылки писем (т.е. лично человеком), а DKIM по моему будет больше полезен массовой, автоматизированной, рассылке. Где шанс быть отнесенным в спам намного выше. Так же не стоит забывать о фишинге, против чего DKIM тоже вполне хорошо себя проявляет. Тот же гугл писал в своём блоге:
      gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html
    • 0
      Например, довольно распространенный пакет Spamassassin.
  • 0
    вопрос конечно не по теме, но hMail поддерживает интеграцию с Active Directory?
    • 0
      Да.
    • 0
      Не, даже не так.
      Да, hMail поддерживает интеграцию с AD.
      Да, использовали в этом варианте, остались довольны.
  • 0
    Спасибо за столь краткое описание, побуждает наконец разобраться и сделать.
  • –1
    А чем Сервер DNS: Bind 9.7 лучше стандартного виндового днс сервера?
    • +1
      Тем, что он присутствует в Win 2008 WebServer ))) К сожалению стандартный виндовый поставляется только со Standart и выше, а так бы конечно использовал его.
  • 0
    Я в основном такие штуки кручу на Postfix на юниксах.
    Подход примерно тот же.
    Касаемо спама — ещё пользуюсь SPF, также помимо DKIM'а — Domainkeys'ами и ещё стараюсь сделать Feedback Loops с многими крупными провайдерами (Yahoo, AOL, Microsoft).

    Кстате, Yandex/Мыло.ру/Рамблер FeedbackLoop умеет? или они сразу вносят твой ИП в чёрный список и их ничего не волнует? (а-ля Gmail)
    • +2
      P.S.: Может статью написать? :)
      • 0
        Напиши, я вот хочу заморочиться своей почтой.
        • 0
          Я думаю, закончу проект свой и выделю пару часов для этого.
      • 0
        Поддерживаю. Думаю было бы интересно в итоге собрать воедино все что касается антиспама со стороны отправления почты (SPF, DKIM, DomainKeys… etc.)
    • 0
      Простите, а под Feedback Loops подразумеваются callout'ы?
  • +2
    Ох не стал бы я генерировать пары ключей на чужом сервере. Паранойя конечно, но кто помешает им теперь подписывать почту вашим ключом? Или продать ключ кому-то другому?
    openssl.exe genrsa -out tstpriv.pem 1024 — генерим секретный ключ (1024 — длина ключа).
    openssl.exe rsa -pubout -in tstpriv.pem -out tstpub.pem — получаем публичный ключ из секретного
    • 0
      Да, первоначально я так и делал. Пожалуй включу это в статью.
  • 0
    Даа, недавно тоже в дополнение к SPF прикрутил и DK/DKIM…
    Думаете, перестала нормальная почта с моего домена сыпаться в спам на гугловских ящиках? Нет.
    • 0
      Хм… может вы уже в списках «не доверенных»? Не факт, что гугл моментально реагирует на изменения и появление SPF/DK/DKIM не сразу сменит статус на «доверенный».

      Кстати, можно попробовать проверить, говоря выше в комментариях про List-Unsubscribe как раз говорилось про то, что эта фича работает в гугле только у «доверенных» отправителей. Попробуйте послать емайл с её поддержкой и проверьте, появиться ли ссылка на отписку.
  • +2
    Рекомендую публиковать ASDP записи в днс тоже, это позволит принимающему серверу понять, должно ли ваше письмо подписано или нет. RFC5617
    Просто добавляете запись TXT _adsp._domainkey.example.com, значения у записи может быть 3 dkim=unknown, dkim=all, dkim=discardable. Первый вариант это тоже самое что у вас такой записи нету. Второй все письма должны быть подписаны и 3 не подписанные письма не должны приниматься.
    • 0
      Спасибо, так же добавлю в топик.
  • 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
  • 0
    Я не могу понять, почему всякие чекеры SPF говорят что все Ок.
    @ TXT «v=spf1 ip4:77.93.ХХ.ХХ include:amazonses.com ~all»
    А отчет от гугла приходит такой:

    <dkim>pass</dkim>
    <spf>fail</spf>
    

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.