Установка и настройка postfix и dovecot на ubuntu 20.04

Потребности в почте у среднего бизнеса

Начнем с того, что я подразумеваю под средним бизнесом. Я не знаю точную классификацию и нигде не смотрел, не проверял. Мне интуитивно кажется, что это от 10-15 пользователей до 200-300. Я же буду рассматривать сегмент до 100 пользователей, так как почти все время работаю исключительно в этой нише. Проблемы и потребности более крупных компаний мне достоверно неизвестны. Хотя не уверен, что что-то будет принципиально отличаться от 100 человек, думаю подходы будут те же самые, только железо мощнее. Проблемы распределение нагрузок и кластеризации тут скорее всего еще не будут стоять.

Есть у нас небольшая компания на несколько десятков человек. Нам нужен почтовый сервер. Несмотря на то, что технологии давно шагнули вперед, предоставив массу всевозможных средств коммуникации, электронная почта все равно плотно стоит на своих позициях и не собирается их пока уступать. При этом в таком небольшом коллективе, больших требований к почтовому серверу не предъявляют. Чаще всего достаточно, чтобы почта просто работала, без особых функциональных изысков. Будет достаточно либо почтового клиента и протокола imap, либо web интерфейса. Хорошо, если будет возможность настроить автоответ, делать общие папки, единую адресную книгу, но и без этого можно прожить.

Среди всех возможных вариантов почтового сервиса, я выделяю 3 принципиально разных подхода к реализации необходимого функционала:

Сервисы на основе бесплатных почтовых служб гугла, яндекса или мейл.
Свой почтовый сервер на основе бесплатного ПО.
Exchange сервер от Microsoft.

Разберем каждый из них поподробнее.

Немного теории

Перед конкретными инструкциями и брожением по коду не обойтись без доли теоретического материала

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

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

Почтовые серверы на Linux существенно отличаются от оных на Windows и других системах. На Винде это уже готовая закрытая программа, которой остаётся только начать пользоваться. Дистрибутивы Линукса же предполагают самостоятельную настройку всех компонентов. Причём сервер будет в итоге состоять не из одной программы, а из нескольких. Мы будем использовать Postfix в сочетании с Dovecot.

Почему Postfix?

На Убунту существует несколько почтовых клиентов, но всё же мы выбрали именно этот

Настройка Posfix на Ubuntu гораздо легче, чем того же SendMail, а это важно для начинающего пользователя. В сочетании с Dovecot Postfix способен выполнять всё то, что обычно требуют от почтовых серверов

Postfix — это непосредственно сам агент передачи почты. Ему и предстоит сыграть главную роль во всём представлении. Это программа с открытым исходным кодом, которую используют по умолчанию многие серверы и веб-сайты. Dovecot — это агент получения доставки почты.

Managing Spam With SpamAssassin: Stop spam on Postfix, Dovecot, And MySQL

Install SpamAssassin:
Next, create a user for SpamAssassin daemon(spamd):
Edit the configuration file. Set the home directory, update the parameter with the user that was just created (as well as the home directory), and update the parameter to .

File: /etc/default/spamassassin

Here is a
detailed documentation of SpamAssassin’s configuration file that you can refer to while working through these next steps.
File: /etc/spamassassin/local.cf
File: /etc/postfix/master.cf
Start Spamassassin and enable the service to start on boot:

If not using systemd (as is the case with Debian 7 and earlier), edit the configuration file instead. Set the parameter to .

Обслуживание почтовой системы, которая должна выполнять массовые рассылки

Не стоит надеяться, что правильно настроенный сервер будет всегда хорошо справляться со своей задачей. Необходимо заниматься его обслуживанием, так как поведения фильтров могут меняться, как и сущность СПАМа и методы борьбы с ним.

