Настройка DKIM, SPF и DMARC в Zimbra Collaboration Suite

Если при попытке отправить сообщение на почтовые сервера Gmail вы вдруг получили ошибку типа «Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.», то это почти всегда значит, что на вашем почтовом сервере не настроены DKIM, SFP и DMARC. Крупные почтовые серверы (Gmail, mail.ru, Яндекс) требуют наличие данных записей. Сегодня мы расскажем, как это сделать в Zimbra Collaboration Suite.

image

Настройка DKIM в Zimbra

DKIM (DomainKeys Identified Mail) — это метод e-mail аутентификации, основанный на проверке подлинности цифровой подписи. DKIM необходим для того, чтобы почтовые сервисы проверяли отправителя и защищали получателя письма от мошеннических рассылок, которые производятся с подменой адреса отправителя.

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

image

DKIM стал доступен с версии Zimbra 8.0. Настройка подписи состоит из двух этапов:

Первый этап: генерация ключей и селектора

Добавляем данные DKIM к домену, у которого еще нет существующей конфигурации DKIM:

Получаем:

Также можно обновить DKIM данные для домена:

Удалить DKIM данных для домена:

Извлечь сохраненные данных DKIM для домена:

Второй этап: обновление DNS-записей

Публичный ключ нужно добавить как TXT-запись в домен:

Обновите DNS, и проверьте результат выполнения команды:

Например:

Если получили ошибку:

Это означает, что файла /opt/zimbra/conf/opendkim.conf не существует, создать его можно командой:

Если возникнет необходимость отозвать ключ подписи DKIM, установите пустой «р=» тег в записи TXT.

По умолчанию создается 1024-битный ключ (зависит от версии ZCS), изменить размер можно параметром -b.

Sender Policy Framework (SPF)

SPF (Sender Policy Framework) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208. SPF-запись защищает от подделки вашего домена и позволяет предотвратить попадание в спам писем, отправленных с ваших адресов. SPF настраивается для адреса, используемого в envelope-from (SMTP конверте).

С помощью spf-записи владелец домена может указать список серверов, имеющих право отправлять email-сообщения для домена. В общем случае порядок следующий:

[версия] [механизмы] [-all | ~all | redirect]
Версия всегда spf1, модификаторы сообщают, кто может посылать почту:

  • a, mx — сервера из DNS записей A или MX соответственно,
  • ip4, ip6 — адрес сервера (можно указывать подсети, например: ip4:1.2.3.4/24),
  • include — взять данные с другого адреса

Параметры:

  • -all означает не принимать почту, если проверка механизма не прошла,
  • ~all если проверка не прошла, то действовать на усмотрение сервера получателя.
  • redirect означает забрать правила с другого сервера.

Рассмотрим примеры:

Пример 1
example.com. IN TXT «v=spf1 ip4:62.220.58.72 a mx -all»
Для домена example.com принимать письма, отправленные с ip-адреса 62.220.58.72, так же принимать с серверов указанных в A и MX записях, сообщения с других серверов должны быть отклонены.

Пример 2
example.com. IN TXT «v=spf1 redirect:example.org»
Получить правила с домена example.com.

Пример 3
example.com. IN TXT «v=spf1 include:_spf.google.com -all»
Получать письма только с smtp-серверов компании Google.

Настройка DMARC

Domain-based Message Authentication, Reporting and Conformance (идентификация сообщений, создание отчётов и определение соответствия по доменному имени) или DMARC — это техническая спецификация, созданная группой организаций для борьбы со спамерами, подделывающими адреса отправителей. Она основана на идентификации почтовых доменов отправителя на основании правил и признаков, заданных на почтовом сервере получателя.

Таким образом почтовый сервер сам решает, хорошее сообщение или плохое и действует согласно DMARC записи. Благодаря настройке DMARC владельцы доменов могут создавать правила обработки писем, которые поступили с доменов, не прошедших авторизацию.

После создания записей SPF и DKIM необходимо настроить проверку DMARC, добавив в DNS запись типа TXT (аналогично SPF). Параметры могут быть следующими:

Более подробно можно узнать в реестре тегов DMARC.

Правило для домена (что делать серверу-получателю, если проверка на spf и dkim не прошла) может быть одним из трех:

  • none — просто регистрировать сообщения для отчета, с самими сообщения ничего не делать;
  • quarantine – помечать такие сообщения как спам;
  • reject – отклонить получение сообщения на уровне SMTP.

Если вы хотите получать отчеты не забудьте указать адрес электронной почты в теге rua:

_dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@example.com" 

Результат добавления DNS-записей

Ниже показан пример dns записий, для зоны example.com:

$ORIGIN .
$TTL 3600
example.com IN SOA example.com. hostmaster.example.com. (
2017011011 ; serial
3600 ; refresh [1h]
600; retry [10m]
1209600 ; expire [14d]
3600 ; min TTL [1h]
)
NS ns1.example.com.
MX 10 ns1.example.com.
A 62.220.58.71
IN TXT "v=spf1 a mx ip4:62.220.58.71 ~all"

