Для чего нужен postfix
Почтовый сервер на собственном сайте с помощью postfix
В прошлый раз я рассматривал пример создания подобного сервиса на примере sendmail. Напомню, целью данного деяния создать на основе существующего сайта небольшой почтовый сервис с возможностью получения на сайте входящих сообщений для пользователей. Так как по изученным мною данным postfix является вторым по использованию агентом и используется где-то на 30% серверах, я решил изучить и его для решения данной задачи. Кроме прочего postfix имеет более широкие возможности защиты и в частности поддержку SSL/TLS, которую в sendmail я, к сожалению, так и не обнаружил. В довесок postfix позволяет напрямую обращаться к базе данных, а также поддерживает формат maildir, который насколько я помню в senfmail также отсутствует. А так как однозначного ответа на просторах интернета я, как и в прошлый раз, не нашел, думаю инструкция все-таки будет полезна.
В первую очередь необходимо прописать настройки в dns-зоне:
@ IN MX 10 mail.site.ru.
@ IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Для записи в файл нам понадобиться отредактировать все тот же /etc/postfix/main.cf
Добавим в него параметры virtual_uid_maps, virtual_gid_maps, virtual_mailbox_domains, virtual_mailbox_maps и virtual_mailbox_domains. Выглядеть все это дело будет следующим образом
Параметр virtual_uid_maps содержит идентификатор пользователя, от имени которого мы будем записывать сообщения, virtual_gid_maps делает тоже самое, но для группы. Если их несколько можно перечислить их через запятую. В директиву virtual_mailbox_base необходимо указать путь для корневого каталога всех возможных почтовых ящиков. Вдальнейшем он будет формировать примерно следующим образом virtual_mailbox_base+vmailbox и получится что-то навроде (/home)+(/)+(site.ru/public_html/mail)=/home/site.ru/public_html/mail
Далее создадим файл vhosts в папке /etc/postfix. В нем с каждой новой строчки необходимо прописать домены, с которых мы будем принимать сообщения для наших виртуальных пользователей.
Также создадим файл vmailbox, где будем прописывать инструкции для виртуальных доменов, а в параметре virtual_mailbox_maps указана ссылка на этот файл. В файле vmailbox необходимо прописать инструкции
Такая инструкция будет записывать все входящие сообщения с доменом site.ru, в файл /home/site.ru/public_html/mail. Добавим в конце слеш и получим формат Maildir.
Он будет более удобен, так как создает файл для каждого отдельного сообщения. Все новые сообщения передаются в папку /home/user/public_html/mail/new. Создаваемые файлы формируются из текущего времени, имени хоста, идентификатора процесса, создавшего этот файл, и некоторого случайного числа. Главный недостаток данной записи в отсутствии четкой номенклатуры. И разобрать где и чья почта довольно проблематично. Поэтому наиболее подходящим вариантом будет указать конкретных пользователей.
Теперь нам необходимо добавить некоторой гибкости данному процессу. Его можно добиться перенеся наших пользователей и пути с директориями для хранения сообщений в базу. В postfix для этих целей по сути существует админка PostfixAdmin, но я ставлю целью внедрить данный функционал непосредственно в сайт, поэтому она нам не понадобится. Сами базы логичнее создавать конечно непосредственно в таблице с пользователями сайта, но я покажу на примере отдельной базы.
В первую очередь нас интересует колонка `dir`, в ней необходимо прописать путь к директории с сообщениями пользователя, например site.ru/public_html/mail/user1/. Поэтому при создании пользователя нужно убедиться в наличии данной папки и при необходимости ее создать, иначе сообщениям просто негде будет сохранятся. В колонке `user` хранится логин пользователя, т.е. левая часть адреса до знака @. В колонке `domain` правая часть. В колонке `mail` адрес целиком. Из них нам нужны всего 1 или 2 колонке, но для примера я решил указать все возможные варианты.
Теперь создадим файл /etc/postfix/vmailbox.cf и пропишем в нем настройки для запроса и соединение с базой.
Специальная переменная %u будет запрашивать лишь левую часть адреса (логин пользователя) без знака @. Такой вариант будет вполне оправдан, если у Вас только один сайт, который будет принимать сообщения. В ином случае нужно будет сделать также и проверку домена
Здесь специальная переменная %d запрашивает правую часть адреса (домен) без знака @. Либо можно и вовсе хранить адрес целиком.
Соответственно переменная %s будет запрашивать весь адрес.
В файле /etc/postfix/main.cf изменим значение директивы virtual_mailbox_maps.
Если сайтов несколько, то инструкцию для каждой можно вынести в отдельный файл и перечислить через запятую
Конечно привязать к базе можно и остальные директивы, но я не вижу в этом никакой необходимости.
Перезагружаем postfix и получаем полноценный сайт с возможностью получать сообщения для пользователей.
Этот вариант в целом вполне пригодный и им даже можно пользоваться, но в общем-то далеко не безупречный. В частности отсутствует возможность сортировки, так как из имени файла, кроме даты и времени получить ничего невозможно. Чтобы получить хотя бы элементарные данные на вроде темы сообщения и отправителя, нужно открывать целый файл. Нет возможности совершить какие-либо действия при получении сообщений, что тоже немаловажно. Поэтому более гибким и удобный будет вариант с возможностью отправить сообщения непосредственно на обработку php-скрипту, который разберет почту удобным нам образом и совершим необходимые нам действия.
Убираем директивы virtual_mailbox_base, virtual_mailbox_maps, virtual_uid_maps и virtual_gid_maps. Вместо них нам теперь понадобиться директива virtual_alias_maps. В ней мы будем указывать на конкретного пользователя, которому будем переадресовывать все входящие сообщения для того или иного домена. Создадим файл, где будем прописывать инструкцию для виртуальных пользователей /etc/postfix/valias, а в нем направим всю почту для домена конкретному пользователю, от имени которого и будет работать php-скрипт, а тот уже и будет распределять ее по виртуальным пользователям нашего сайта.
Как и в случае с каталогами можно создать базу, для обработки виртуальных доменов, что позволит отбрасывать почту предназначенную для несуществующих пользователей еще на начальном этапе. Я не буду повторять пример для виртуальных пользователей, так как он аналогичен настройкам директивы virtual_mailbox_maps за тем лишь исключением, что вместо колонки `dir`, логичнее указать колонку `alias`, в которой необходимо прописывать уже не путь к директории для хранения сообщений, а имя пользователя.
В файле /etc/aliases пропишем инструкцию на файл-обработчик
И обновим карту алиансов командой newaliases, а также перезагрузим postfix.
А о том, как mail.php обработает входящий результат я планирую рассказать в следующей статье.
Для защиты от атак и вирусов можно заглянуть в HOW-TO: Настройка Amavisd-new + ClamAV + Dspam.
Почтовый сервер
Настройка почтового сервера
В наше время этим никого не удивишь, но возможно кому-то статья будет полезна
К почтовой системе предъявлялись следующие требования:
Начнем:
ось: Ubuntu 20.04.1 LTS
Шифрация файловой системы /data — Veracrypt
MTA: Postfix + postscreen + postgrey + opendkim
IMAP: Dovecot
SSL сертификаты: certbot
Доступ web: Nginx + Roundcube
Ограничения от китайцев и других «друзей» жаждущих ssh: GeoIP iptables
За перебором паролей присматривает: fail2ban
С интернета с внешнего IP адреса пробрасываются несколько TCP портов:
TCP 80 nginx для обеспечения работы certbot
TCP 443 nginx для roundcube и web доступа к почте
TCP 465 postfix для отправки почты с почтового агента на телефоне
TCP 993 dovecot для доступа почтового агента на телефоне
Информации много, свел все в разделы, в окончании раздела эта штука [END] подскажет что читаемый раздел закончился.
Базовая настройка выполняется довольно просто
В проекте использовался veracrypt, установить его на базовую ось несложно, останавливаться на этом не буду. Почтовый сервер работает на esx, при перезагрузке почтового сервера или просто при включении, базовая операционная система на почтовом сервере должна подняться, все модули ОС должны запустится, но почтовый функционал должен быть недоступен, до входа оператора (или администратора) и монтирование файловой системы с обязательным вводом пароля от файловой системы.
Два диска, один sda для системы, второй sdb для veracrypt
Создаем fdisk на sdb партицию sdb1
Создаем каталог /usr/local/veracrypt в нем создаем несколько файлов
Создаем пользователя и отключаем ему доступ через SSH, для обеспечения безопастности
Создаем сценарии монтирования раздела, перезапуска прикладной части:
Добавим в sudoers, чтоб пользователь data мог после входа, монтировать раздел и перезапускать службы
На этом настройка veracrypt вроде окончана, для примера листинг монитирования:
Как в наше время без SSL, а если быть точнее без TLS 1.1 или 1.2
Сертификат будет один, на один адрес и им будут пользоватся несколько служб:
Настроим nginx для certbot
Сертификат на 3 месяца, для обновления сертификата добавим в планировщик:
Создадим исполняемый файл /etc/letsencrypt/certbot-renew.sh
Должны появится три файла:
/etc/letsencrypt/live/mail.хххх.ru/fullchain.pem
/etc/letsencrypt/live/mail.хххх.ru/privkey.pem
/etc/letsencrypt/live/mail.хххх.ru/fullchain.pem
На этом думаю настройка certbot заканчивается
[END]
Нравится он мне в настройке, безопастный, несложный в настройке, гибкий
Проверьте у себя если нужно подправьте
smtpd_sender_login_maps = ldap:/data/etc/postfix/ad_sender_login.cf
Почтовая система при отправке письма, ищет в AD объект objectClass=user, после чего проверяет добавлен ли он в группу безопастности в AD CN=MailUserGroup,OU=Groups,OU=хххх,DC=хххх,DC=ru, далее ищет либо по доменному имени sAMAccountName=%u либо по почте mail=%s
Если находит пользователя по почте или по его доменному имени, письмо принимается к доставке, если не находит — футболит
Тест по имени пользователя в AD
Например пользователь user1 ( почта у пользователя user_email1@хххх.ru )
Тест по электронке пользователя в AD
Например пользователь user1 ( почта у пользователя user_email1@хххх.ru )
virtual_mailbox_maps = ldap:/data/etc/postfix/ad_local_recipients.cf
Почтовая система производит поиск электронной почты в AD по атрибутам mail=%s или otherMailbox=%u@%d при этом учетка пользователя не должена быть заблокирована sAMAccountType=805306368
Например пользователь user1 ( почта у пользователя user_email1@хххх.ru )
Если существует:
Если не существует почты
virtual_alias_maps = ldap:/data/etc/postfix/ad_mail_groups.cf, ldap:/data/etc/postfix/ad_virtual_alias_maps.cf
Почта которая должна доставлятся локально либо через наследования через AD группу ad_mail_groups.cf либо напрямую пользователю ad_virtual_alias_maps.cf
Например группа в AD veeam_backup в атрибутах добавлена почта veeam_backup@хххх.ru и добавлены два пользователя user1 и user2
user1 ( почта у пользователя user_email1@хххх.ru )
user2 ( почта у пользователя user_email2@хххх.ru )
Sender Policy Framework, SPF (инфраструктура политики отправителя) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208. Благодаря SPF можно проверить, не подделан ли домен отправителя.
В файле /data/etc/postfix/main.cf строка
В файле mcedit /data/etc/postfix/master.cf
Нужно убедится что файл /usr/sbin/postfix-policyd-spf-perl запускается и никаких ошибок не выдает, например так:
этого достаточно чтоб spf заработал
Postgrey хорошая штука
В файле /data/etc/postfix/main.cf строка
Postgrey настраивается очень просто:
Смотрим со стороны открытых сетевых портов:
Ну хорошо, если служба работает и порт открыт, значит postgrey будет применятся при попытке отправить сообщения на почтовый сервер.
DomainKeys Identified Mail — метод E-mail аутентификации, разработанный для обнаружения подделывания сообщений, пересылаемых по email. Метод дает возможность получателю проверить, что письмо действительно было отправлено с заявленного домена. DKIM упрощает борьбу с поддельными адресами отправителей, которые часто используются в фишинговых письмах и в почтовом спаме.
Необходимо создать TXT-записи следующего вида в DNS зоне:
Добавляем в /etc/postfix/main.cf если не добавлен:
перезапускаем postfix и opendkim:
root@mail:
# /etc/init.d/opendkim restart
root@mail:
# /etc/init.d/postfix restart
root@mail:
# echo «Test mapping» | sendmail user_email1@хххх.ru
В конфигурации main.cf, есть упоминания об
Это есть ничто иное как передача полученных и проверенных сообщений в dovecot для их сохранение в mailbox пользователя
[END]
Dovecot мы будем использовать для хранения почты пользователей и доступа по IMAPS
Конфигурации в каталоге /data/etc/dovecot/
Почтовые ящики пользователей в каталоге /data/mail/
Логи лежат тут /data/var/log/
Скопом привожу все конфигурации, для удобства
Тестирование порта IMAPS
Просмотр активных подключений
Очень удобно
Можно разрешить или запретить доступ к примеру к SSH на основании привязке к стране
Скачиваем https://github.com/mschmitt/GeoLite2xtables
Архив /data/_install/geoip/GeoLite2xtables.zip разорхивируем
Вносим свой ключ в файл
/data/_install/geoip/GeoLite2xtables-master/geolite2.license.example
Переименовываем файл geolite2.license.example в geolite2.license
Правило должно заработать:
Если что то не срослось, значит что то сделано не верно при конвертации, у меня тоже не спервого раза получилось, читал гуглил, работал напильником и наждачкой:
Конфиг nginx.conf приводил ранее, пришло время привести конфигурацию roundcube
Конструкция вида:
allow…
auth_basic «web»;
auth_basic_user_file /data/etc/nginx/webmail_htpasswd;
allow… обеспечивает доступ к web roundcube внутри компании, конечно почтовая авторизация внутри roundcube никуда не делась и это нормально.
Если обратится с публичной сети интернет на web сервер, то, до стандартного приглашения от roundcube, nginx выдаст вначале запрос с требованием auth_basic авторизации.
Если тот, кто пришел знает логин/пароль от auth_basic, он его вводит и nginx открывает доступ к roundcube, и почтовой авторизации.
Такая двойная авторизация позволяет уберечься от атак на возможные уязвимости в roundcube с интернета и задержать недоброжилателей еще на стадии auth_basic.
В файле /data/etc/nginx/webmail_htpasswd хранится одна пара логина и пароля, и наверно, как Вы дагадались эту пару знают все работающие коллеги кто обратился с вопросом, а как войти в почту со своего ноутбука или домашнего ПК. Небезопастно что один логин/пароль для auth_basic, возможно, но в тоже время авторизация auth_basic это простая учетка и простой пароль из нескольких цифр, и больше формальность, которая все же эффективно работает, а за динамикой неверного ввода логина и пароля следит fail2ban и блокирует нерадивых хацкеров кто пытается подобрать.
В тоже время никто не мешает разослать заранее всем работающим коллегам новый пароль от этой учетки и затем сменить одним движением, в период скажем раз в полгода или год.
Настроить roundcube не сложно, описывать тут как скачать архив, разложить его и настроить один конфиг не вижу смысла.
А как же пользователи заходят с телефона, просто, на Play Маркете понравился почтовый клиент TypeApp, довольно просто настроить, нет назойливой рекламы, нет неожиданностей вроде отправки почты или логинов/паролей на левые узлы.
TypeApp для входящей почты:
Почта user_email1@хххх.ru
Пароль
Сервер IMAP mail.хххх.ru
Безопастность SSL/TLS (проверка сертификата)
Аутентификация PLAIN
Порт 993
TypeApp для исходящей почты:
SMTP сервер mail.хххх.ru
Безопастность SSL/TLS (проверка сертификата)
Порт 465
Требуется авторизация — крыжик стоит
Аутентификация AUTOMATIC
Почта user_email1@хххх.ru
Пароль
Пользуемся TypeApp уже полгода вроде нормально
[END]
Не плохой получился инстанс
Работает шустро, перебор паролей к службам dovecot, nginx, postfix и ssh — fail2ban вовремя присекает + GeoIP iptables хорошее подспорье блокирует все левых желающих халявки
Postfix
Настройка
По умолчанию, Postfix пытается посылать почту в напрямую используя, запросы к DNS, в частности записи типа MX.
relay_domains | список доменов, на которые разрешена пересылка писем |
relayhost | имя и порт сервера для пересылка на него писем |
Если имя заключено в квадратные скобки [] — то Postfix не предпринимает попытку поиска записей типа MX.
Псевдонимы
Файл | Команда |
---|---|
/ etc / aliases | newaliases |
Если возникает ошибка
Нужно установить переменную:/etc/postfix/main.cf
Маскарад адресов
Замена одного домена или адреса другим, удобно использовать, если нужно скрыть внутренние домены при отправке почты на внешние адреса./etc/postfix/main.cf
Размер сообщения
Задается в Байтах, значение по умолчанию 10240000
Копирование всей почты
Отправка скрытых копий всех писем (Blind carbon copy) на определенный адрес./etc/postfix/main.cf
Команды
Работа с несколькими экземплярами
При решении некоторых задач можно воспользоваться возможностью работы с несколькими экземплярами (instance) сервера.
Для работы нужно добавить такие строки:/etc/postfix/main.cf
в переменной multi_instance_directories указывается экземпляры программы, в примере использованы следующие:
Для того, чтобы при запуске/останове и перезапуске Postfix и по команде
нужно параметре multi_instance_wrapper нужно указать имя группы ( ИМЯ _ ГРУППЫ ) в куда входя нужные экземпляров программы.
Также для того, чтобы разрешить работу с несколькими экземплярами можно использовать команду
postfix+dovecot+mysql в FreeBSD
Введение
Подготовка
Первым делом установим пакеты которые понадобятся для работы (postfix, dovecot и dovecot-pigeonhole необходимо установить из портов, dovecot-sieve можно в принципе установить из пакетов, но в портах версии бывают более новые и по этой причине может быть не совместимость dovecot с dovecot-sieve). Установим следующие пакеты:
После установки поместим необходимые службы в автозапуск:
Не забываем добавить в httpd.conf строки необходимые для работы php в apache и корректной работы postfixadmin:
Далее необходимо перейти в каталог и скачать postfixadmin
Скачаем postfixadmin (на момент написания актуальная версия была 3.2)
После этого необходимо распаковать архив в данный каталог и изменить владельца каталога:
Далее подготовим базу данных для postfixadmin, выполните скрипт mysql-secure-installation(тот пароль который Вы создадите в данном скрипте, необходимо будет создать и в mysql командой alter user), для первичной настройки mysql, далее войдите в mysql, создайте базу данных и права для неё:
После того как база данных настроена необходимо отредактировать файл config.inc.php, в данном примере этот файл находится в каталоге /usr/local/www/apache24/data/postfixadmin-3.2/, в данном файле необходимо отредактировать несколько строк и привести их к виду, после того как измените данные настройки, перезагрузите apache, также необходимо создать каталог templates_c в каталоге /usr/local/www/apache24/data/postfixadmin-3.2 и назначить на него владельца www:
Для генерации ключа будем использовать способ который предложен на сайте postfix.org, с созданием собственного центра сертификации, необходимо перейти в каталог /etc/ssl и выполнить скрипт:
Во время выполнения скрипта будет запрошено имя для сертификата, не чего не вводите, нажмите Enter, далее скрипт запросит создать пароль для сертификата, далее будут стандартные вопросы для создания сертификата.
Далее необходимо создать секретный ключ(без пароля) и не подписанный сертификат открытого ключа(Organizational Unit Name (eg, section) [] должен отличаться от того, что указан в сертификате созданном выше):
Подпишем сертификат открытого ключа(количество дней укажите столько, сколько вам необходимо):
Созданные сертификаты оставьте в данном каталоге, или перенесите их в тот каталог который Вам более удобен, «конфиги» postfix и dovecote будут настроены с учётом того, что сертификаты будут находиться в данном каталоге.
Пользователь vmail
Перед тем как приступить к установке postfix, dovecot и dovecot-pigeonhole, создадим пользователя и группу(группа создаться автоматически) vmail, а также каталог в котором будет располагаться почта.
Создадим каталог для почты и назначим владельцем пользователя vmail:
Postfix, dovecot, dovecot-pigeonhole
Как я писал ранее сборку данных приложений произведём из портов, выполните команду для скачивания и распаковки портов:
После распаковки портов перейдите в каталог dovecot, выполните настройку порта (необходимо отметить поддержку mysql) и запустите сборку(BATCH=yes укажет make не задавать вопросы при установке):
Те же действия проделать с postfix и dovecot-pigeonhole
postfix: также отметьте в настройке порта поддержку mysql
Перед запуском dovecot скопируйте «конфиги»:
После установки postfix и dovecot запустите службы:
Также необходимо создать каталог в котором будет компилироваться модуль для пересылки спама в папку спам, в моём случаи данный каталог находиться в папке /usr/local/etc/dovecot/conf.d, имя каталога def, создадим данный каталог и файл с кодом для компиляции и установим владельцем данного каталога пользователя vmail:
В данный файл поместите строки:
«Конфиги»
В данном разделе приведу примеры «конфигов» с комментариями в них, сомневаюсь только в «конфиге» spamassassin, так как корректных описаний в сети не нашёл(оставил «конфиг» по умолчанию), просьба дополнить в комментариях как лучше настроить spamassassin.
Postfix
Первым делом необходимо создать файлы для вытаскивания пользователей, доменов, квот из базы данных. Создайте каталог для хранения данных файлов и необходимые файлы:
Я построю свой почтовый сервер с Postfix и Dovecot
В рамках программы по унификации установленных серверных систем встала задача по переделке почтового сервера. Вдумчивое изучение мануалов и руководств показало довольно любопытный факт – нигде не было найдено однозначно достоверного руководства или подобия Best Practice по развёртыванию почтовика.
Мануал пошаговый, основывается на внутренней документации компании и затрагивает совершенно очевидные вопросы. Гуру могут не тратить время, ноу-хау здесь нет – руководство является сборной солянкой и публикуется только потому, что все найденные руководства по развёртыванию почтовика напоминали картинку о том, как рисовать сову.
Для тех, кто не хочет собирать всё вручную, оптимальным вариантом, пожалуй, будет пакет iRedMail. Отличная сборка Postfix, Dovecot, Apache, MySQL/PostgreSQL, Policyd, Amavis, Fail2ban, Roundcube и даже Awstats. Ставится легко, работает стабильно, есть красивая админка (бесплатная) и очень красивая админка (платная) не идущая ни в какое сравнение с убогим PostfixAdmin. Поклонники же ручного труда могут продолжить чтение.
Старый сервер работал под Gentoo и нёс в себе термоядерный заряд из Postfix+VDA с Courier и глючно реализованного SASL, решавшим подключаться к mysql только при первой аутентификации. План переделки заключался в миграции на наш внутренний стандарт – CentOS. Роль MTA и MDA возлагается на связку Postfix и Dovecot, а в качестве вспомогательной артиллерии: Amavis + SpamAssassin + ClamAV + Postgrey + Fail2Ban. Письма хранятся в файлах, а учётные записи и домены — в MySQL. На сервере крутится несколько почтовых доменов и есть поддержка виртуальных квот.
[*] Подключаем дополнительные репозитории. Мне хватило epel, rpmforge, centalt и remi. Не все они нужны постоянно включёнными, и можно установить плагин yum-priorities; ну или если лень разбираться, то включать-отключать их руками. Далее я буду говорить, что из какого репозитория устанавливается.
[*] Работа с SELinux достойна отдельного материала, поэтому в рамках данной статьи примем, что selinux по-ламерски сделан permissive или disabled.
[*] В завершение подготовительного этапа ставим утилиты, которые облегчат нам тестирование и дальнейшую работу:
Для нашей базы данных используем MySQL 5.5 от Remi. Можно и mariadb, конечно, но пока MySQL ещё жив, вышеупомянутая сборка меня полностью устраивает. Версия важна, т.к. при обновлении Postfix до 2.10 он захочет новую версию и если поставить 5.1 из base, то обновление постфикса из CentALT потянет за собой MariaDB. Кому больше нравится PgSQL — пожалуйста, ставьте его. Развёртывание ничем отличаться не будет, даже конфигурационные файлы postfix можно будет брать неизменными. Отличаться будет только настройка самого postgresql и создание базы.
Для запуска подойдёт вариант «из коробки» (в репозитории ниже представлен слегка расширенный my.cnf). Создаём пользователя postfix с одноимённой базой и всеми правами на неё.
Антивирусом у меня работает ClamAV. Стоит отметить, что самая последняя версия есть на CentALT, однако она в упор не хочет оттуда скачиваться, умирая на попытке скачать 50 мегабайт clamav-db. Поэтому ставим из EPEL на пару минорных версий меньше, погоды это не сделает. Clam будет работать у нас через сокет, поэтому в /etc/clamd.conf комментируем строки:
Обновление баз антивируса подключается автоматически, за него отвечает утилита freshclam. Проконтролируем, чтобы соответствующий файл находился в cron.daily и запускаем сервис антивируса
Развёртывать или не развёртывать веб-интерфейс — личное дело каждого. Мне он понадобился для контроля процесса миграции. Вам он может понадобиться для создания структуры базы и администрирования доменов, ящиков, алиасов и т.п. Для последних задач в большинстве руководств активно предлагается PostfixAdmin, но мне он категорически не нравится. Равно как я бы рекомендовал придерживаться принципа разделения, по которому почтовый сервер должен заниматься обработкой почты, веб-сервер держать веб-приложения, а DB-сервер работать с базами данных.
Для тех, кто не захочет развёртывать веб-подсистему, прилагаю SQL-дамп базы данных для почтового сервера на все случаи жизни. Даже с некоторыми неиспользуемыми возможностями: mysql_dump.sql на гитхабе.
Если же потребуется PostfixAdmin — ставьте nginx/apache + php и собственно сам PostfixAdmin. И обратите внимание, что развернуть его поверх приведённого дампа не удастся — из структуры удалены некоторые «лишние» таблицы. Нюансов настройки PostfixAdmin немного. Редактируем config.inc.php, обращая внимание на следующие параметры:
После этого можно идти на domain.tld/postfixadmin/setup.php, генерировать пароль и создавать учётную запись супер-администратора. Теперь сгенерированный хэш надо внести в файл config.inc.php и изменить его статус:
[!] Postfixadmin сам создаёт структуру базы и в mysql, и в postgresql при запуске setup.php. Если намереваетесь использовать его, установку следует проводить на пустую базу.
Проконтролируем, что в базе postfix создана вся дефолтная структура и перейдём к установке MTA и MDA. Postfix уже идёт в комплекте с CentOS, но не самый новый. Обновим его из CentALT и оттуда же поставим Dovecot.
Все основные системы корабля будут оперировать с файлами в /var/vmail под отдельным юзверем:
Сделаем самоподписанные SSL’ки
Самый противный этап сборки – убедить Postfix работать с базой данных:
В этой директории создаём файлы со следующим содержанием:
Редактируем файл /etc/postfix/main.cf, обучая Postfix работать с базой по свежесозданным файлам:
Хороший почтовый сервер пропускает своих и авторизует чужих. Чтобы аутентификация работала корректно, запустим Submission, подняв SMTP сервис дополнительно на 587 порту. Смартфоны при создании новых учётных записей при вписывании smtp сервера с аутентификацией по умолчанию предлагают 587 порт; вы же не хотите объяснять клиентам, что недостаточно вписать mail.domain.tld, а ещё надо и порты какие-то прописывать. В общем, в /etc/postfix/master.cf редактируем секцию, отвечающую за submission:
[!] Обязательно обращаем внимание на пробелы перед -o ключами — без них конфиг не будет валидным.
Пока отложим в сторону master.cf, к нему мы вернёмся позднее, и продолжим с /etc/postfix/main.cf
Это были изменения строк по умолчанию. А теперь добавим несколько секций наших настроек. Проверьте на дубликаты, убирая их из родной конфигурации, если они там встречаются. Я предлагаю свои настройки вписывать структурированными блоками в нижней части файла /etc/postfix/main.cf:
[!] Использовать или не использовать чёрные списки — ваш выбор. Я закомментировал соответствующие директивы reject_rbl_client, чтобы не плодить холивары. Грейлистинга зачастую хватает, а Spamhaus и иже с ним исповедуют неоднозначную политику, но на практике оказалось, что «честных ребят», в чёрные списки просто так не заносит и ложных срабатываний у нас не было. Повезло, наверное. Поэтому — дело вкуса включать директивы RBL или нет. Считайте, что я их указал в информационных целях.
[!] Параметры разбиты по группам — внимательно пересмотрите их и подстройте под собственные нужды. Хуже нет варианта, чем вслепую влепить чужой конфиг без правок.
[!] Malamut справедливо заметил, что опция `permit_mynetworks` крайне сомнительна и опасна. Гораздо лучше будет её убрать и разрешать отправку корреспонденции только пользователям, прошедшим аутентификацию.
[!] К файлу main.cf мы снова вернёмся, добавляя в него postgrey, amavis и dovecot, а пока перейдем к MDA
Пара изменений в /etc/dovecot/dovecot.conf:
Остальная часть конфигурационного файла удобно разбита на составляющие и прекрасно документирована:
Теперь подружим Postfix с Dovecot. Добавим две секции в /etc/postfix/main.cf:
И поставим Postfix перед фактом, что доставкой почты занимается dovecot. В /etc/postfix/master.cf:
Далее необходимо проконтролировать, чтобы скрипт предупреждения о превышении квоты /usr/local/bin/quota-warning.sh отрабатывал корректно. В моём случае в CentOS путь в нём был указан неверно и пришлось править его вручную. Его в любом случае, кстати, поправить вручную, отредактировав адрес отправителя, который по умолчанию указан, как postmaster@domain.tld. Найдём искомый бинарник
И поправим путь в самом /usr/local/bin/quota-warning.sh, при желании добавляя в скрипт более содержательные заголовки.
Поскольку у нас будет работать Amavis, который является прослойкой между почтовыми агентами и антивирусно-антиспамовыми системами, то запускать spamd отдельно не нужно – он работает как модуль, подгружающийся при необходимости. Чтобы SA держать обновлённым, используется родная утилита sa-update. Убедимся, что в etc/cron.d есть файлик sa-update с запланированным запуском апдейтера.
[!] Ставьте spamassassin 3.3.2 из rpmforge-extras, т.к. втыкающаяся из EPEL версия 3.3.1 имеет врождённый дефект в sa-update. Последняя версия 3.3.2 уже избавлена от этой проблемы и обновляется корректно
Немного подкорректируем /etc/mail/spamassassin/local.cf
и в /etc/postfix/main.cf добавляем
Об эффективности грейлистинга писалось уже не раз, поэтому просто молча
Никакой дополнительной конфигурации не требуется — прописываем его в /etc/postfix/main.cf
[!] Директива check_policy_service должна обязательно идти после reject_unauth_destination.
Если есть необходимость исключить из проверки какие-либо сервера — редактируем /etc/postfix/postgrey_whitelist_clients.local, а для исключения из проверки конкретные почтовые адреса на локальном сервере — редактируем postgrey_whitelist_recipients. Исчерпывающая информация доступна в вики: wiki.centos.org/HowTos/postgrey
Про Fail2ban разговор отдельный. Чтобы продемонстрировать его эффективность, покажу картинку со статистикой почтового сервера до и после установки утилиты. Красная линия на графике – неавторизованная долбёжка в поисках открытого релея. Письма, конечно, отсекаются, да и нагрузку большую не создают, но зачем вообще слушать этот мусор. Поэтому установка fail2ban с тремя правилами значительно улучшают внешний вид графика:
Если SSH открыт только на внутреннюю сеть, то первое правило можно и убрать. И всё, никаких дополнительных телодвижений – правила работают «из коробки». Спасибо urbain за напоминание о защите от перебора smtp.
Поскольку в Dovecot мы подключили плагин autocreate, то для создания доменов и почтовых ящиков достаточно завести их в базу через Postfixadmin или делая INSERT INTO в консоли. При первой же аутентификации или первом полученном письме структура директорий будет создана автоматически.
Информацию по обработке можно читать в логах (по умолчанию /var/log/maillog). Чтобы увидеть больше информации, поднимите уровень verbose в /etc/dovecot/conf.d/10-logging.conf и log-level в /etc/amavisd/amavisd.conf.
Теперь питание компьютера можно отключить можно начинать работать с почтовым сервером, создавать домены, пользователей, алиасы и т.п. Напоследок несколько общих моментов и рекомендаций:
Ещё раз подчеркну, что это начальный этап установки. Даже если не считать подключение мониторинга, который крайне желателен на почтовом сервере, работы ещё непочатый край. Однозначно потребуется тщательная настройка антиспам политики; если планируется использовать дополнительные релеи, то потребуется доработка запросов; обязательно будет нужно выверять параметры ограничений и т.п.
Но в остальном на этом пробу пера в написании масштабного руководства можно считать завершённой. В планах есть публикация материала уже не для «начинающих» и не по почтовому серверу, но я решил потренироваться на кошках. Кто дочитал до этого места… гм… завидую вашему терпению, но разбивать публикацию на несколько частей представлялось нецелесообразным.