Проверка корректности настройки для домена. Время от времени, проверяйте свой домен с помощью сервиса mxtools.
Эффективность рассылок. Выполняем проверку наших рассылок при помощи специализированных сервисов — Постмастер от mail.ru и Postmasters Tools от Google. На основе данных незамедлительно принимаем решение об исключении определенных адресов из рассылки и выполняем все рекомендации систем.
Наличие в черных списках. Проверяйте наличие домена/IP-адреса в черных списках. Ранее мы говорили, что это можно сделать на сайтах dnsbl.smtp.bz, 2ip.ru, dnsbl.info и syslab.ru.
Держим руку на пульсе. Время от времени, перечитываем требования к честным рассылкам, например, у Яндекса и . В них могут появляться новые требования.
Анализируем log. Находим по логам неудачные попытки отправить сообщения. Большинство из них делятся на две категории — soft bounce (мягкие возвраты) и hard bounce (жесткие возвраты). Первые означают, что ошибка отправки произошла на принимающей стороне — это может быть переполнение ящика, временная его блокировка, другими словами — временные явления и попытки отправки сообщений этому адресату можно повторить позже. Жесткие возвраты сигнализируют о постоянной проблеме, как правило, отсутствующем адресате. За ошибками hard bounce нужно внимательно следить и реагировать, удаляя несуществующих адресатов из списка рассылки.
Отправляем тестовые сообщения. Используем сервисы mail-tester.com и spamtest.smtp.bz для периодической отправки сообщений и проверки, что наш сервер настроен правильно.

Настройка аутентификации на Postfix

Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.

а) если используем Ubuntu / Debian:

apt-get update

apt-get install postfix dovecot-imapd dovecot-pop3d

б) если используем CentOS / Red Hat:

yum install postfix dovecot

После установки пакетов, разрешаем автозапуск dovecot и postfix:

systemctl enable postfix dovecot

Открываем на редактирование конфигурационный файл нашего MTA Postfix:

vi /etc/postfix/main.cf

Добавляем строки (или меняем значения):

smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination

* где:

smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
- permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
- permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
- reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.

Проверяем корректность настройки:

postconf > /dev/null

Если команда не вернула ошибок, перезапускаем Postfix:

systemctl restart postfix

Переходим к настройке dovecot — открываем файл:

vi /etc/dovecot/conf.d/10-master.conf

… и приводим опцию service auth к следующему виду:

service auth {
…
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
…
}

* если соответствующей секции unix_listener нет, то ее нужно создать

Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth

Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):

vi /etc/dovecot/conf.d/10-ssl.conf

Проверяем, чтобы значение ssl не было required:

ssl = yes

* нас устроит оба варианта — yes или no.

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

* данные механизмы позволяют передачу данных в открытом виде.

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

Если команда ничего не вернула, перезапускаем сервис:

systemctl restart dovecot

В качестве логина и пароля можно использовать любую системную учетную запись. Создадим ее для теста:

useradd smtptest

passwd smtptest

Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:

Пробуем отправить письмо. Отправка должна потребовать ввода логина и пароль — используем аутентификационные данные для записи, созданной выше.

Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.

Подключение LDAP

И так, наш сервер требует ввода логина и пароля от системных учетных записей для отправки писем. Теперь сделаем так, чтобы эти учетные записи брались из LDAP (на примере Active Directory).

В службе каталогов нам нужна учетная запись со стандартными правами — ее мы будем использовать для подключения к LDAP. Создаем служебную учетную запись, например, postfix в корневом контейнере Users. Таким образом, в моем примере, это будет запись cn=postfix,cn=Users,dc=dmosk,dc=local (в домене dmosk.local).

Теперь возвращаемся на наш сервер. Если у нас Debian/Ubuntu, необходимо установить пакет dovecot-ldap:

apt-get install dovecot-ldap

Открываем файл:

vi /etc/dovecot/dovecot-ldap.conf.ext

* в системах deb файл уже будет создан и в нем будут приведены примеры настройки; в системах RPM файл будет создан новый файл.

Добавляем в него следующее:

hosts = dmosk.local
ldap_version = 3
auth_bind = yes
dn = cn=postfix,cn=Users,dc=dmosk,dc=local
dnpass = ldap-password-for-postfix
base = ou=Пользователи,dc=dmosk,dc=local
scope = subtree
deref = never
pass_filter = (&(objectCategory=Person)(sAMAccountName=%n))
user_filter = (&(objectCategory=Person)(sAMAccountName=%n))

* где:

hosts — имя нашего сервера ldap (в моем примере указан домен, так как по нему у меня разрешается кластер LDAP).
ldap_version — версия ldap. Как правило, третья.
auth_bind — указываем, нужно ли выполнять аутентификацию при связывании с LDAP.
dn — учетная запись для прохождения авторизации при связывании со службой каталогов.
dnpass — пароль от записи для прохождения авторизации.
base — базовый контейнер, в котором мы ищем наших пользователей. Нельзя использовать поиск на уровне домена. Внимательнее проверяем путь на предмет использования контейнеров (CN) или организационных юнитов (OU).
scope — указывает на каком уровне нужно искать пользователей:
- subtree — во всех вложенных контейнерах.
- onelevel — во всех вложенных контейнерах, но на один уровень.
- base — только в контейнере, который указан в base.
deref — параметр означает использование поиска по разыменованным псевдонимам. К сожалению, не нашел подробного описания. Обычно, не используется.
pass_filter — фильтр для поиска паролей пользователей. Его формат зависит от используемой реализации LDAP. В нашем примере это Active Directory.
user_filter — фильтр для поиска учетных записей пользователей. Формат зависит от того, какую реализацию для LDAP мы используем.

Не знаю причину, но если для base указать корневой путь к домену, например, dc=dmosk,dc=local, наша связка не будет работать, а система вернет ошибку … failed: Operations error.

Открываем файл:

vi /etc/dovecot/conf.d/10-auth.conf

Комментируем строку для использования аутентификации по системных учетных записям и снимаем комментарий для аутентификации в ldap. Получим следующий результат:

#!include auth-system.conf.ext
…
!include auth-ldap.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

И перезапускаем его:

systemctl restart dovecot

Возвращаемся к настроенному почтовому клиенту и меняем параметры для авторизации с smtptest на учетную запись из домена, например, master@dmosk.local. Проверяем отправку письма — системы должна запросить пароль и отправить письмо при успешной проверке пользователя.

Можно переходить к настройке почтовых ящиков для пользователей из LDAP.

Install Packages

Log in to your Linode via SSH. Replace with your IP address:
Update your system and then install the packages needed in this guide:

You will not be prompted to enter a password for the root MySQL user for recent versions of MySQL. This is because on Debian and Ubuntu, MySQL now uses either the or authorization plugin by default. This authorization scheme allows you to log in to the database’s root user as long as you are connecting from the Linux root user on localhost.

Versions

The following software versions are compatible with the instructions in this guide:

Postfix 3.3.x and 3.4.x
Dovecot 2.2.x and 2.3.x
MySQL 5.7 and 8.0 (or MariaDB 10.3)

While other versions are possibly fully compatible as well, they may require different commands or additional configuration.

3 решения для организации корпоративной почты

Создать свой почтовый сервер для рассылки и сбора почты — не единственное решение. Организовать корпоративную почту можно и другими способами. Выбор способа зависит от масштабов вашего бизнеса, его направленности и бюджета, который вы готовы выделить на обслуживание почты.

Бесплатный email

Плюсы:

простой и функциональный интерфейс;
бесплатное пользование сервисом;
отсутствие необходимости настройки ресурсных записей (но если вы хотите применить свои настройки, то этот пункт из плюса перерастает в минус).

Минусы:

ограниченная почтовая квота (это дисковое пространство на сервере, выделенное под вашу почту);
большинство красивых имен занято (например, вида имя + фамилия);
сложно подчеркнуть бренд или обозначить принадлежность почтового ящика к определенной компании;
небезопасно (например, при увольнении сотрудник может сменить пароль к почтовому ящику, с которым он работал, а компания потерять доступ к важным данным).

Почта на домене

Вы можете зарегистрировать домен, созвучный названию вашей компании, и использовать его для создания почтовых ящиков в любом сервисе, который предоставляет услугу почты на домене. Так, имя почтового ящика будет оканчиваться названием компании, а начинаться с чего угодно: с названия отдела, фамилии и имени сотрудника и т.д. Ящик имеет вид: mail@yourdomain.ru

Плюсы:

большинство сервисов предоставляет услугу почты бесплатно, вы оплачиваете только обслуживание домена;
работа с корреспонденцией как в web-интерфейсе, так и любом удобном почтовом клиенте;
широкий функционал, доступный сразу после создания почтового ящика: антиспам, увеличение почтовой квоты, настройка фильтров, переадресации, сбора почты и т.д.

Минусы:

отсутствие возможности тонкой настройки сервера «под себя»;
при возникновении сбоев в работе сервера вы не можете повлиять на их устранение.

Персональный почтовый сервер

Это как почта для домена, которая описана в предыдущем пункте, только расширенная версия — вы настраиваете не только домен, но и сам сервер.

Плюсы:

гибкая настройка сервера под свои нужды: резервное копирование, ограничение доступа, правила пересылки и удаления писем, белые и черные списки и т.д.
мониторинг работы почтового сервера и доступ к логам (например, если письмо не будет доставлено, вы сможете найти причину и решить проблему);
контроль работы и надежности сервера.

Минусы:

материальные расходы на покупку или аренду необходимого оборудования;
технические знания (для настройки сервера понадобится специалист с навыками администрирования Linux или Windows Server).

Как настроить почтовый сервер на своем домене

Настройка почтового сервера проходит в несколько этапов:

Развертывание сервера. Это может быть либо компьютер, работающий 24/7 в вашем офисе, или виртуальный сервер на Digital Ocean, Amazon Web Services, Google Cloud или любом другом облачном провайдере.
Настройка почты. Далее необходимо настроить саму почту — эти самые почтовые агенты, которые отправляют и получает электронные сообщения. Можно воспользоваться готовым решением типа Iredmail или собрать свои компоненты.
Сервер контактов и календарей. Пользователи привыкли пользоваться контактами и календарями. Эту инфраструктуру почты также нужно развернуть отдельно.
Подключение веб-клиента. Почта не может так просто работать в браузере, для этого нужно настроить специальный веб-клиент.
Настройка RSS-ленты. Это лента новостей, которая приходит на почту. Немного устаревший формат, но для многих сервисов он важен, потому в почте его нужно настроить.
Синхронизация для смартфонов. Со смартфонов такая почта работать не будет, если не настроить специальный мобильный клиент.

Если вам нужна корпоративная почта, настройте ее по нашей инструкции «Как настроить корпоративную почту на своем домене». Если нужен именно почтовый сервер — ищите системного администратора в команду или аутсорсеров.

Почтовый сервер для массовых рассылок

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

Эти сервера отличаются следующим:

они сфокусированы на отправке писем, а не на получении;
они могут отправлять миллионы писем в минуту;
за их репутацией следят выделенные команды.

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

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

Если хотите детально разобраться — вот статья о настройке почтового сервера для рассылок.

Шаг 7 — Инициализация Maildir и тестирование клиента

Теперь мы можем протестировать клиент.

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

Для отправки письма добавьте строку в команду . Измените команду, чтобы сделать получателем вашего пользователя Linux:

Вы можете получить следующий ответ:

Это нормально, и такой ответ может появиться только при отправке первого сообщения. Мы можем еще раз проверить создание каталога, выполнив поиск нашего каталога :

Вы должны увидеть созданную структуру каталогов и новое сообщение в каталоге :

Похоже наше письмо доставлено.

Управление почтой с помощью клиента

Используйте клиент для проверки почты:

Вы должны увидеть новое сообщение:

Просто нажмите для вывода этого сообщения:

Вы можете веернуться к списку сообщений, введя и нажав :

Поскольку это сообщение не очень полезно, мы можем удалить его, введя и нажав :

Для выхода и возврата в терминал введите и нажмите :

Отправка писем с помощью клиента

Вы можете протестировать функцию отправки писем, набрав сообщение в текстовом редакторе:

Введите текст, которы вы хотите отправить по почте:

~/test_message

Мы можем использовать команду , чтобы направить сообщение в процесс . По умолчанию сообщение будет отправлено от имени вашего пользователя Linux. При желании вы можете изменить поле «From» с помощью атрибута :

Приведенные выше опции:

: строка темы письма
: изменение поля «From» письма. По умолчанию в этом поле указан текущий пользователь Linux. Опция позволяет задать другого отправителя.
: учетная запись получателя письма. Измените этот адрес на адрес учетной записи, к которому у вас есть доступ .

Вы можете просмотреть отправленные сообщения в клиенте . Запустите интерактивный клиент еще раз с помощью следующей команды:

После этого откройте список отправленных сообщений с помощью следующей команды:

Вы можете управлять отправленными письмами с помощью тех же команд, которые используются для входящих писем.

Конфигурация Postfix

Мы настроим Postfix для использования виртуальных почтовых ящиков и доменов.

Начните с создания файлов конфигурации которые будут указывать postfix, как получить доступ к базе данных MySQL , созданной в первой части этой серии .

Откройте текстовый редактор и создайте следующие файлы:

/etc/postfix/sql/mysql_virtual_domains_maps.cf

/etc/postfix/sql/mysql_virtual_alias_maps.cf

/etc/postfix/sql/mysql_virtual_alias_domain_maps.cf

/etc/postfix/sql/mysql_virtual_alias_domain_catchall_maps.cf

/etc/postfix/sql/mysql_virtual_mailbox_maps.cf

/etc/postfix/sql/mysql_virtual_alias_domain_mailbox_maps.cf

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

Команда postconf отображает фактические значения параметров конфигурации, изменяет значения параметров конфигурации или отображает другую информацию о конфигурации почтовой системы Postfix.

Агент локальной доставки доставит входящие электронные письма в почтовые ящики пользователей. Выполните следующую команду, чтобы установить службу Dovecot LMTP в качестве транспорта доставки почты по умолчанию:

Задайте параметры TL, используя ранее созданный SSL-сертификат Let’s encrypt:

Настройте параметры аутентифицированного SMTP и передайте аутентификацию Dovecot:

Нам также потребуется отредактировать главный файл конфигурации Postfix и включить порт отправки ( ) и порт smtps ( ).

Откройте файл в текстовом редакторе и раскомментируйте / отредактируйте следующие строки:

/etc/postfix/master.cf

Перезапустите службу постфикса, чтобы изменения вступили в силу.

На этом этапе вы успешно настроили службу Postfix.

Защищаем сообщения от попадания в СПАМ

Чтобы другие почтовые системы не принимали наши письма за СПАМ, выполняем следующие рекомендации:

А-запись в DNS

Для FQDN-имени почтового сервера должна быть создана А-запись в DNS. Пример записи:

mail.dmosk.ru A 90.156.242.197

Создаем PTR-запись для внешнего IP-адреса

Она должна вести на имя сервера (в данном примере, mail.dmosk.ru). Чтобы создать такую запись, нужно написать обращение Интернет-провайдеру или хостеру виртуальной машины. Пример записи:

171.23.222.83.in-addr.arpa name = mail.dmosk.ru

* данная запись соответствует IP-адресу 83.222.23.171.

Эта запись создается в DNS для домена, от которого идет отправка сообщений. Пример:

dmosk.ru text = «v=spf1 +mx -all»

Прописываем DKIM в DNS

Для начала, смотрим ключ, который был сформирован во время установки iRedMail:

amavisd-new showkeys

Пример ответа:

dkim._domainkey.dmosk.ru. 3600 TXT (
«v=DKIM1; p=»
«MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHNu0ZlYkq8pKsp131jnoZ+Ief»
«zcSP1WxGzGQXssg3yiRGBlqsRGBnnKgitrsPYTZbzqqL+/rW0ptGNhAqfTWHvMia»
«+f4RSMLJPMREFtakVEZvTIK5iZvxuCZpVhvM6ldadTLAxbcupX38yMfJV73EwCHK»
«d2mdqfW+emSW/paUwQIDAQAB»)

Копируем DKIM и создаем в DNS запись TXT. Пример:

dmosk.ru text = «v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHNu0ZlYkq8pKsp131jnoZ+IefzcSP1WxGzGQXssg3yiRGBlqsRGBnnKgitrsPYTZbzqqL+/rW0ptGNhAqfTWHvMia+f4RSMLJPMREFtakVEZvTIK5iZvxuCZpVhvM6ldadTLAxbcupX38yMfJV73EwCHKd2mdqfW+emSW/paUwQIDAQAB»