$ORIGIN example.com.
ECAC22D2-DCA2-11E6-BA30-B554729FE32B._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs5OCY0sX04ziF+sOHt/1kq3A7iAzAjBjb4JteaoFzu1q2uBOiQS0uyaFeY6CgSgRRbvPnq8cWLG/XMU0tM9gSGtgtWDmHOs6/+QgKp6zRmetfsyABA2Y2U+XJlVURUE5ai3KIA/njt7IGZ5yeFsdZIKmhOCAOPGCovq10xkZXHdjRwiqxbCYGXv2m3o74BcWtOLPfEvexD5PYx"
"aTWFbelJpGlDN7WdBCE+ObpLGkJ9co/1sVOcd3c9SHfPq3jcBAFm7oPX2ak7Fb7cslVK77lA2hBgMYqI2Sh+T64o6R33dU++Ej7CuImmv7PAqVUn5MjYr05t3LK9dwWM8Cm6aJ/QIDAQAB" ) ; ----- DKIM key ECAC22D2-DCA2-11E6-BA30-B554729FE32B for example.com
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:postmaster@example.com"
ns1 IN A 62.220.58.71
www 86400 IN CNAME example.com.

Автоматическое обновление SSL-сертификатов

Вы также можете автоматизировать продление сертификата. Это предотвратит истечение срока действия ваших сертификатов и может быть выполнено cron.

  1. Вывод предыдущей команды показывает, как неинтерактивно обновлять все ваши сертификаты:

  2. Задайте эту задачу для автоматического запуска один раз в месяц с помощью задания cron:

    Добавьте следующую строку в конец файла crontab:

     

    0 0 1 * * /opt/letsencrypt/letsencrypt-auto renew
    Обновление Давайте зашифруем постоянную ссылку
  1. Вернитесь в /opt/letsencryptкаталог:

  2. Загрузите любые изменения, сделанные в Let’s Encrypt, поскольку вы в последний раз клонировали или вытаскивали репозиторий, эффективно обновляя его:

Автоматическое обновление Давайте зашифруем (необязательно) Постоянная ссылка

Вы также можете использовать, cronчтобы поддерживать letsencrypt-autoклиента в актуальном состоянии.

0 0 1 * * cd /opt/letsencrypt && git pull

Техническое обслуживание Постоянная ссылка Продление SSL-сертификатов

  1. Вернитесь в /opt/letsencryptкаталог:

  2. Выполните команду, которую вы использовали на шаге 1 раздела « Создание сертификата SSL », добавив --renew-by-defaultпараметр:

Через несколько секунд должно появиться подтверждение, подобное приведенному ниже:

Let’s Encrypt обновил срок действия ваших сертификатов; в этом примере 31 марта 2016 года — новая дата истечения срока действия.

Заметка

Давайте зашифровать сертификаты на 90-дневную продолжительность жизни. Согласно Let’s Encrypt , это поощряет автоматизацию и минимизирует ущерб от ключевых компромиссов. Вы можете продлевать свои сертификаты в любое время в течение своей жизни.

Настройка HTTPS (SSL/TLS) в nginx

После получения сертификата для HTTPS нужно настроить nginx на его использование. Пусть наши ключи лежат в/etc/letsencrypt/live/example.com , где fullchain.pem  — это вся цепочка сертификатов, а privkey.pem  — это сертификат сервера.

У nginx файл настроек обычно расположен по пути /etc/nginx/sites-available/default. В файле настроек nginx уже есть настройки по умолчанию для HTTPS. Они закомментированы. Нужно их откомментировать и поправить несколько строк.

Закрытый ключ:
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem

Вся цепочка:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem

Заголовок, чтобы автоматически использовался HTTPS:
add_neader Strict-Transport-Security ‘max-age=604800’;

В итоге секция server для HTTPS будет выглядеть примерно так:

Также нужно настроить перенаправление с http на https для порта 80 (это уже другая секция server для HTTP):

 

Let’s Encrypt — бесплатный сертификат для HTTPS

Сегодня есть возможность получить абсолютно бесплатно и довольно быстро легальный и корректный сертификат для HTTPS. Для этого нужно воспользоваться услугами https://letsencrypt.org.

Здесь я выкладываю подробную инструкцию по получению сертификата с помощью Let’s Encrypt.

Сначала нужно установить git, если его ещё нет:

Затем получаем сам клиент letsencrypt:

Команда letsencrypt-auto  скачает все необходимые зависимости и обновит исходные коды клиента.

Получение и настройка сертификата для Apache:

./letsencrypt-auto —apache

Для nginx тоже есть подобная команда, но на текущий момент (декабрь 2015) на официальном сайте написано, что она в стадии бета и могут быть ошибки.

Для всех других платформ нужно использовать команду certonly.

Для получения сертификата с использованием «standalone» (может потребоваться остановить ваш сервер nginx  service nginx stop, или какой там у вас слушает порт 80) сервера для получения.

Вместо example.com  нужно подставить ваш домен.

Вам предложат ввести e-mail, который будет использоваться для важных сообщений и для восстановления потерянного ключа.
Затем вам нужно будет согласиться с лицензионным соглашением.

Ваш сертификат и вся цепочка сохранится по пути/etc/letsencrypt/live/example.com/

В этом каталоге будут ссылки на файлы с ключами:
privkey.pem  — приватный ключ для сертификата. Хранить в секрете. Это то, что Apache требует для SSLCertificateKeyFile, и nginx для ssl_certificate_key.

cert.pem  — только сертификат сервера, то что требует Apache для SSLCertificateFile.

chain.pem  — все сертификаты, которые должны обслуживаться браузером БЕЗ сертификата сервера. Это Apache требует для SSLCertificateChainFile.

fullchain.pem  — вся цепочка, объединение chain.pem и cert.pem. Это nginx требует для ssl_certificate.