Как настроить postfix, dovecot на CentOS 8 с настройкой веб-сервера NGINX + PHP + MariaDB та защита от вирусов и спама Clamav + Amavisd

 

В данной инструкции выполнена настройка полноценного почтового сервера. Список всех особенностей и возможностей:

• Почтовая система на базе Postfix;
• Поддержка виртуальных доменов;
• Хранение почты на сервере;
• Подключение к почтовым ящикам по POP3 и IMAP (Dovecot);
• Поддержка шифрования;
• Хранение части настроек в MariaDB;
• Защита от СПАМа и вирусов;
• Доступ к почте с помощью веб-интерфейса (Roundcube);
• Возможность управления почтовыми ящиками с помощью PostfixAdmin.

Данная инструкция является обновлением для статьи

Шаг 1. Подготовка системы

Напоминаю, данная инструкция написана под систему Linux CentOS версии 8. Предварительно, выполним следующие действия.

Общие настройки

Задаем правильное имя серверу — это важный шаг, так как большинство антиспам систем выполняют проверки, обращаясь к серверу по имени в ожидании ответа.

* необходимо указать FQDN-имя, которое будет доступно из глобальной сети. В данном примере указано relay.infoit.com.ua.

Устанавливаем служебные пакеты (они понадобятся в процессе настройки сервера):

* chrony для возможности синхронизировать время на сервере; wget — клиент для загрузки файлов.

Задаем временную зону (в данном примере московское время):

* в данном примере мы установим московское время. Чтобы получить список всех возможных зон, вводим timedatectl list-timezones.

Запускаем сервис для обновления времени:

Обновляем систему:

Настройка безопасности

Заранее открываем порты на брандмауэре с помощью firewalld:

* где мы откроем следующие порты:

• 25 — стандартный SMTP через STARTTLS;
• 80 — HTTP для порталов Postfixadmin и Roundcube;
• 110 — стандартный POP3 через STARTTLS;
• 143 — стандартный IMAP через STARTTLS;
• 443 — защищенный HTTPS для порталов Postfixadmin и Roundcube;
• 465 — защищенный SMTP через SSL/TLS;
• 587 — защищенный SMTP через STARTTLS;
• 993 — защищенный IMAP через SSL/TLS;
• 995 — защищенный POP3 через SSL/TLS.

Отключение SELinux

Для отключения дополнительного компонента безопасности вводим 2 команды:

* первая команда отключит SELinux для текущей загрузки. Вторая оставит его отключенным на постоянной основе.

Шаг 2. Настройка веб-сервера: NGINX + PHP + MariaDB

Система управления PostfixAdmin работает как веб-приложение, разработанное на PHP, а информацию хранит в базе данных. В нашем примере будет использоваться веб-сервер на NGINX, а база данных — MariaDB.

Установка NGINX

Устанавливаем nginx командой:

Разрешаем автозапуск сервиса и запускаем его:

Проверяем работоспособность веб-сервера, обратившись к нему в браузере по IP-адресу. Если видим заголовок «Welcome to nginx!», NGINX настроен верно.

PHP + PHP-FPM + NGINX

Устанавливаем php и php-fpm. Мы будем использовать репозиторий remi, так как в репозитории CentOS отсутствует нужный нам php-imap.

И так, устанавливаем EPEL и REMI:

Теперь устанавливаем PHP из репозитория REMI:

После ставим php-fpm:

Настраиваем NGINX:

В разделах http — server добавляем настройку для обработки запросов php:

* где /usr/share/nginx/html — каталог для размещения данных nginx по умолчанию.

Запускаем сервисы:

Для проверки, создаем индексный файл в директории сайта со следующим содержимым:

Открываем сайт в браузере по его IP-адресу. На открывшейся странице мы должны увидеть подробную информацию по php:

MariaDB

Устанавливаем сервер баз данных следующей командой:

Включаем автозапуск сервиса и запускаем его:

Задаем пароль для пользователя sql root:

Шаг 3. Установка и настройка PostfixAdmin

Устанавливаем дополнительные компоненты для PHP:

Для применения установленных пакетов, перезапускаем обработчик скриптов:

Скачиваем PostfixAdmin:

В директории сайтов nginx создаем каталог для postfixadmin и распаковываем в него архив:

Создаем каталог templates_c внутри папки портала (без него не запустится установка):

Задаем права на каталог:

* несмотря на то, что мы используем веб-сервер nginx, php-fpm по умолчанию, запускается от пользователя apache.

Создаем базу данных postfix и учетную запись в mariadb:

* где postfix — имя базы.

* где postfix — имя учетной записи; postfix123 — пароль; localhost разрешает подключение только с локального сервера.

Выходим из командной оболочки MariaDB:

Создаем конфигурационный файл postfixadmin:

* в предыдущих версиях использовался файл config.inc.php. В новых версиях его не рекомендуется править, а использовать config.local.php, который переопределяет настройки.

И добавляем следующее:

* где configured говорит приложению, что администратор закончил его конфигурирование; default_language — используемый язык по умолчанию; database_password — пароль для базы данных, который мы задали на предыдущем шаге; emailcheck_resolve_domain — задает необходимость проверки домена при создании ящиков и псевдонимов.

Запускаем браузер и вводим адрес http://<IP-адрес сервера>/postfixadmin/public/setup.php

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

… после чего, вводим дважды пароль и генерируем хэш, кликнув по Generate password hash:

После перезагрузки страницы копируем хэш:

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

И добавляем строчку:

* где ‘7a8e14…c26’ — скопированный хэш.

После, на той же странице, где показан хэш, добавляем суперпользователя PostfixAdmin:

* где Setup password — пароль, который мы ввели на предыдущей странице; Пароль — новый пароль для создаваемой учетной записи.

В итоге мы увидим следующее:

И переходим в браузере на страницу http://<IP-адрес сервера>/postfixadmin/public/

Вводим логин и пароль для созданного пользователя. Мы должны войти в postfix.admin:

Готово.

Шаг 4. Установка и настройка Postfix

Установка Postfix в CentOS 8 выполняется командой:

* помимо самого postfix, мы также установили postfix-mysql для возможности работы с СУБД.

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

* сначала мы создаем группу vmail и guid 1024, после — пользователя vmail с uid 1024 и домашней директорией /home/mail — в ней у нас будет храниться почта. Обратите внимание, что в некоторых системах идентификатор группы и пользователя 1024 может быть занят. В таком случае необходимо создать другой, а в данной инструкции ниже заменить все 1024 на альтернативный.

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

Теперь открываем на редактирование конфигурационный файл почтового сервера:

И редактируем следующие строки:

* где:

• myorigin — указывает, какой домен подставлять отправителю, если он не указан в заголовке FROM.
• mydestination — указываем, для каких доменов принимаем входящую почту.
• local_recipient_maps — указываем, откуда брать список локальных пользователей.
• mynetworks — разрешаем отправлять сообщения локальному серверу.
• inet_interfaces — необходимо убедиться, что postfix будет слушать на всех необходимых интерфейсах, в данном случае, на всех (all). Также можно задать варианты loopback-only (127.0.0.1) или конкретный IP-адрес интерфейса.
• inet_protocols — данный параметр задаст протокол для работы postfix. В данном примере на всех (all). Также можно задать значения ipv4 или ipv6.
• smtpd_tls_cert_file — полный путь до публичного сертификата.
• smtpd_tls_key_file — полный путь до приватного сертификата.

Если имя сервера отличается от имени, по которому сервер будет зарегистрирован в DNS, задаем опцию:

Теперь в конец конфигурационного файла допишем следующее:

* где:

• virtual_mailbox_base — базовый путь хранения почтовых ящиков в системе UNIX.
• virtual_alias_maps — формат и путь хранения алиасов для виртуальных пользователей.
• virtual_mailbox_domains — формат и путь хранения доменов виртуальных пользователей.
• virtual_mailbox_maps — формат и путь хранения почтовых ящиков для виртуальных пользователей.
• virtual_minimum_uid — с какого номера присваивать идентификаторы пользователям.
• virtual_uid_maps — идентификатор пользователя, от которого записываются сообщения.
• virtual_gid_maps — идентификатор группы, от которой записываются сообщения.
• virtual_transport — задает доставщика сообщений.
• dovecot_destination_recipient_limit — передача сообщений от Postfix в Dovecot выполняется по заданному количеству (в нашем примере, по 1 шт.).
• smtpd_sasl_auth_enable — разрешает sasl аутентификацию.
• smtpd_sasl_exceptions_networks — исключение сетей от использования шифрования.
• smtpd_sasl_security_options — дополнительные опции настройки sasl.
• broken_sasl_auth_clients — эту опцию прописываем для клиентов MS Outlook.
• smtpd_sasl_type — указывает тип аутентификации.
• smtpd_sasl_path — путь до временных файлов обмена информацией с Dovecot. Указывается либо абсолютный путь, либо относительный queue_directory (по умолчанию /var/spool/postfix). Итого, полный путь — /var/spool/postfix/private/auth.
• smtpd_use_tls — указывает клиентам на наличие поддержки TLS.
• smtpd_tls_auth_only — использовать только TLS.
• smtpd_helo_required — требовать начинать сессию с приветствия.

Создаем файл с настройками обращения к базе с алиасами:

* где user и password — логин и пароль для подключения к MySQL; hosts — имя сервера баз данных (в нашем случае, локальный сервер); dbname — имя базы данных; query — шаблон запроса к данным.

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

И файл с почтовыми ящиками:

Открываем файл master.cf и дописываем в самый конец:

* необходимо убедиться, что в содержимом файла нет других раскомментированных опций для submission, smtps и dovecot (по умолчанию, их нет). В данном случае, мы настроили работу postfix на портах 25, 465 и 587. В файле master.cf мы настраиваем работу вспомогательных сервисов для Postfix. Описание каждого сервиса начинается с новой строки без отступа. Затем идут настройки для сервиса и параметры запуска. Для примера, рассмотрим первую добавленную строку —
submission   inet  n  —  n  —  —  smtpd:

• submission — имя сервиса. Возможно использование заранее определенных в postfix служб или создание своих. В данном примере submission для подключения MUA по порту 587 при отправке почты.
• inet — тип обслуживания. Возможны варианты inet (сокет TCP/IP), unix (потоковый сокет), unix-dgram (сокет дейтаграммы), fifo (именованный канал очереди), pass (потоковый сокет UNIX-домена).
• первый «n» — является ли сервис частным и должен быть ограниченным. Возможны варианты y или n. Для типа обслуживания inet может быть только n.
• первый «-« — работает ли служба с правами root. Возможны варианты y, n и —. Прочерк означает неприменимость данного параметра к конкретному сервису.
• второй «n» — должна ли служба работать в окружении chroot. Возможны варианты y или n.
• второй «-« — через какое время в секундах пробудить службу, если она неактивна.
• третий «-» — максимальное количество одновременно выполняемых процессов, которые может запустить данный сервис.
• smtpd — выполняемая команда.

* после команды идут аргументы ее запуска. Они могут переопределять параметры, заданные в main.cf. Каждый аргумент записывается с новой строки и начинается с двух пробелов. В данном примере мы используем следующие аргументы:

• smtpd_tls_security_level — задает уровень безопасности с применением TLS. В данном примере may говорит о возможности его использования.
• smtpd_sasl_auth_enable — разрешает sasl аутентификацию.
• smtpd_sasl_type — указывает тип аутентификации.
• smtpd_sasl_path — путь до временных файлов обмена информацией с сервером хранения почты (в нашем случае Dovecot). Указывается либо абсолютный путь, либо относительный queue_directory.
• smtpd_sasl_security_options — дополнительные опции настройки sasl.
• smtpd_sasl_local_domain — добавить домен для пользователей, которые проходят smtp-аутентификацию.
• syslog_name — префикс названия службы при занесении ее в системный журнал.
• smtpd_tls_wrappermode — запускать ли службу в нестандартном режиме (для поддержки TLS).
• smtpd_client_restrictions — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

Генерируем сертификаты безопасности. Для этого создаем каталог, в котором их разместим:

И сгенерируем их следующей командой:

* сертификат сгенерирован на 1461 день, ключи subj могут быть произвольными, CN необходимо указать в соответствии с именем сервера, по которому мы будем подключаться к почте.
* если мы хотим использовать сертификат, который будет проходить все проверки безопасности, его нужно купить или запросить у Let’s Encrypt.

Разрешаем запуск postfix:

Шаг 5. Настройка Dovecot

Устанавливаем Dovecot с компонентом для работы с СУБД:

Настраиваем способ хранения сообщений:

* в данном примере сообщения будут храниться в продвинутом формате maildir в каталоге /home/mail/<почтовый домен>/<логин пользователя>.

Настраиваем слушателя для аутентификации:

* в данном примере мы настраиваем сервис для аутентификации и создаем два прослушивателя: /var/spool/postfix/private/auth — для возможности постфиксом использовать авторизацию через Dovecot (обращаем внимание, что /var/spool/postfix/private/auth — это тот же private/auth, который был прописан нами в postfix); auth-userdb — сокет для авторизации через dovecot-lda. Опция mode задает права на сокет, например, 666 позволит любому пользователю к нему подключиться; user и group задает пользователя и группу владельцев на сокет.

А также в этом файле добавим строки:

* в противном случае, мы увидим в логе ошибку error net_connect_unix(/var/run/dovecot/stats-writer) failed permission denied, так как у пользователя vmail не будет прав.

Настраиваем аутентификацию в Dovecot:

* в данном случае мы просто комментируем обычную аутентификацию и снимаем комментарий для использования sql-аутентификации.

Настраиваем использование шифрования:

* ssl = required укажет dovecot требовать от клиентов использования шифрования; ssl_cert — путь до открытого сертификата (также нами указывался в postfix); ssl_key — путь к закрытому ключу.

Настроим автоматическое создание каталогов при первом подключении пользователя к ящику:

Настраиваем подключение к нашей базе данных:

* в данном примере мы указали на файл, в котором будут находиться настройки для получения пользователей и паролей из базы данных. Данная настройка является настройкой по умолчанию и, в большинстве случаев, ее не нужно менять без необходимости указать свой путь.

Создаем файл с настройками работы с mysql:

* в данном примере мы настроили запрос на получение данных из базы mysql (mariadb). password_query — запрос на получение пароля из таблицы mailbox; user_query — запрос на получение данных пользователя (домашняя почтовая директория, идентификатор 1024 (идентификатор созданного нами ранее пользователя vmail).

И, напоследок, настраиваем интерфейс, на котором будет слушать dovecot:

* по умолчанию, dovecot слушает также на ipv6 (listen = *, ::). Если на сервере не используется 6-я версия протокола TCP/IP, в логах dovecot появятся ошибки:
master: Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
master: Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol

Запускаем dovecot:

Шаг 6. Создаем первый почтовый ящик и проверяем работу сервера

В браузере вводим в адресной строке путь до Postfixadmin — http://<IP-адрес сервера>/postfixadmin/public/.

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

Переходим в Список доменов — Новый домен:

Заполняем формы и нажимаем по Добавить домен:

Теперь переходим в Обзор — Создать ящик:

Вводим данные нового пользователя и нажимаем по Создать ящик:

Теперь можно подключиться к серверу с помощью любой почтовой программы, например, Mozilla Thunderbird.

Параметры для подключения:

• Сервер: имя сервера или его IP-адрес (не желательно, так как сертификат выдается по доменному имени).
• IMAP: 143 STARTTLS или 993 SSL/TLS
• POP3: 110 STARTTLS или 995 SSL/TLS
• SMTP: 25 STARTTLS или 465 SSL/TLS или 587 STARTTLS

* для корректной работы сервера на портах 993, 995, 465 (SSL/TLS) необходим правильный сертификат (для нашего домена и выпущенный доверенным центром сертификации).

Шаг 7. Устанавливаем и настраиваем Roundcube Webmail

В данной инструкции мы разберем использование веб-клиента Roundcube. При необходимости, можно установить другой, например, WebMail Lite или несколько одновременно.

На официальном сайте заходим на страницу загрузки Roundcube. Смотрим ссылку на версию продукта с длительной поддержкой (LTS):

Используем ссылку, чтобы загрузить архив программы:

Создаем каталог, где будут размещаться файлы портала:

И распаковываем скачанный архив:

Копируем шаблон конфига:

И открываем его на редактирование:

* первую строку мы редактируем, а вторую добавляем. В первой строке roundcube:roundcube123 — логин и пароль для доступа к базе данных; localhost — сервер базы данных; roundcubemail — имя базы данных. Вторая строка разрешает установку портала.

Также дописываем в конфигурационный файл следующее:

* настройка $config[‘create_default_folders’] = true создает папки по умолчанию, если их нет:

• Drafts — Черновики.
• Junk — СПАМ.
• Sent — Отправленные.
• Trash — Корзина.

* Без данной настройки, если не создавались папки другим клиентом, веб-клиент будет выдавать ошибки при перемещении писем, например, при их удалении.

Задаем владельца apache на папку портала:

Создаем в MariaDB базу для roundcubemail:

И загружаем в созданную базу данные:

Устанавливаем компоненты, необходимые для работы Roundcube:

Настроим php:

* в данном примере мы задаем московское время и возможность загружать файл размером в 30 Мб (это будет максимальным объемом вложений, которые можно отправлять через веб-интерфейс).

Перезагружаем php-fpm:

Настроим nginx:

Добавим строку в раздел http:

* данной настройкой мы также разрешим загрузку файлов размером 30 Мб.

Перезапустим nginx для применения настройки:

Теперь открываем браузер и переходим по адресу http://<IP-адрес сервера>/webmail/installer/. В самом низу нажимаем по кнопке Next. Если кнопка будет неактивна, проверяем, что нет ошибок (NOT OK).

На следующей странице проверяем, что все пункты находятся в состоянии OK. Установка выполнена.

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

Запрещаем установку портала:

После удаляем папку с установочными скриптами:

И заходим в браузере по адресу http://<IP-адрес сервера>/webmail/. Вводим в качестве логина адрес почты созданного пользователя и его пароль.

Шаг 8. Защищаемся от вирусов и СПАМа

Установка и настройка Clamav + Amavisd

Устанавливаем необходимые для работы антивируса и антиспама компоненты:

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

Редактируем следующие параметры:

* данные опции не обязательны, но они определяют сообщения в заголовках. $mydomain — домен, в котором находится сервер; $myhostname — имя сервера.

… а также добавим:

* данные опции позволят программе Outlook без ошибок отправлять тестовое сообщение.

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

Снимаем комментарий для опции TCPSocket:

Теперь разрешаем запуск антивируса и amavis:

Настройка Postfix

Добавляем в postfix:

* где content_filter указывает на приложение, которое будет сканировать сообщения; receive_override_options позволяет увидеть оригинальные email адреса писем с вирусами.

Теперь редактируем master.cf:

Дописываем следующее:

* итак, данной настройкой мы создадим два вспомогательных сервиса scan и 127.0.0.1:10025 (сервис без имени, он просто будет слушать на порту 10025 — это порт по умолчанию, на который отправляет сообщение amavis после выполнения проверки). Также, мы используем следующие опции:

• smtp_send_xforward_command — передавать ли в сканирование сообщение с исходными именем клиента и IP-адресом. В данном примере, да.
• smtp_enforce_tls — требовать ли TLS.
• content_filter — приложение для сканирования. В данном примере сканирование отключено.
• receive_override_options переопределяет опции в main.cf. В нашем случае, no_unknown_recipient_checks отключает попытки выяснить, является ли получатель неизвестным; no_header_body_checks отключает проверки заголовков и тала писем.
• пустые значения для smtpd_helo_restrictions, smtpd_client_restrictions, smtpd_sender_restrictions отключают ограничения для данных опций.
• smtpd_recipient_restrictions — контролирует ответ Postfix на SMTP-команду RCPT TO. Здесь мы разрешаем только соединения от узлов, перечисленных в mynetworks.
• mynetworks_style=host указывает postfix, что он должен пересылать почту только с локального компьютера.
• smtpd_authorized_xforward_hosts укажет, какие удаленные клиенты могут использовать XFORWARD. В данном случае локальный компьютер.

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

Настройка обновлений антивируса и amavis

Устанавливаем clamav-update:

Обновляем антивирусную базу командой:

Для обновления базы антиспама:

Для настройки автоматического обновления, редактируем cron:

* в данном примере, каждый день в 03:15 будет запускаться процесс обновления clamav, а в 03:30 — антиспама.

Проверка

Для проверки антивируса отправляем сообщение со следующим содержимым:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Письмо не должно дойти, а в логе (/var/log/maillog) мы увидим строку:

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

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

В итоге, письмо не должно прийти, а в логах мы увидим:

Пересылка СПАМа и вирусов на другой ящик

Все письма со спамом и вирусами будут перемещаться в карантин. Если мы хотим перенаправлять все подобные сообщения на специальный ящик, то необходимо настроить amavis.

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

Добавляем такие опции:

* где $spam_quarantine_to указываем на адрес для перенаправления СПАМ-писем; $virus_quarantine_to — почта для писем с обнаруженными вирусами.

После перезагрузим amavisd:

Пробуем отправить сообщения с тестовыми сигнатурами на СПАМ и вирус — письма должны быть перенаправлены на указанные адреса.

Сохранения СПАМа в папку SPAM пользователя

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

Устанавливаем пакет dovecot-pigeonhole:

Открываем на редактирование файл:

Комментируем и добавляем строки:

* закомментированная строка указывала, что файл с настройками находится в домашней директории каждого пользователя. Мы же будем делать централизованный конфиг в файле /etc/dovecot/sieve/default.sieve.

Открываем файл /etc/dovecot/conf.d/15-lda.conf и редактируем:

* в данном примере мы добавили плагин sieve. Также необходимо со строки снять комментарий, если он был.

Открываем файл /etc/dovecot/conf.d/15-lda.conf и редактируем:

* также мы добавили плагин sieve + необходимо со строки снять комментарий, если он есть.

Создаем каталог и файл с настройками sieve:

* в данном примере мы ищем в заголовках X-Spam-Flag и отправляем такие письма в папку Junk.

Задаем владельца для созданных каталога и файла:

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

Открываем конфиг amavis:

Редактируем строку:

* по умолчанию стоит значение D_DISCARD, что означает, что сообщения будут отклонятся. Нам же нужно D_PASS — пропускать.

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

Антиспам средствами Postfix

В MTA Postfix встроен свой механизм проверки заголовков входящих сообщений. Правила размещаются в 7 секций, обработка которых выполняется в следующем порядке:

client -> helo -> sender -> relay -> recipient -> data -> end_of_data

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

1. Соединение с сервером.
2. Команда HELO. Приветствие, в котором отправитель называет свое имя, по которому можно проверить, соответствует ли оно правилам именования и своему IP-адресу.
3. MAIL FROM — указывает адрес отправителя. Выполняется для sender и relay.
4. RCPT TO — кому отправляем письмо.
5. DATA — команда сообщает о готовности отправить письмо с заголовками и текстом.
6. END-OF-DATA — отправка письма.

И так, для настройки антиспама в конфигурационный файл main.cf добавляем:

* где параметры:

1. smtpd_client_restrictions — настройки ограничений при осуществлении клиентских соединений с почтовым сервером.
2. smtpd_helo_restrictions — ограничения в контексте клиентской команды HELO.
3. smtpd_sender_restrictions — ограничения будут применяться во время выполнения клиентской команды MAIL FROM.
4. smtpd_relay_restrictions — ограничения пересылки почты в контексте клиентской команды RCPT TO.
5. smtpd_recipient_restrictions — ограничения в контексте клиентской команды RCPT TO после пересылки (smtpd_relay_restrictions).
6. smtpd_data_restrictions — ограничения будут применяться во время выполнения команды DATA.
7. smtpd_end_of_data_restrictions — ограничения во вреся выполнения команды END-OF-DATA.

… и значения для них:

• permit_mynetworks — разрешает все адреса, перечисленные в настройке mynetworks.
• permit_sasl_authenticated — разрешает запросы всех успешно авторизованных клиентов.
• reject_unauth_pipelining — запрещает отправку писем, которые отправляются заранее (пропуская правильную цепочку сессии SMTP).
• reject_non_fqdn_sender — отклонить соединение, если адрес отправителя указан неправильно (согласно RFC).
• reject_unknown_sender_domain — запрещает запрос, если Postfix не является конечным пунктом назначения для адреса отправителя, а домен MAIL FROM не имеет 1) DNS-записи MX и DNS-записи A или 2) искаженной MX-записи, такой как запись с MX-именем хоста нулевой длины.
• reject_non_fqdn_recipient — запретить соединение, если адрес получателя указан неправильно (согласно RFC).
• reject_unauth_destination — отклонить соединение, если письмо не пересылается согласно правилу relay_domains или сервер не является адресом назначения. Другими словами, запрещает использование нашего сервера в качестве open relay.
• reject_unknown_recipient_domain — отклонить запрос, если Postfix не является конечным пунктом назначения для домена получателя, а домен RCPT TO не имеет 1) DNS-записи MX и DNS-записи A или 2) неверно сформированной MX-записи, такой как запись с именем хоста MX нулевой длины.
• reject_unverified_recipient — отклонить запрос, если известно, что почта на адрес RCPT TO отклоняется или когда адрес получателя не доступен. 
• permit — разрешает соединение. Ставим в конец каждого блока ограничений (если ограничения не сработали, то разрешаем).

* это более или менее мягкие правила. Их можно использовать первое время, пока тестируем сервер.

Для усиления защиты добавляем:

* где:

• reject_unknown_client_hostname — проверяет наличие PRT-записи отправителя и наличие рабочей А-записи в соответствие PTR.
• reject_invalid_helo_hostname — проверяет синтаксис HELO-приветствия.
• reject_non_fqdn_helo_hostname — требует правильного FQDN-имени во время HELO-приветствия.
• reject_unknown_helo_hostname — запрещает представляться именами, для которых нет А-записи или MX.
• reject_rbl_client — проверяет наличие отправителя в черных списках.

* более подробное описание опций для защиты можно найти на странице postfix.org/postconf.5.html.

После внесения всех правок, необходима перезагрузка Postfix:

Обучение антиспама

Мы установили amavis, который проверяет почту на СПАМ средствами spamassassin. Последний без обучения, практически, бесполезен. Синтаксис команды для обучения следующий:

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

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

* в данном примере мы сказали spamassassin найти в каталогах пользователей папки Спам, Spam, Junk, Junk E-mail (данные каталоги являются типичными для помещения СПАМа) и провести обучение.

Чтобы минимизировать количество ложных срабатываний, необходимо проводить обучение с ключом —ham. В нашем примере мы отправляем все нежелательные письма на ящик spam. В таком случае, необходимо вручную находить ложные срабатывания и переносить их в специальную папку, например Ham. Тогда команда для обучения будет такой:

Статистику обучения можно посмотреть командой:

Черные и белые списки

В настройках amavis мы можем переопределять СПАМ-бал для конкретного отправителя или всего домена. Для этого открываем файл:

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

Внутри фигурных скобок можно создавать новые строки с описанием поведения антиспама.

а) для добавления в белый список.

Присваиваем минусовое значение для бала, например:

* в данном примере все письма от домена infoit.com.ua будут получать минус 5 баллов. Таким образом, шансов попасть в СПАМ будет меньше. У всех писем от email example@mail.ru будет отниматься 10 баллов.

б) для добавления в черный список.

В данном случае, мы задаем положительное значение для балла:

После того, как мы внесли правки в наш файл, перезапускаем amavis:

Шаг 9. Отправка почты наружу

Для отправки почты на другие почтовые серверы необходимо правильно сконфигурировать сервер, чтобы письма не попадали в СПАМ. Чтобы это сделать, выполняем инструкции ниже.

Настройки DNS для сервера

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

1. rDNS. Обратная зона используется для проверки соответствия имени сервера в приветствии с именем, которое возвращает NS сервер при запросе по PTR-записи.

И так, для создания записи в обратной зоне, необходимо написать письмо Интернет провайдеру, к сети которого подключен сервер или хостеру, если почтовый сервер настроен на VPS. IP-адрес нашего сервера должен вести на имя, которым приветствуется наш postfix — можно посмотреть командой:

Если мы получим пустой ответ, то вводим:

Если и в этот вариант не вернет ответ, вводим:

2. А-запись. Также необходимо, чтобы имя сервера, которым представляется почтовый сервер разрешалось в IP-адрес.

Для этого заходим в консоль управления зоной нашего домена и создаем запись типа А для сопоставления имени сервера с IP-адресом, на котором слушает запросы данный сервер.

Настройки DNS для домена

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

1. SPF.
2. DMARC.
3. DKIM

Для проверки корректности настройки сервера, воспользуемся ресурсами:

• https://www.mail-tester.com
• https://spamtest.smtp.bz

Шаг 10. Настройка DKIM

Подпись писем не является обязательной, но помогает не попадать в СПАМ. DKIM настраивается для каждого домена, а также должна создаваться специальная запись в DNS. Рассмотрим создание и настройку DKIM в amavisd.

Создаем каталог для хранения ключей:

Генерируем последовательность для нашего домена:

* где infoit.com.ua — домен, для которого мы сгенерируем подпись dkim.

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

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

Редактируем запись:

* в данном примере мы закомментировали первую строку и раскомментировали вторую. Это укажет amavis, что он должен запускаться и работать на двух портах.

Добавляем записи:

* гдеinfoit.com.ua — домен, для которого мы настраиваем dkim; /var/lib/dkim/infoit.com.ua.pem — путь до сгенерированного файла с последовательностью.

Проверяем, чтобы значение данных переменных было 1:

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

Посмотреть DKIM последовательность для нового домена можно командой:

Мы должны увидеть что-то на подобие:

Теперь нам нужно на основе данного вывода создать в DNS запись TXT. В данном примере, нужно создать запись c именем dkim._domainkey в зоне infoit.com.ua и значением «v=DKIM1; p=MIGfMA0SD…wIDAQAB».

Проверить корректность настройки DKIM можно командой:

Переходим к настройке Postfix. Мы должны добавить отправку всех исходящих писем на проверку в amavis на порт 10026 и принимать обратно письма на порт 10027.

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

Отредактируем submission и smtps, добавив content_filter:

И добавим:

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

Настраиваем Roundcube:

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

… и меняем ее на:

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

Пробуем отправить письмо — в заголовках мы должны увидеть:

Шаг 11. Настройка квот

В PostfixAdmin у нас есть возможность задать квоты на почтовые ящики, но они работать не будут, так как о них ничего не знает Dovecot.

Процесс настройки не сложен и описан отдельно в статье Настройка квот в Dovecot + PostfixAdmin.

После применения квот мы сможем наблюдать в почтовом клиенте Roundcube информацию об оставшемся дисковом пространстве:

… или в Webmail Lite:

Шаг 12. Автоматическая настройка почтовых клиентов

Для автоматического конфигурирования почтовых клиентов необходимо настроить сервис autodiscover. Для этого настраиваем веб-сервер, который будет возвращать почтовые настройки для домена.

Подробнее процесс настройки описан в статье Настройка Autodiscover для своего почтового сервера.

Шаг 13. Папки на русском в Outlook

По умолчанию, все почтовые клиенты, кроме Outlook распознают служебные папки IMAP:

• Drafts — черновики.
• Junk — СПАМ.
• Sent — отправленные.
• Trash — удаленные.

Данные каталоги переводятся на русский язык и корректно отображаются в клиенте. В Outlook эти папки отображаются как есть — на английском языке.

Для решения проблемы мы должны открыть файл:

Найти блок настроек namespace inbox. Для каждого из служебного каталога настроить следующее:

* и так, мы задали несколько вариантов служебных каталогов:

• Черновики — на сервере могут быть папки Черновики и Drafts. По умолчанию отображается и создается Черновики.
• Спам — на сервере Спам, Junk, Spam, Junk E-mail.
• Удаленные — на сервере Удаленные, Trash, Deleted Messages.
• Отправленные — на сервере Отправленные, Sent, Sent Messages, Sent Items.

Для применения настроек перезапускаем dovecot:

Шаг 14. Разное

Рассмотрим дополнительные настройки для нашего сервера.

Настройка ограничений

Также важно настроить некоторые ограничения, например:

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

Подробнее, информацию можно найти в статье Лимиты в Postfix.

Смена email адреса

Предположим, мы сделали ошибку в написании адреса электронной почты, но не хотим удалять учетную запись и создавать ее по новой. Рассмотрим смену email-адреса на примере sekretar@infoit.com.ua -> secretar@infoit.com.ua.

Нам нужно внести изменения в базу данных — для этого заходим в оболочку sql:

Вводим пароль, который создавали после установки СУБД.

Используем базу postfix:

Редактируем алиасы командой:

Редактируем почтовый ящик:

И квоту:

С базой данных закончили — выходим из sql:

Переходим в каталог с почтовыми ящиками пользователей для нашего домена:

Перемещаем папку с почтой старого ящика в новый:

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

Информация взята из сайта!