Создать другую подпись DKIM

Генерируем новый ключ:

amavisd-new genrsa /var/lib/dkim/dmosk2.ru.pem 1024

* где dmosk2.ru — новый домен, для которого мы сгенерируем подпись dkim.
* некоторые системы не работают с ключами более чем 1024 бит.

Задаем права на созданный файл:

chown amavis:amavis /var/lib/dkim/dmosk2.ru.pem

chmod 0400 /var/lib/dkim/dmosk2.ru.pem

Открываем конфигурационный файл amavisd

vi /etc/amavisd.conf

Находим строчку:

dkim_key(‘dmosk.ru’, «dkim», «/var/lib/dkim/dmosk.ru.pem»);

И добавляем радом с ней новую. Получится так:

dkim_key(‘dmosk.ru’, «dkim», «/var/lib/dkim/dmosk.ru.pem»);
dkim_key(‘dmosk2.ru’, «dkim», «/var/lib/dkim/dmosk2.ru.pem»);

Теперь находим строчку:

@dkim_signature_options_bysender_maps = ( {
…
«dmosk.ru» => { d => «dmosk.ru», a => ‘rsa-sha256’, ttl => 10*24*3600 },

И также после нее добавляем новую. Должно получиться:

@dkim_signature_options_bysender_maps = ( {
…
«dmosk.ru» => { d => «dmosk.ru», a => ‘rsa-sha256’, ttl => 10*24*3600 },
«dmosk2.ru» => { d => «dmosk2.ru», a => ‘rsa-sha256’, ttl => 10*24*3600 },

Перезапускаем amavisd:

amavisd-new restart

Политика DMARC

Данная политика определяет, что делать с письмом, которое не проходит проверку. Подробнее о DMARC.

Для создания данной политики необходимо в DNS добавить TXT запись, примерно, такого содержания:

_dmarc.dmosk.ru. 3600 IN TXT «v=DMARC1; p=quarantine; sp=none; pct=100; fo=0; rua=mailto:postmaster@dmosk.ru»

* данная запись означает, что все письма, которые не прошли проверку, необходимо отправить в карантин, а отчет написать на ящик postmaster@dmosk.ru.

Ящик abuse

По аналогии с тем, как мы создавали тестовую учетную запись, необходимо создать ящик abuse@… На данный ящик могут приходить жалобы на СПАМ. Стоит время от времени просматривать его (или настроить переадресацию), и реагировать на жалобы.

Простое удаление старых писем из ящика

Начнем с самого простого примера. Допустим, у вас есть какой-то ящик, хранить письма в котором старше определенного срока не имеет смысла. К примеру, это может быть ящик для оповещений системы мониторинга. После того, как оповещение было прочитано, оно теряет актуальность. Все события и так фиксируются и хранятся на самом сервере, поэтому хранить долго письма нет никакого смысла. Очистим этот ящик, удалив из него все письма, старше 30 дней.

/usr/bin/find /data/mail/virtual/zabbix@mailsrv.ru/Maildir/*/ -type f -mtime +30 -exec rm {} \;

/usr/bin/find	Путь до утилиты find. Проверьте его актуальность в своем дистрибутиве.
/data/mail/virtual/reports@eme.ru/Maildir/*/	Путь до конкретного ящика. Конструкция /*/ позволяет сразу проверить обе папки new и cur.
-type f	Говорим find, что ищем только файлы.
-mtime +30	Указываем срок более 30 дней с последнего изменения файла. То есть все файлы старше 30-ти дней.
-exec rm {} \;	Выполняем удаление.

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

/usr/bin/find /data/mail/virtual/zabbix@mailsrv.ru/Maildir/*/ -type f -mtime +30 >> /root/dellist.txt

После этого смотрите файл /root/dellist.txt и проверяйте, что собираетесь удалить. После того, как проверили, не обязательно заново выполнять поиск по базе и лишний раз нагружать диски. Можно удалить все указанные в dellist.txt письма следующим скриптом.

#!/bin/bash

cat /root/dellist.txt | while read i ; do 
rm -f "$i" 
done

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