Настройка dkim на postfix

Введение

Речь пойдет про типовой почтовый сервер, настроенный самостоятельно на базе популярных бесплатных компонентов — Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 8. В качестве бэкенда для web сервера там используется apache, так что получать сертификаты будем с его помощью.

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

Тем не менее, последнее время наблюдается тенденция по выдавливанию самоподписанных сертификатов из обращения. Некоторый софт напрочь отказывается им доверять, не оставляя возможность пользователям это исправить. Вместо того, чтобы бороться с софтом, я предлагаю вам настроить всем известные сертификаты от let’s encrypt. К тому же сделать это относительно просто.

Получаем сертификат от Let’s Encrypt

Итак, я считаю, что вы настроили почтовый сервер по предложенной выше ссылке. Значит, у вас установлен веб сервер Apache, а так же все в порядке с dns записями. Сертификатов мы получим сразу два. Для доменных имен:

• mail.site.ru — имя почтового сервера, этот сертификат будут использовать postfix и apache
• webmail.site.ru — домен для web интерфейса почты, будет использовать веб сервер

Для настройки получения сертификатов let’s encrypt и настройки apache, нам нужно будет установить несколько пакетов. Напоминаю, что речь идет про Centos 8. В других системах настройка будет аналогичной, только имена пакетов могут отличаться.

# dnf install certbot python3-certbot-apache mod_ssl

Пакеты эти живут в репозитории epel, так что если он еще не подключен, подключите.

# dnf install epel-release

Дальше нам нужно добавить 2 виртуальных домена в настройки apache. Для этого создаем 2 конфига в директории /etc/httpd/conf.d/.

1. mail.site.ru.conf

<VirtualHost *:443>
 ServerName mail.site.ru
 DocumentRoot /var/www/mail.site.ru/
 <Directory /var/www/mail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/mail.site.ru-error.log
 CustomLog /var/log/httpd/mail.site.ru-access.log combined
</VirtualHost>

<VirtualHost *:80>
 ServerName mail.site.ru
 DocumentRoot /var/www/mail.site.ru/
 <Directory /var/www/mail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/mail.site.ru-error.log
 CustomLog /var/log/httpd/mail.site.ru-access.log combined
</VirtualHost>

2. webmail.site.ru.conf

<VirtualHost *:443>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
</VirtualHost>

<VirtualHost *:80>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
</VirtualHost>

По сути конфиги идентичные, только названия доменов разные. Теперь можно проверить конфигурацию apache и перезапустить его.

# apachectl -t
# apachectl reload

Если увидите ошибку:

AH00526: Syntax error on line 85 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/pki/tls/certs/localhost.crt' does not exist or is empty

Просто удалите конфиг /etc/httpd/conf.d/ssl.conf. Он нам не нужен.

Если нет ошибок, то можно запускать certbot и получать сертификаты. Делается это очень просто.

# certbot --apache

Если все прошло без ошибок, то вы увидите в директории /etc/letsencrypt/live две папки с сертификатами для каждого из доменов.

Так же certbot автоматически добавит в конфигурации виртуальных хостов apache несколько дополнительных параметров.

<VirtualHost *:443>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
 SSLCertificateFile /etc/letsencrypt/live/mail.site.ru/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/mail.site.ru/privkey.pem
 Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

<VirtualHost *:80>
 ServerName webmail.site.ru
 DocumentRoot /var/www/webmail.site.ru/
 <Directory /var/www/webmail.site.ru/>
  Options -Indexes +FollowSymLinks
  AllowOverride All
 </Directory>
 ErrorLog /var/log/httpd/webmail.site.ru-error.log
 CustomLog /var/log/httpd/webmail.site.ru-access.log combined
 RewriteEngine on
 RewriteCond %{SERVER_NAME} =mail.site.ru
 RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} 
</VirtualHost>

В этот виртуальный хост установите веб почту, если вам она нужна.

Выбор сервера отправки в зависимости от адреса получателя

Итак, в sender_bcc_map всю локальную почту я оставляю локально, просто указывая адрес отправителя (каждый сайт шлет почту от своего ящика) и локального пользователя, к которому она будет складываться. Если у вас много сайтов, то для каждого сайта будет свой локальный пользователь. Чаще всего это так, потому что разные сайты лучше всего запускать под разными пользователями, от которых работает веб сервер. Файл с записями для sender_bcc_map выглядит так:

[email protected] user1
[email protected] user2

Если у вас использует разные ящики для отправки, то можете настроить правило для всего домена сразу:

*@site1.ru user1
*@site2.ru user2

Дальше вам нужно выяснить, как выглядит полностью адрес домена для локальной доставки почты. Это имя задается в параметре mydomain в конфиге postfix main.cf. Допустим, там указано имя сервера — websrv.site.ru. Это не принципиально, в нашем случае там можно написать все, что угодно, но лучше использовать полное доменное имя (fqdn) самого веб сервера, которое указано в DNS записи типа А.

Теперь создаем файл transport_map, в котором пишем следующее:

websrv.site.ru local

Мы явно указываем, что всю почту для домена websrv.site.ru отправлять локально. Не забываем построить индексированный файл:

# postmap /etc/postfix/transport_map

Отправляемся в конфиг main.cf и добавляем туда параметр:

transport_maps = hash:/etc/postfix/transport_map

Перезапускаем postfix и проверяем работу. При отправке почтового сообщения от имени пользователя [email protected] там должно быть примерно следующее:

websrv postfix/smtpd: CC8F0602E205: client=localhost
websrv postfix/cleanup: CC8F0602E205: message-id=<[email protected]>
websrv postfix/qmgr: CC8F0602E205: from=<[email protected]>, size=874, nrcpt=2 (queue active)
websrv postfix/smtpd: disconnect from localhost ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
websrv postfix/local: CC8F0602E205: to=<[email protected]>, relay=local, delay=0.07, delays=0.06/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
websrv postfix/smtp: CC8F0602E205: to=<[email protected]>, relay=smtp.yandex.ru:465, delay=0.93, delays=0.06/0.01/0.23/0.63, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on myt6-9bdf92ffd111.qloud-c.yandex.net as 1608951012-xOUj8gBhbE-oCJSqvIX)
websrv postfix/qmgr: CC8F0602E205: removed

Получили в итоге то, что хотели. Внешняя почта отправляется через внешний smtp адрес, указанный в relayhost, а копии сообщений падают в локальный ящик, который находится в файле /var/mail/user1. Конкретно мне это нужно было для отладки, чтобы понять, что именно отправляет сайт.

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

sender_bcc_maps:

*@site1.ru [email protected] 
*@site2.ru [email protected]

transport_map:

backupmail.ru relay::25

В данном случае backupmail.ru это отдельный почтовый домен и почтовый сервер для него для сбора всей вашей почты. Это не обязательно может быть собственноручно настроенный почтовый сервер. Можете использовать ящик в какой-то готовой службе почты. Но имейте ввиду, если это будет какой-то бесплатный сервис, то он вас быстро заблокирует, если будете слать слишком много почты на этот ящик.

Заключение

Я постарался рассказать подробно и понятно о полной настройке ELK Stack. Информацию в основном почерпнул в официальной документации. Мне не попалось более ли менее подробных статей ни в рунете, ни в буржунете, хотя искал я основательно. Вроде бы такой популярный и эффективный инструмент, но статей больше чем просто дефолтная установка я почти не видел. Буквально одна на хабре попалась с какой-то более ли менее кастомизацией.

Какие-то проверенные моменты я не стал описывать в статье, так как посчитал их неудобными и не стал использовать сам. Например, если отказаться от logstash и отправлять данные с beats напрямую в elasticsearch, то на первый взгляд все становится проще. Штатные модули beats сами парсят вывод, устанавливают готовые визуализации и дашборды в Kibana. Вам остается только зайти и любоваться красотой Но на деле все выходит не так красиво, как хотелось бы. Кастомизация конфигурации усложняется. Изменение полей в логах приводит к более сложным настройкам по вводу этих изменений в систему. Все настройки поступающей информации переносятся на каждый beats, изменяются в конфигах отдельных агентов. Это неудобно.

В то же время, при использовании logstash, вы просто отправляете данные со всех beats на него и уже в одном месте всем управляете, распределяете индексы, меняете поля и т.д. Все настройки перемещаются в одно место. Это более удобный подход. Плюс, при большой нагрузке вы можете вынести logstash на отдельную машину.

Я не рассмотрел в своей статье такие моменты как создание визуализаций и дашбордов в Кибана, так как материал уже и так получился объемный. Я устал писать эту статью Смотрите остальные мои материалы по данной теме. Там есть примеры.

Так же я не рассмотрел такой момент. Logstash может принимать данные напрямую через syslog. Вы можете, к примеру, в nginx настроить отправку логов в syslog, минуя файлы и beats. Это может быть более удобно, чем описанная мной схема. Особенно это актуально для сбора логов с различных сетевых устройств, на которые невозможно поставить агента, например mikrotik. Syslog поток так же можно парсить на ходу с помощью grok. Отдельно надо рассмотреть автоочистку старых индексов в elasticsearch.

Подводя итог скажу, что с этой системой хранения логов нужно очень вдумчиво и внимательно разбираться. С наскока ее не осилить. Чтобы было удобно пользоваться, нужно много всего настроить. Я описал только немного кастомизированный сбор данных, их визуализация — отдельный разговор. Сам я постоянно использую и изучаю систему, поэтому буду рад любым советам, замечаниям, интересным ссылкам и всему, что поможет освоить тему.

Все статьи раздела elk stack — https://serveradmin.ru/category/elk-stack/.

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .