Настройка postfix + dovecot + postfixadmin + roundcube + dkim на Debian

Настройка postfix + dovecot + postfixadmin + roundcube + dkim на Debian

Несмотря на то, что облачные сервисы вытесняют локальные, некоторые вещи остаются актуальны по сей день. Я расскажу про установку и настройку почтового сервера на базе postfix, dovecot, postfixadmin, roundcube на ОС Debian. Последнее время инфраструктура информационных систем стремительно изменяется, но классические почтовые сервера по прежнему актуальны и востребованы.

Если у вас есть желание научиться администрировать системы на базе Linux, рекомендую познакомиться с онлайн-курсом «Linux для начинающих» в OTUS. Цели статьи

  1. Рассказать о настройке DNS записей для почтового сервера.
  2. Установить и настроить базовый функционал почтового сервера на базе Debian с помощью Postfix и Dovecot.
  3. Настроить панель управления почтовым сервером Postfixadmin.
  4. Настроить Web интерфейс Roundcube, а так же его плагины acl, managesieve.
  5. Рассказать о способах борьбы со спамом средствами Postfix.

Данная статья является частью единого цикла статьей про сервер Debian.

Введение

Меня побудило к написанию новой статьи по настройке почтового сервера Linux информация о том, что Яндекс больше не будет бесплатно предоставлять услугу по использованию почты со своим доменом. Это очень популярный сервис, которым я сам активно пользовался и всем его рекомендовал. Теперь становится понятно, что скорее всего больше такой услуги не будет в бесплатном виде ни у кого. Тенденции явно прослеживают на платность данной услуги.

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

Как я уже сказал, настраивать почтовый сервер буду на ОС Linux, а точнее на Debian. За основу будет взят Postfix, который присутствует в этой системе из коробки. Инструкция получится универсальной, можно использовать и для других дистрибутивов. Все основные конфиги легко переносятся на разные системы, требуя минимальной правки, в основном путей. Думаю, что вообще без какой-то дополнительной правки эта же статья будет полностью актуальна для Ubuntu.

Я напишу статью на самом что ни на есть реальном примере, без какой-либо правки доменов, ip и прочего, чтобы не ошибиться и показать максимально возможный реальный пример. У меня есть домен rocky-linux.ru. Я буду использовать его в своей работе. Почтовый сервер будет иметь имя mail.rocky-linux.ru.

Настройка DNS для почтового сервера

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

Для написания этой статьи, я сделал поддомен mail.rocky-linux.ru. Для работы почты нет никакой разницы, используется домен первого, второго или третьего уровня. Почтовые ящики у меня будут вида user1@rocky-linux.ru. Внешний ip адрес, на котором будет работать сервер — 62.113.115.231.

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

ИмяТипЗначение
mail.rocky-linux.ruA62.113.115.231

Подробнее о типах DNS записей читайте на википедии. У меня в итоге получилось вот так:

Настройка DNS для почтового сервера

Но это не всё. К сожалению, указанных DNS записей недостаточно. Для вашего внешнего IP адреса должна быть прописана обратная зона — PTR. В обратной зоне IP адресу ставится в соответствие доменное имя. То есть вашему IP адресу должно соответствовать доменное имя mail.rocky-linux.ru. Это идеальная ситуация, когда обратная зона соответствует имени почтового сервера. Не всегда это возможно. Важно, чтобы PTR зона была прописана и соответствовала реально существующему статическому доменному имени.

Настройками обратной зоны во многих случаях вы не можете управлять. Иногда это возможно через панель управления провайдера, если это какой-то хостер с VPS или выделенным сервером. В остальных случаях нужно обратиться к вашему провайдеру, который выделил вам внешний IP и сказать ему, что вы хотите настроить почтовый сервер и вам необходимо прописать обратную зону с именем mail.rocky-linux.ru на внешний IP адрес. Это обычная просьба, и тех поддержка без проблем сделает то, что вы просите, если они предоставляют такую услугу. Чаще всего провайдеры, работающие с юридическими лицами, такую услугу предоставляют. Домовые провайдеры для физиков — нет.

Проверить обратную зону для домена можно в консоли сервера с помощью команды host. Вот пример для моего внешнего IP. Я не стал прописывать домен mail.rocky-linux.ru, так как этот IP адрес используется в том числе для других целей. Привожу просто для примера:

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

Проверка DNS

Тут полное соответствие всех записей. MX запись соответствует A записи, а IP адрес A записи резолвится в доменное имя, указанное в MX. Вам в идеале нужно сделать также. Иногда люди путают, называют, к примеру, сервер mail.site.ru, а обратную зону делают просто site.ru или srv.site.ru. Вроде всё правильно, домен один и тот же, но соответствие не полное. Чтобы всё было корректно, должно быть полное соответствие всех записей — A, MX, PTR. Очень много спам фильтров используют эти записи для проверки домена отправителя на полное соответствие. Отклонение от идеала добавляет лишние баллы, но не означает, что почта не будет доставлена.

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

Подготовка сервера

После того, как закончите с DNS, можно приступать к настройке самого сервера. Рекомендую воспользоваться услугами провайдера Selectel. У него помимо очень дешёвых выделенных серверов, есть в том числе и бесплатная услуга по хостингу DNS. Я обычно там заказываю дешёвый выделенный сервер, устанавливаю туда Proxmox, создаю виртуалки. И одну из них использую под почтовый сервер.

Если у вас еще не настроен сервер с Debian, рекомендую мои материалы на эту тему:

Отдельно потратьте время на настройку iptables. Я не буду касаться этого вопроса в данной статье, чтобы не раздувать ее второстепенными вещами. Удобнее, когда всё по отдельности рассказано и описано с должной глубиной. Сваливать все в одну кучу не хочется.

Установка postfixadmin

Начнем с установки и настройки панели управления почтовым сервером postfix — postfixadmin. Без него начинать что-то делать неудобно, так как управлять пользователями, ящиками, алиасами будет нечем. По своей сути postfixadmin — набор php скриптов для управления записями в MySQL базе данных, которую использует сервер postfix во время своей работы. Соответственно, для работы postfixadmin нам нужен web сервер.

Подробно на настройке веб сервера я останавливаться не буду. Быстро установим всё необходимое для дальнейшей работы, в том числе и веб интерфейса с tls сертификатами. Привожу только команды, с минимумом комментариев.

Установка nginx:

Установка php-fpm со всеми модулями, которые нам понадобятся во время настройки по данному руководству:

Установка MariaDB:

Для простоты откажитесь от unix_socket authentication и задайте пароль root. Не хочется в этой статье останавливаться на настройке MariaDB.

Теперь, зайдя браузером на страницу с ip адресом сервера, вы должны увидеть приветственную страницу Nginx.

Установка NGINX

Если страница не открывается, то скорее всего у вас не настроен firewall. Займитесь его настройкой, ссылку я давал в начале. Если он вам не нужен, то удалите или отключите его.

Предлагаю сразу поставить phpmyadmin, с ним удобно работать с базой. В нашем случае все пользователи будут храниться в mysql, иногда может понадобиться туда заглянуть.

По умолчанию у phpmyadmin нет готовой настройки под nginx, поэтому настроим вручную. Сделаем символьную ссылку:

Приведёт дефолтный конфиг nginx /etc/nginx/sites-available/default к следующему виду:

Проверяем и перезапускаем nginx:

При переходе по адресу http://ip-сервера/phpmyadmin вы должны попадать в интерфейс панели управления. Можно зайти под учётной записью root. Если вы настроили веб сервер на внешнем интерфейсе, то оставлять phpmyadmin доступным для всех крайне нежелательно. Нужно ограничить доступ тем или иным способом. Можно по IP, либо паролем. Закроем паролем:

Создали пользователя pmauser01. Теперь включим аутентификацию в nginx. Добавляем новые параметры.

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

Устанавливаем postfixadmin. Его, к сожалению, нет в базовых репозиториях Debian, поэтому скачаем и установим свежую версию вручную. Адрес для загрузки возьмём в репозитории на github.

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

Убедитесь, что файл config.local.php содержит следующие исправленные параметры.

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

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

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

У меня распространены ситуации, когда я удаленно администрирую сервера, а на месте поддержка работает с пользователями. Чаще всего это не очень аккуратные и ответственные люди, иначе они бы работали с серверами 🙂 Они часто забывают записать пароль, путают что-то и т.д. В итоге, когда один человек увольняется и приходит другой, оказывается, что найти пароли на некоторые ящики просто невозможно. Тут очень выручает возможность посмотреть пароль в базе. Я новому админу либо пароль говорю, либо весь дамп сразу отдаю, пусть работает.

Если вы сами работаете с сервером и всё аккуратно ведёте, записываете, например, в keepass все пароли от почтовых ящиков, то смело шифруйте все пароли, так будет спокойнее.

Последние 2 параметра domain_path и domain_in_mailbox указывайте по своему усмотрению. В файле конфигурации в комментариях расписано, за что они отвечают и в чём отличие. Мне кажется, удобно хранить директории именно в таком виде, как я указал. Получится следующий путь до ящика, если у вас архив почты будет жить, к примеру, в директории /mnt/mail — /mnt/mail/rocky-linux.ru/root@rocky-linux.ru. Если доменов будет несколько, в такой иерархии удобно работать.

В базе данных Mysql необходимо создать указанные выше в конфигурации пользователя и базу postfix. Если устанавливали phpmyadmin, то можете это сделать там.

С параметрами разобрались. Сохраняем конфиг. Еще один маленький нюанс. Для работы панели управления нужна директория templates_c с правами на запись для web сервера. Сделаем ее и дадим права.

Идем по адресу http://ip-сервера/postfixadmin/public/setup.php и начинаем установку postfixadmin. Первым делом идет проверка всех необходимых для установки и работы компонентов. Для продолжения установки у вас должна быть такая картинка.

Установка postfixadmin

Нам необходимо указать пароль установки, на основе которого будет сгенерирован hash, который нужно будет добавить в config.local.php. Для этого в форму Generate setup_password введите два раза пароль, который обязательно должен содержать буквы и 2 цифры.

После генерации пароля, под формой появится строка конфига:

Её нужно добавить в config.local.php в директории postfixadmin. Достаточно заменить строку, которая там есть по умолчанию со значением changeme.

После того, как это сделаете, обновите страницу в браузере. Информация там изменится. У вас не должно быть замечаний к конфигурации, кроме предупреждений по поводу PostgreSQL, так как она нам не нужна и мы её не настраивали. А все остальные проверки должны быть с зелёными индикаторами. Если есть какие-то ошибки, то исправьте их. Обычно забывают или неправильно указывают параметры доступа к MySQL, копируя конфиги из статьи.

Настройка postfixadmin

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

Панель управления Postfix

Используя созданную учётную запись, можно авторизоваться в панели управления. Для этого перейдите по ссылке http://ip-сервера/postfixadmin/public/login.php

Интерфейс postfixadmin

Сразу же добавим наш домен в список почтовых доменов. Идем в раздел Список доменов -> Новый домен и добавляем свой домен. Я обычно не ставлю никаких ограничений.

Добавление домена

При создании домена были добавлены стандартные алиасы, получателя для которых мы указали еще в конфиге — ящик root@rocky-linux.ru. Создание таких алиасов — требование стандартов, но по факту, кроме спама, вы скорее всего ничего не будете получать по этим адресам. Так что их создание оставляйте на свое усмотрения. Я обычно их не делаю, так как ящик для этих алиасов все равно не читаю.

Далее создадим почтовый ящик администратора — root@rocky-linux.ru (на картинках имя ящика admin, уже в процессе передумал и решил делать root). Для этого идем в раздел Обзор -> Создать ящик и заполняем поля.

Вы получите ошибку, что невозможно отправить сообщение. Это нормально, так как непосредственно почтового сервера у нас еще нет, только панель управления для него. Сам ящик на диске создан тоже не будет, но запись в базе данных появится. Это можно проверить через phpmyadmin.

Почтовый ящик в mysql базе

Как вы видите, пароль зашифрован. На этом установку и настройку postfixadmin завершаем. Интерфейс для управления почтовым сервером мы подготовили. Теперь можно заняться непосредственно настройкой postfix.

Настройка postfix

Сердце нашего почтового сервера на Linux — Postfix. В дистрибутиве Debian в минимальной установке он по умолчанию отсутствует. Так что сначала устанавливаем postfix.

Во время установки будет задан вопрос по поводу назначения этого сервера. Тут не важно, что выбрать. Всё равно конфигурацию мы полностью составим сами. Так что можете оставить тот вариант, что будет по умолчанию. Имя сервера укажите как в DNS записи. В моём случае — mail.rocky-linux.ru.

Приводим конфиг postfix /etc/postfix/main.cf к следующему виду, предварительно сохранив оригинальный (рекомендую всегда так делать).

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

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

Так же не стоит забывать, что в современных ОС зачастую на уровне всей системы запрещено использование старых протоколов шифрования, таких как tls 1.0 или ssl3. Чтобы разрешить их, недостаточно настроек почтового сервера. Надо менять системные настройки. Например, вот так это делается в Centos и производных rpm системах — Centos 8 и TLS 1.0 и 1.1.

Продолжаем настройку почтового сервера postfix. Редактируем файл /etc/postfix/master.cf. Нам надо добавить строки, касающиеся настройки Submission для того, чтобы почтовый сервер работал на 587 порту. Смартфоны очень часто при настройке используют этот порт по умолчанию, где-то даже без возможности изменить эту настройку. Приводим секцию, отвечающую за эту работу, к следующему виду.

Обращаю внимание на пробел в начале строки, начиная со второй. Его надо обязательно оставить. Добавляем еще настройки для того, чтобы наш сервер поддерживал протокол SSL/TLS и слушал порт 465

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

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

Создаем директорию и сами сертификаты:

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

Настройка postfix

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

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

Теперь создайте два почтовых ящика all_in@rocky-linux.ru и all_out@rocky-linux.ru через postfixadmin.

Немного поясню по этим ящикам — для чего они нужны. Изначально я их делал, когда пользователи использовали протокол pop3 без сохранения писем на сервере. Это позволяло организовать бэкап всей переписки. Эти ящики очень быстро заполняются и занимают огромный объем, поэтому их обязательно надо чистить. Я просто скриптами регулярно собирал всю почту в архивы с именами в виде дат. Если нужно было какое-то письмо найти, то просто распаковывал нужный архив. Пример прямого поиска писем по дате я показывал в статье про обслуживание почтовой базы.

В случае с imap роль бэкапа отпадает, так как вся почта хранится на сервере. Но эти ящики все равно бывают полезны, когда пользователь, к примеру, удалил какое-то важное письмо и потом делает вид, что его и не было. Если это письмо пришло только сегодня и еще не успело улететь в бэкап, то кроме записи в логах об этом письме, вы не увидите само содержимое. А с такими ящиками все сразу будет понятно, и вопросы отпадут. Последнее применение — служба безопасности. Если у вас есть кто-то, кому положено читать всю переписку, то реализовать этот функционал можно таким простым способом.

Все основные настройки для postfix мы сделали. Некоторые из них завязаны на работу с dovecot, который мы еще не настроили. Поэтому больше postfix не трогаем, не перезапускаем. Идем настраивать dovecot — imap сервер нашей почтовой системы.

Настройка dovecot

Займемся настройкой dovecot — сервер доставки почты пользователю по протоколам pop3 и imap. Я не вижу причин использовать pop3. Он неудобен по сравнению с imap. Чаще всего pop3 отключаю вовсе. Но это уже на ваше усмотрение. Приведу пример с настройкой обоих протоколов. Помимо основного функционала по доставке почты, я настрою несколько полезных плагинов. Расскажу о них поподробнее:

  • Sieve — выполняет фильтрацию почты по заданным правилам в момент локальной доставки на почтовом сервере. Удобство такого подхода в том, что вы один раз можете настроить правило сортировки, и оно будет работать во всех клиентах, которыми вы будете получать почту по imap. Правила создаются, хранятся и исполняются на самом сервере.
  • Acl — позволяет пользователям расшаривать папки в своем почтовом ящике и предоставлять доступ к этим папкам другим пользователям. Не часто видел, чтобы этот функционал настраивали и использовали. Думаю, просто по незнанию. По мне так очень удобный и полезный функционал.

Часто вижу, что люди настраивают плагин quota, который позволяет ограничивать максимальный размер почтового ящика. Я лично в своей работе его не использую. Возможно, когда у тебя клиентов сотни и тысячи это имеет значение и надо обязательно настроить ограничение. Когда же ящиков меньше, нет смысла напрягать людей постоянной чисткой. Сейчас диски стоят не так дорого. Мне кажется, проще и дешевле увеличить место на сервере, нежели постоянно беспокоить пользователей необходимостью чистки ящика. Лучше ограничить максимальный размер письма, скажем 20-ю мегабайтами. Тогда сильно забить ящик даже при большом желании быстро не получится. А почта все-таки важный инструмент в работе. Мне кажется, ее лучше хранить как можно дольше.

Есть еще один полезный плагин — expire, который позволяет удалять устаревшие письма в определенных папках. Например, удалять все письма старше 30-ти дней в корзине и папке со спамом. Но реально пользоваться им не получается по простой причине. Разные почтовые клиенты создают различные папки для корзины и спама. Thunderbird создает папки с латинскими именами trash и spam, outlook с русскими, которые на почтовом сервере преобразуются в кодировку UTF7, мобильные клиенты тоже используют разные имена папок. В итоге нет единообразия, плагин полноценно не работает.

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

Небольшую теорию я дал, теперь переходим к практике. Устанавливаем необходимые для dovecot пакеты.

Изначально конфиг dovecot разбит на отдельные сегменты и лежат они в директории /etc/dovecot/conf.d. Каждый файл — отдельный функционал. Мне не нравится прыгать по файлам, поэтому я храню всё в едином общем файле конфигурации /etc/dovecot/dovecot.conf. С ним мы и будем работать. Обращаю внимание, что это только вопрос удобства. Можете оставить все файлы отдельности, если вам так привычнее. Приводим конфиг к следующему виду.

Создаем группу и пользователя с указанными в конфиге uid 1100. Если у вас уже занят этот uid, то везде замените его на другой или удалите пользователя с uid 1100, если он вам не нужен.

Создаем конфигурационные файлы для доступа к mysql базе.

Обращаю внимание на параметр шифрования паролей. Если пароли не зашифрованы, то параметр будет PLAIN.

Создадим директорию и файлы для логов.

Создаем служебную папку для плагина acl.

На этом основная настройка почтового сервера на базе postfix и dovecot завершена. Можно запускать службы и проверять работу системы.

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

Настройка logrotate для dovecot

Для того, чтобы логи Dovecot не разрослись до бесконечности, их имеет смысл периодически ротировать с помощью logrotate. Для этого создадим файл конфигурации /etc/logrotate.d/dovecot следующего содержания:

Для логов postfix этого делать не нужно, так как они обрабатываются с помощью системной службы rsyslog, для которой ротация обычно уже настроена в системе по умолчанию.

Проверка работы почтового сервера

Самый простой и быстрый способ проверить работу почтового сервера — отправить на него письмо. Я буду отправлять со своего почтового адреса zeroxzed@gmail.com на адрес root@rocky-linux.ru. Вот что должно быть в логе, если у вас все правильно настроено и почтовый сервер нормально работает.

Пояснять тут нечего, по логу все понятно. Было подключение от сервера mail-ej1-f43.google.com[209.85.218.43] с использованием протокола шифрования и шифров TLSv1.3 with cipher TLS_AES_128_GCM_SHA256.

Письмо было доставлено в указанный ящик. В директории /mnt/mail была создана директория с именем домена rocky-linux.ru, а в ней создана папка с именем ящика root@rocky-linux.ru. В итоге новое, ещё не прочитанное письмо, лежит здесь — /mnt/mail/rocky-linux.ru/root@rocky-linux.ru/new. Можно зайти и прочитать его прямо через консоль. Это обычный файл в текстовом формате.

Во время этого теста у меня был отключен сбор входящей почты в отдельный ящик all-in. Если бы это было включено, то в логе отдельной строкой было бы указано, что письмо сохранено и в этот ящик.

Директории с почтовыми ящиками создаются в момент получения первого письма в ящик. Непрочитанное письмо помещается в директорию new в почтовом ящике. После прочтения переносится в cur.

Попробуем теперь подключиться к почтовому ящику по imap, прочитать письмо и отправить ответ. Настроим любой почтовый клиент для проверки работы настроенного почтового сервера. Я для этих целей буду использовать Thunderbird. Из всех почтовых клиентов мне он нравится больше всего. В основном из-за его портированной версии. Указываем следующие настройки.

Настройка почтового сервера в Thunderbird

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

Самоподписанный сертификат в Thunderbird

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

Я подключился к почтовому ящику и увидел тестовые письма. Отвечу на одно из них и посмотрю в логе, как прошла отправка. У меня еще раз выскочило окно с предупреждением о небезопасном сертификате. Еще раз добавляю его в исключения. Это нормально, сертификат проверяется во время получения почты в dovecot, а во время отправки в postfix. Так что нужны 2 подтверждения. Отправляю письмо еще раз и смотрю лог.

Все в порядке. Видно подключение с моего ip, успешную sasl авторизацию, формирование письма на сервере, присваивание ему message-id, отправка в ящик получателя. Все этапы прошли без ошибок.

Расскажу, куда еще надо смотреть для отладки почтовой системы. Да и не только отладки, во время работы периодически придется разбираться, куда ушло то или иное письмо, кто и когда подключался к ящику. Разные ситуации бывают. В файле /var/log/dovecot/lda-deliver.log содержится информация обо всех пришедших письмах — когда, от кого и в какой ящик было положено.

В /var/log/dovecot/info.log информация о подключениях к почтовым ящикам — кто, когда, откуда и каким способом подключался к серверу. Вот пример успешной аутентификации:

А вот неудачной:

Тут кто-то пытается подключиться, используя несуществующий ящик:

Эти три лога основные для разбора ситуаций:

  • postfix — mail.log
  • dovecot — lda-deliver.log
  • dovecot — info.log

На текущий момент почтовый сервер на базе postfix и dovecot полностью работоспособен. В таком виде им без проблем можно пользоваться. Но функционала мало. Использовать плагины sieve и acl через удаленные почтовые клиенты неудобно. Проще всего их настроить через web почту roundcube. Установим эту web панель на наш почтовый сервер.

Установка web интерфейса roundcube

Установим и настроим самый популярный web интерфейс для postfix — roundcube. Вообще говоря, его не обязательно ставить на почтовый сервер. Более того, я бы рекомендовал его ставить в другое место. Если в инфраструктуре имеется отдельный веб сервер, лучше поставить roundcube туда. Но в рамках этой статьи, я всё буду ставить на один сервер для простоты и наглядности. Если у вас всё получится на одном сервере, потом сможете не спеша разнести по разным.

Скачиваем исходники последней LTS или STABLE версии roundcube. Я обычно использую именно LTS версию, хотя она достаточно старая. Но моя практика показывает, что именно в ней всё работает стабильно и сразу, без лишней возни. К примеру, когда я готовил эту статью, у меня не получилось настроить работу автоответчика, о котором я расскажу отдельно ниже. Я его включал, а он просто не работает. За разумный срок (1 час) я не смог выяснить причину этого и опять откатился на LTS версию, где все заработало сразу.

Если есть желание, попробуйте последнюю версию. Может всё, что вам надо, заработает. Но в целом, там во всех версиях всё примерно одинаковое. В новых версиях есть адаптивный скин elastic, но кто-то по-прежнему использует стандартный larry.

Распаковываем и перемещаем на веб-сервер. Я установлю веб интерфейс для почты на отдельный поддомен webmail, а исходники положу в директорию /web/sites/webmail.rocky-linux.ru/www. Это моя стандартная структура каталогов для веб сервера. Вы можете сделать, как вам удобно. Не обязательно полностью повторять за мной.

Не забудьте проверить в момент установки номер актуальной версии roundcube и заменить его в приведенных выше командах.

Отмечу, что если для вас не критично использовать максимально свежую версию, можете установить roundcube из стандартного репозитория Debian. Но даже LTS версия там старее, чем та, что есть на сайте. На момент написания статьи в репозитории была версия 1.4.13 от 30-го декабря 2021 года, а на сайте 1.5.3 от 26 июня 2022 года. Разница в пол года.

Установим необходимые для работы roundcube зависимости:

Меняем некоторые параметры в php. Редактируем или добавляем в /etc/php/7.4/fpm/php.ini:

Перезапускаем php-fpm.

Создаём конфигурацию виртуального хоста для roundcube. Если вы планируете заходить в веб почту по ip адресу, как в phpmyadmin или postfixadmin, то ничего настраивать не надо. Просто положите исходники в папку веб сервера /var/www/html и заходите по ip.

Я сразу же закрыл доступ посторонним к roundcube дополнительным паролем через basic auth, как я это сделал в самом начале с phpmyadmin. Это не обязательно делать. Roundcube вполне безопасная панель и её можно оставлять в открытом доступе. Но и в ней находили критические уязвимости. Так что за ней нужно внимательно следить и регулярно обновлять, защищать от перебора учёток и т.д. Если закрыть доступ отдельным паролем, то можно следить не так внимательно. Как делать — решать вам. Для пользователей лишняя аутентификация всегда нежелательна.

Сохраняем конфигурацию nginx в файл /etc/nginx/sites-available/webmail.rocky-linux.ru.conf и делаем символьную ссылку с него в /etc/nginx/sites-enabled:

Проверяем конфигурацию nginx и перезапускаем:

Если всё в порядке, то можно идти по адресу http://webmail.rocky-linux.ru/installer/ и выполнять настройку roundcube. Вы должны увидеть интерфейс установщика и все проверки в состоянии OK, кроме тех, что касаются сторонних баз. Нам нужна только MySQL. 

Установка roundcube

В самом низу нажимайте NEXT. Здесь нужно будет указать параметры подключения к базе данных. Создайте отдельную базу данных для roundcube и укажите данные подключения.

Также на этой странице нужно будет указать несколько параметров:

  • smtp_server — localhost
  • smtp_port — 25
  • Use the current IMAP username and password for SMTP authentication — галочка должна стоять
  • language — ru_RU
  • skin — elastic (можете поменять на larry, если вам он больше нравится)
  • Выбираем плагины — acl, managesieve, userinfo. Остальные на свое усмотрение.

Жмем CREATE CONFIG. Должны увидеть сообщение:

Жмем CONTINUE. Открывается страница с проверкой настроек. Нам нужно инициализировать базу данных. Для этого жмите на соответствующую кнопку.

Roundcube webmail installer

Тут проверять отправку почты неудобно, можно этого не делать. Зайдем в почтовый ящик и там всё проверим. Если что, конфиг потом всё равно можно вручную отредактировать. Папку installer удаляем. Заходим в почтовый ящик через roundcube. Набирать нужно полное имя ящика и пароль. Если всё сделали правильно, должны попасть в свой почтовый ящик.

Веб интерфейс roundcube

Мне уже успели спам прислать, пока писал статью. Можете попробовать написать и отправить письмо. В настройках можно изменить некоторые параметры web интерфейса. Если будут какие-то ошибки, можно посмотреть лог самого roundcube — /web/sites/webmail.rocky-linux.ru/www/logs/errors.log Он достаточно информативен. В этой же директории будет вестись лог всех отправленных писем через web интерфейс.

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

Настройка фильтра почты sieve

Sieve очень удобная штука, но вот хорошего интерфейса для управления через почтовый клиент я не знаю. Существует плагин для Thunderbird, который так и называется — sieve. Но лично мне он не понравился вообще, так как предлагает писать правила определенным кодом. Для этого надо знать синтаксис, тратить время. Можете сами на него посмотреть — https://github.com/thsmi/sieve.

К счастью, есть удобный способ писать правила фильтрации для sieve через roundcube. Там это реализовано отдельным плагином managesieve, который мы активировали во время установки. Его конфиг находится в директории plugins/managesieve. Скопируйте дефолтный конфиг и проследите, чтобы там были следующие настройки.

Для создания правила фильтрации, зайдите в свой почтовый ящик через roundcube. Переходите в раздел Настройки -> Фильтры и создавайте новое правило.

Настройка фильтра почты sieve

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

Настройка автоответчика

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

Для того, чтобы модуль автоответчика заработал, отредактируйте конфигурационный файл плагина. Для этого открываем его в моем случае по следующему адресу /plugins/managesieve/config.inc.php. Изменяем там параметр:

После этого достаточно просто обновить веб интерфейс roundcube, и появятся новые настройки по адресу Настройки -> Вне офиса.

Настройка автоответчика в postfix

По своей сути настройка автоответчика — это просто создание еще одного правила sieve для всей входящей почты.

Общие папки по imap

Рассмотрим настройку необычного и полезного функционала в виде общих папок. С их помощью один пользователь почтового ящика может предоставить другому пользователю доступ к папке внутри своего почтового ящика. Где и как использовать этот функционал, каждый может придумать сам, в зависимости от своих потребностей. Мне кажется это удобным в том случае, когда создан какой-то общий ящик, на который только поступает информация и нет необходимости писать ответ от его имени. То есть по сути работает как обычный почтовый алиас. Но в случае с алиасом и несколькими почтовыми ящиками, письмо падает в каждый ящик. Если таких писем и получателей много, то идет большое дублирование одного и того же письма в рамках почтового сервера. Если сделать ящик и настроить общий доступ к папке, подключить ее всем пользователям, то дублирования почты не будет. Каждый сможет прочитать письмо, без необходимости его доставки в каждый конкретный ящик.

Настроим общую папку imap. Хотя настраивать нам, по сути, нечего. Мы уже всё настроили ранее. Добавили соответствующие настройки в dovecot и активировали плагин acl в roundcube. Теперь нужно просто сделать папку и открыть ее для другого пользователя. Для этого идем в раздел Настройки -> Папки. Создаем там любую папку. В моем случае это папка с названием Общая. После того, как создали папку, открываем ее еще раз.

Общие imap папки

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

  • чтение
  • запись
  • удаление
Права доступа на почтовые папки

Заходим в ящик, которому добавили общий доступ и проверяем.

Подключение общей папки почты

Все в порядке, общая папка imap настроена и подключена. В папке /mnt/mail/shared-folders появился файл с настроенным выше правилом.

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

Настройка DKIM

Напишу своими словами как я понимаю работу dkim. С помощью dkim вся исходящая почта сервера подписывается электронной цифровой подписью, связанной с именем домена. Открытый ключ шифрования с помощью DNS публикуется в txt записи. Таким образом, удаленный сервер, при получении письма от вас, сравнивает цифровую подпись с опубликованным в DNS открытым ключом вашего домена. Если всё в порядке, то считает, что ваше письмо в самом деле пришло от вас, а не от мошенников. То есть с помощью этой технологии можно однозначно идентифицировать отправителя.

Не путать эту технологию с защитой от спама. Защиты тут нет. Любой спамер так же может себе сделать dkim подпись. Спамеру не составит большого труда настроить на своем сервере dkim и отправлять спам, но подписанный электронной цифровой подписью. Теоретически, dkim помогает защититься от подделки адреса отправителя, когда письмо якобы от вас шлет совсем другой сервер. Но с этим можно бороться и другими способами. В общем, я до конца не понимаю, зачем это надо. Я много лет эксплуатировал сервера без dkim подписей и проблем это не вызывало. Но так как настроить dkim не сложно, сейчас всегда это делаю.

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

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

Генерируем ключи для домена:

rocky-linux.ruимя почтового домена
mailселектор, я обычно указываю как имя самого сервера

На выходе получаете пару файлов — закрытый (приватный) и открытый ключ. Закрытый останется на сервере, открытый будет опубликован в DNS. Переименуем их сразу, чтобы не путаться, если у вас будет несколько доменов. Ключи нужно будет делать для каждого домена.

Создаем файл с таблицей ключей, в которой будут описаны все домены. В данном случае только один.

Тут же создаем еще один файл, в котором будет описано, каким ключом подписывать письма каждого домена. У нас один домен, поэтому только одна запись.

Выставляем права доступа на все файлы:

Рисуем конфиг службы.

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

Перезапускаем postfix и dkim, последний добавляем в автозагрузку.

Теперь нам надо добавить открытый ключ в DNS. Идём в консоль управления DNS и добавляем новую TXT запись. Ее содержание берем из файла /etc/postfix/dkim/mail.rocky-linux.ru.txt

Убираем кавычки, лишние пробелы и вставляем. Должно получиться вот так:

Настройка DKIM

Проверяю работу. Отправляю письмо на gmail и смотрю лог почтового сервера:

# tail -f /var/log/mail.log

Все в порядке, электронная цифровая подпись установлена. Проверим, как google отреагировал на нашу подпись:

Проверка DKIM

Тоже всё в порядке. Подпись выполнена корректно, проверку прошла. Дополнительно проверить корректность dkim записи в dns можно онлайн сервисом — http://dkimcore.org/c/keycheck. Не забывайте, что DNS записи обновляются не мгновенно. Прежде чем проверять DKIM, подождите от 10 минут до часа, а может и больше.

Настройка SPF

Настроим еще одно средство для повышения доверия к нашей почте со стороны других серверов — spf. Расскажу опять своими словами для чего это нужно. Spf запись добавляется в виде TXT записи в DNS вашего домена. С помощью этой записи вы указываете, какие ip адреса имеют право отправлять почту от вашего имени. Если кто-то из спамеров будет использовать ваше имя домена при рассылке спама, он не пройдет проверку по spf и скорее всего будет идентифицирован как спам.

Можно указать конкретные ip адреса в записи, а можно сказать, чтобы ip адреса проверялись по спискам A и MX записей. У нас простой случай и только 1 сервер с одним ip, поэтому укажем конкретно этот ip адрес. Идём в панель управления dns и добавляем новую TXT запись.

Настройка SPF

Больше ничего делать не надо. Можно снова отправить письмо на gmail и проверить. Обращаю внимание, что gmail может и без настройки spf в dns указать, что проверка spf прошла, хотя txt запись еще не была создана. Гугл умный. Думаю, он автоматом сопоставляет все dns записи домена и убеждается, что отправка идет с доверенного сервера, к которому привязана A запись и MX запись.

Но отправка может идти не только с почтового сервера. К примеру, может быть отдельно web сервер с интернет магазином. Он по каким-то причинам может отправлять почту сам (нет модуля для smtp отправки, не работает smtp авторизация, разработчики хотят использовать php_mail и т.д.), а не через настроенный почтовый сервер. Так часто бывает. Тогда нужно обязательно добавить в spf запись ip адрес этого web сервера, с которого будет идти отправка.

Настройка DMARC

Для настройки DMARC на самом почтовом сервере ничего делать не надо. По своей сути это просто указание другим, что делать с письмами от вас, не прошедшими проверки dkim и spf (которые являются подделками, если у вас всё настроено правильно). Для этого сам принимающий почтовый сервер должен поддерживать работу в соответствии с dmark. Плюс, для вашего домена должны быть настроены правила, что делать в том или ином случае.

Есть три типа действий, которые можно настроить с помощью dmark:

  1. Отклонить письмо.
  2. Пометить письмо как спам.
  3. Ничего не делать.

При этом можно настроить при каждом действии формирование отчета и отправку его на какой-то email адрес. Я очень осторожно отношусь к этим правилам и никогда не настраиваю блокировку или пометку о спаме. Так можно выстрелить себе в ногу и загубить всю свою почту из-за какой-нибудь ошибки. Мне кажется, разумнее всего настроить пропускание всех писем, но сделать отправку отчетов на свой существующий адрес. Если вы заметите какую-то подозрительную активность по отчетам, то можно будет временно изменить настройки, чтобы помечать все поддельные письма, к примеру, как спам.

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

Настройка DMARC

Отчеты будут приходить в xml формате на ящик dmarc@rocky-linux.ru. Нужно будет еще потрудиться, чтобы в них разобраться 🙂 В общем случае, я вообще не слежу за dmark. Думаю, это актуально только для крупных компаний, где есть отдельные люди, которые занимаются обслуживанием почты.

Дополнительный функционал почтового сервера postfix

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

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

  1. Защиту от подбора паролей с помощью fail2ban.
  2. Мониторинг почтового сервера postfix с помощью zabbix.
  3. Сбор статистики с помощью pflogsumm или чего-то подобного.
  4. Просмотр и анализ логов с помощью webmin.
  5. Использование бесплатных сертификатов let’s encrypt.
  6. Регулярную очистку служебных почтовых ящиков.
  7. Бэкап всей почтовой базы.
  8. Сбор логов с почтовых серверов в ELK Stack.

Расскажу, почему я не настраиваю некоторые популярные программы, которые используют на почтовых серверах:

  1. Clamav — известный антивирус. Считаю, что сейчас он не актуален, так как вирусов, от которых он способен защитить, я уже давно не видел. Сейчас вирусная эпидемия шифровальщиков. От них он не защищает. К тому же на момент написания статьи доступ к антвирусным базам с IP адресов РФ заблокирован. Нужно использовать прокси.
  2. Spamassasin или spamd — популярные бесплатные антиспам фильтры. Скажу честно, работал с ними очень мало и могу быть не объективен. Насколько я видел их настройку и работу — они требуют к себе некоторого внимания, калибровки, особенно на начальном этапе. Мне обычно не хочется этим заниматься. Вместо этого я использую либо платный антиспам от компании Kaspersky, либо перед почтовым сервером ставлю Proxmox Mail Gateway, который имеет все фильтры уже в настроенном виде с управлением через веб интерфейс.
  3. Graylist — эффективное средство борьбы со спамом. Я уже подробно его рассматривал, когда писал про iredmail, так что не буду повторяться. Скажу лишь, что режет спам очень эффективно и бесплатно, но есть существенные неудобства, которые по моему мнению не перекрывают плюсы. Поэтому я не использую.

В качестве антиспама я предпочитаю коммерческое решение — Kaspersky Anti-Spam. Я знаю этот продукт уже лет 15. Он действительно отлично фильтрует спам. Ложных срабатываний вообще не припомню, 95% спама фильтрует, может больше. Субъективно, работает лучше чем антиспам у того же Gmail или Яндекса. С ним вопрос спама отпадает вообще. Стоит он недорого, можно купить лицензию на меньшее количество ящиков, чем реально используется в системе. Этот вопрос никак не отслеживается и на качество работы не влияет. Но нужно понимать, что это уже нарушение лицензионного соглашения. Но можно всякие хитрости придумать, чтобы и фильтровать и не нарушать.

Борьба со спамом средствами postfix

Сначала хотел сразу все настройки postfix разместить в соответствующем разделе в едином конфиге, но потом передумал и решил все же вынести этот вопрос на отдельное рассмотрение. Возможно, не каждому захочется сразу в эту тему углубляться. Всё, что рассказано выше, позволит настроить полноценный почтовый сервер, который будет успешно принимать почту и доставлять её пользователям. Но в таком виде он будет принимать слишком много спама, но зато не будет проблем с тем, что от кого-то что-то не придет. Как ни крути, но все средства борьбы со спамом так или иначе несут накладные расходы в виде ложных срабатываний с той или иной вероятностью. Если вы решите не заморачиваться и купить Kaspersky Anti-Spam, можете этот раздел не читать. Он сам реализует все те проверки, что мы будем делать. Если же хотите своими силами бороться со спамом средствами postfix, то давайте дальше разбираться.

Я буду использовать штатные возможности postfix, позволяющие отсеять спам по тем или иным параметрам еще до получения письма. Это очень эффективный способ с точки зрения производительности. Благодаря этому правильно настроенный на отсев спама postfix часто ставят перед exchange, чтобы снизить на него нагрузку. Сразу дам ссылки на официальную документацию с описанием параметров, которые я буду использовать:

  1. smtpd_helo_restrictions
  2. smtpd_sender_restrictions
  3. smtpd_recipient_restrictions
  4. smtpd_data_restrictions
  5. smtpd_client_restrictions

Есть еще парочка — smtpd_etrn_restrictions и smtpd_end_of_data_restrictions, но я ими не пользуюсь.

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

Долго думал, как лучше всего представить информацию по этому разделу. В итоге решил просто написать часть конфига, которая отвечает за restrictions с комментариями. Более подробную информацию по каждой настройке вы можете найти в официальной документации postfix, ссылки я привел выше, либо в гугле. Данные настройки это моя многолетняя калькуляция различных параметров, собранных из черновиков и рабочих серверов. Не везде всё было настроено именно в таком виде, так как ситуации бывают разные. Сейчас я постарался всё собрать в одном месте и аккуратно описать. Те проверки в борьбе со спамом, что вам не нужны, просто закомментируйте. В конце я еще пройдусь по некоторым из них и поделюсь своим опытом.

У меня во всех ограничениях первыми правилами стоят разрешения для mynetworks и авторизовавшихся пользователей (permit_sasl_authenticated). Важно понимать, что это значит и для чего сделано. Ограничения читаются последовательно в порядке их перечисления. Таким образом, мы своих пользователей пускаем мимо ограничений, а для всех остальных выполняются проверки.

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

  • reject_invalid_helo_hostname и reject_unknown_helo_hostname — под эти правила иногда попадают почтовые серверы клиентов, которые не очень хорошо настроены. У них бывают неправильные адреса, кривые записи dns, отсутствие обратных зон и т.д. Их немного, но попадаются. Это не страшно, если вы регулярно следите за сервером. Отправитель получит сразу сообщение о том, что его письмо не дошло до вас. Если он как-то сообщит вам о проблеме, вы легко добавите его в белый список и всё будет нормально. Если вам не хочется следить за сервером, лучше не указывайте эти ограничения. Но спам они отсекают хорошо. Сюда попадают все завирусованные компьютеры и сервера без нормальных настроек dns (а их чаще всего и нет).
  • reject_unverified_sender — специально его закомментировал. Я тестировал этот параметр. В принципе, работает нормально, но есть, как обычно, нюансы. Поясню, что делает этот параметр. Когда вам кто-то шлет письмо, ваш сервер обращается к серверу отправителю и спрашивает его стандартной командой, есть ли на сервере такой отправитель. Если удаленный сервер отвечает, что есть, то никаких проблем — письмо принимается. Если удаленный сервер не отвечает или говорит, что такого адресата нет — письмо отклоняем. Очевидно, что такие проверки создают дополнительную постоянную нагрузку. Это нужно учитывать. К тому же, у вас почтовый лог постоянно будет забит этими проверками, особенно, если вам приходит много спама. На каждое спамовое письмо будет идти проверка, а сервера отправителя скорее всего либо нет, либо он неправильный, либо не отвечает и т.д. Все это будет постоянно проверяться и фиксироваться. В общем, я не использую.

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

Когда он включен, все ответы сервера с кодами ошибок 5XX, заменяются на 4ХХ. То есть постоянная ошибка, которая сразу отклоняет письмо, заменяется на временную, которая предлагает повторить отправку позже. Таким образом, вы увидите работу всех ограничений, но письма не будут отклонены навсегда. Сервер отправителя через некоторое время снова придет к вам с новой попыткой доставки почты. Письмо безвозвратно не отклоняется. Вы можете проанализировать работу фильтра и решить, ставить его на постоянную работу или с ним что-то не так.

Создадим теперь файлы с белыми и черными списками.

Ниже пример содержания этих файлов. Вы можете менять по своему усмотрению.

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

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

Ещё упомяну о таком популярном явлении в спамерских письмах, как подделка адреса отправителя. Причем не просто подделка на абы кого, а именно на ваше имя домена. Пользователь получает спам письмо и в почтовом клиенте видит, что оно отправлено с вашего домена. Только по заголовкам можно определить реального отправителя. Такой подход позволяет обходить некоторые антиспам системы, которые не фильтруют письма внутреннего домена. Бороться с подменой адреса отправителя в нашем случае очень просто. Об этом я рассказал отдельно — Запрет писем с поддельным полем From.

Приведу в завершении описания методов борьбы со спамом простой пример. Добавим в black_client почтовый адрес и отправим с него письмо.

Отправляем сообщение и проверяем почтовый лог.

Вот и результат. На этом по борьбе со спамом всё.

Заключение

Проверить настроенный почтовый сервер можно с помощью онлайн сервиса https://www.mail-tester.com. Не факт, что получите максимальный бал, но все недочеты будут указаны. Критичное нужно исправить (например, если обратная зона неправильная), некритичное можно пропустить (если dkim, к примеру, не настраивали).

Кажется всё написал, что знал по поводу почтового сервера на linux в небольших и средних организациях. У некоторых может возникнуть вопрос, а зачем свой почтовый сервер? Почему бы не воспользоваться средствами корпоративной почты, которую представляют популярные почтовые сервисы бесплатно или за деньги? У меня есть определенный опыт на этот счет, в том числе негативный. И если некоторое время назад я считал, что свои почтовые серверы в небольших организациях уже не актуальны, то сейчас я так не думаю, поэтому и появилась эта статья.

Так же вам могут быть полезны мои материалы на тему postfix:

Буду рад замечаниям по делу и советам в комментариях. Напоминаю, что данная статья является частью единого цикла статьей про сервер Debian.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *