Термины по теме: Postfix , POP3 , SMTP , IMAP , MariaDB , CentOS , PostfixAdmin , Dovecot , Roundcube

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

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

Содержание

1. Преднастройка системы

Напоминаю, данная инструкция написана под систему Linux CentOS версии 7.

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

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

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

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

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

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

Разрешаем сервис для синхронизации времени и запускаем его:

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

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

Заранее открываем порты на брандмауэре с помощью 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.

В CentOS также может использоваться утилита iptables — в таком случае команды будут следующие:

После сохраняем правила любым из описанных способов .

Отключение SELinux

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

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

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

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

Установка NGINX

Устанавливаем репозиторий EPEL:

Устанавливаем nginx:

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

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

PHP + PHP-FPM + NGINX

Устанавливаем php и php-fpm :

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

* где /usr/share/nginx/html — каталог для размещения портала управления Postfix; /var/run/php-fpm/php5-fpm.sock — путь до сокетного файла для взаимодействия с php-fpm (будет настроено ниже).

Если мы хотим, чтобы postfixadmin был на отдельном виртуальном домене, создаем файл:

vi /etc/nginx/conf.d/postfixasdmin.conf

server {
listen 80;
server_name postfixasdmin.remontka.com;
set $root_path /usr/share/nginx/html;

location / {
root $root_path;
index index.php;
}

location ~ .php$ {
fastcgi_pass unix:/var/run/php-fpm/php5-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
}

* postfixasdmin.remontka.com — доменное имя узла, к которому мы будем подключаться для работы с Postfixasdmin.

Настраиваем PHP-FPM:

* здесь мы поменяли строку 127.0.0.1:9000 .

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

* если в процессе перезапуска nginx выскочит ошибка nginx: [emerg] a duplicate default server , необходимо найти настройку виртуального домена, в которой также указана опция default_server — опцию нужно убрать. Или можно самостоятельно настроить другой виртуальный домен.

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

Открываем сайт в браузере по его 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

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

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

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

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

* где ‘$2y$10…BMK’ — скопированный хэш.

Загружаем по новой страницу http://<IP-адрес сервера>/postfixadmin/public/setup.php — теперь у нас появится форма для ввода нашего пароля, созданного на предыдущем этапе. Вводим его и кликаем по Login with setup_password :

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

Будет выполнена установка PostfixAdmin.

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

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

Вводим логин и пароль для созданного пользователя.

Готово.

Однако, конкретно, в моем случае, пользователь не создавался при установке системы и необходимо было создать администратора вручную. Если это потребуется, в консоли сервера подключаемся к СУБД:

Переходим к использованию базы postfix:

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

Выходим из sql-оболочки:

Теперь переходим на страницу http://<IP-адрес сервера>/postfixadmin/public/login.php вводим логин root@remontka.com и пароль qwe12345 — мы должны оказаться в системе управления почтой.

4. Настройка Postfix

По умолчанию, Postfix уже установлен в CentOS 7. Но если встретится сервер без него, выполним установку простой командой:

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

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

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

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

* данная настройка указывает, какой домен подставлять отправителю, если он не указан в заголовке FROM.

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

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

* разрешаем отправлять сообщения локальному серверу.

* необходимо убедиться, что postfix будет слушать на всех необходимых интерфейсах, в данном случае, на всех ( all ). Также можно задать варианты loopback-only (127.0.0.1) или конкретный IP-адрес интерфейса.

* данный параметр задаст протокол для работы postfix. В данном примере на всех ( all ). Также можно задать значения ipv4 или ipv6 .

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

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

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

* где 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 — настройки ограничения клиентских соединений. В данном примере разрешить только авторизованных.

Перезапустим 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 задает пользователя и группу владельцев на сокет.

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

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

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

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

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

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

Приводим опцию imap_client_workarounds к виду:

* данная настройка позволит решить проблему потери соединения между Outlook и сервером IMAP.

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

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

Создаем файл с настройками работы с 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

Генерируем сертификаты безопасности

Создаем каталог, в котором разместим сертификаты:

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

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

Запускаем 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. Смотрим версию продукта (желательно, LTS):

В нашем примере это версия 1.5.6. Создаем переменную:

Загружаем архив программы:

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

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

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

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

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

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

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

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

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

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

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

Создаем пользователя и даем ему полные права на созданную базу:

Выходим в Linux shell:

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

Если система вернет ошибку ERROR 1071 (42000) at line 51: Specified key was too long; max key length is 767 bytes , переходим к решению ниже.

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

Настроим php:

* date.timezone задает часовой пояс (в данном примере московское время); allow_url_fopen включает поддержку оберток URL, которые позволяют работать с ними как с обычными файлами.

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

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

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

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

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

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

И заходим в браузере по адресу http://<IP-адрес сервера>/webmail/ .

В редких случаях, мы можем получить ошибку 504 при попытке войти в систему. Проблема может быть в несовместимости механизма аутентификации между MySQL и Roundcube. Для решения проблемы необходимо задать пароль учетной записи roundcube с использованием нативного плагина:

mysql -uroot -p

> ALTER USER ’roundcube’@’localhost’ IDENTIFIED WITH mysql_native_password BY ’roundcube123′;

> FLUSH PRIVILEGES;

> quit

Если при отправке сообщения мы видим ошибку авторизации SMTP, открываем конфигурационный файл roundcube:

Приводим опцию smtp_pass к виду:

8. Защищаемся от вирусов

Установка и настройка ClamAV

Устанавливаем антивирус:

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

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

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

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

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

• 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. В данном случае локальный компьютер.

Конфигурируем clamsmtpd:

* где ClamAddress указываем на путь к сокетному файлу — он должен совпадать с путем к LocalSocket в конфигурационном файле для clamscan;

Редактируем конфигурационный файл для clamscan:

* где #Example — закомментированная Example, которая не позволит запустить сканер, пока ее не удалить или закомментировать; LocalSocket — путь до сокетного файла для взаимодействия с clamsmtp; User — пользователь, от которого будет запускаться clamd.

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

Комментируем строку:

И добавляем:

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

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

Запускаем clamscan:

* запуск может занять некоторое время. Если мы получим ошибку Job for clamd.service failed because timeout was exceeded , переходим к ее решению .

И после запускаем clamsmtpd:

И также перезапускаем postfix:

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

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

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

Проверка

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

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

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

9. Боремся со СПАМом

Проверка контента с помощью Spamassassin

Устанавливаем spamassassin:

Редактируем master.cf:

Для smtp добавляем опцию фильтра:

* в данном случае мы добавим к сервису postfix smtp дополнительную опцию content_filter , которая отвечает за запуск фильтрации контента; spamassassin указывает на имя сервиса, который будет запускаться для фильтрации.

И добавить сам сервис для фильтра:

* spamassassin — добавляемый сервис фильтрации; /usr/bin/spamc — путь до исполняемого файла спамассасина; spamd — учетная запись, от которой запучкается spamassassin.

Создаем учетную запись spamd:

Обновляем spamassassin:

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

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

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

* обновление будет происходить каждый день в 03:30 .

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

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

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

Исходящие письма

Мы настроили антиспам фильтр для smtp-соединения. В основном, он будет отрабатывать для входящей почты. Если нам необходимо также проверять исходящую почту, в master.cf добавляем content_filter для smtps и submission:

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

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

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

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

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

… и если ее нет, то добавляем.

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

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

Проверим, что мы все сделали правильно:

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

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

Антиспам средствами 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 — проверяет наличие отправителя в черных списках.

* более подробное описание опций для защиты можно найти на странице main.cf(5) .

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

Защита от СПАМа «от себя к себе»

Часто можно наблюдать ситуацию, когда приходит спам от своих же ящиков (или ящиков своего домена, хотя таких почтовых адресов у нас не существует).

Это происходит из-за возможности в поле FROM подставить любой адрес. А адрес от своей организации может внушить доверие, что побудит пользователя откликнуться на нежелательное сообщение.

Для решения проблемы в Postfix нужно добавить простое правило:

Создадим сам файл:

Создаем карту:

Перезапускаем постфикс:

10. Отправка почты наружу

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

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

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

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

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

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

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

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

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

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

1. SPF .
2. DMARC .

Настройка DKIM

DKIM настраивается на сервере, а для каждого домена создается специальная запись в DNS. Подробнее в инструкции Настройка DKIM + Postfix .

Возможные проблемы

1. Job for clamd.service failed because timeout was exceeded

Появляется при попытке запустить службу clamd.

Причина: сервис стартует так долго, что время, которое отведено на его запук заканчивается.

Решение: увеличиваем время, в течение которого может стартовать сервис. Для этого открываем файл настройки юнита systemd для clamd:

В раздел [Service] добавляем:

Перечитываем юнит:

Снова пробуем запустить clamscan:

2. SQLSTATE[HY000] [2002] No such file or directory

Ошибка появляется при попытке установить PostfixAdmin на этапе установки соединения с базой данных.

Причина: при попытке соединиться с базой по имени localhost, последний может разрешаться в IP-адрес, на котором не слушает запросы MySQL или который ведет на IPv6.

Решение: пробуем подключиться к нашему хосту по адресу 127.0.0.1. Для начала подключаемся к командной строке СУБД:

Создаем пользователя, которому можно подключаться с адреса 127.0.0.1:

Выходим:

Теперь в конфигурационном файле:

… добавляем:

3. ERROR 1071 (42000) at line 51: Specified key was too long; max key length is 767 bytes

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

Причина: в старых версиях MySQL максимальный размер для длины префикса индекса равен 767 байт. Этого достаточно, чтобы создать поле varchar(255) в кодировке utf8, но схема Roundcube пытается использовать кодировку utf8mb4, для которой 767 байт — это 191 символ. В результате мы не можем создать таблицу с таким полем.

Решение: в файле дампа, который идет в комплекте с Roundcube изменим кодировку на utf8.

Это можно сделать одной командой:

Удаляем созданную базу для roundcube и заново ее создает. После можно еще раз восстановить схему.