Linux почтовый сервер postfix

Настройка почтового сервера SMTP Postfix для локальной отправки email сообщений в Ubuntu и Debian Linux

В этой статье мы рассмотрим установку почтового сервера Postfix в дистрибутиве Ubuntu или Debian Linux. Если вы используете CentOS, воспользуйтесь руководством для этой ОС. Эта настройка позволит вам отправлять email сообщения из ваших локальных приложений, размещенных на сервере без использования авторизации.

Подразумеваем, что у вас уже установлен сервер с операционной системой Ubuntu, Debian или подобной им. Инструкция демонстрирует базовую настройку почтового сервера Postfix без использования баз данных.

Обновление кэша пакетов

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

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

Установка и настройка почтового агента Postfix

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

Во время автоматической настройки пакета Postfix выберите пункт «Интернет-сайт«:

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

После установки проверьте статус демона Postfix, для этого введите команду:

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

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

Если у вас не работает команда nano, установите редактор командой apt-get install nano или воспользуйтесь другим редактором.

В конфигурационном файле main.cf найдите строку:

Измените значение inet_interfaces на localhost

Параметр inet_interfaces указывает на каких сетевых интерфейсах postfix должен ожидать соединений. По умолчанию MTA Postfix слушает на всех активных сетевых интерфейсах. Вы можете переопределить значение inet_interfaces , указав IP адрес (либо доменное имя) нужного сетевого интерфейса.

*MTA — агент пересылки электронной почты (сервер электронной почты)

Внимание: при настройках из данной статьи не рекомендуется указывать значением ваш внешний IP адрес в inet_interfaces. Иначе ваш почтовый сервер может быть использован для массовой рассылки злоумышленниками.

Далее найдите следующие строки:

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

На этом редактирование файла конфигурации Postfix завершено. Сохраните файл main.cf. Теперь необходимо перезапустить сервер Postfix:

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

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

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

Проверим работу почтового сервера командой в консоли:

Вместо info@mail.ru укажите рабочий электронный адрес, на котором вы можете проверить почту.

Настройка переадресации с локального ящика сервера на внешний ящик

Переадресация настраивается с помощью файла /etc/aliases. Рассмотрим создания правила для переадресации локальной почты для root на внешний почтовый ящик. Откройте файл /etc/aliases для редактирования:

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

Внесите в файл дополнительную строку для настройки переадресации:

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

Теперь сообщения направленные пользователю root будут отправляться на указанный e-mail. При настроенной локальной отправке вы должны внимательно отслеживать активность вредоносных приложений, которые пытаются взломать вашу систему. Как только это произойдет, ваш хост начнет участвовать в спам-сети и скоро попадет в черные списки серверов, рассылающих спам, а ваши пользователи перестанут получать почтовые сообщения от вас.

Для повышения безопасности вашего почтового сервера читайте наше руководство по дальнейшей настройке Postfix для защиты от несанкционированного использования.

Все больше сайтов отказываются от локальной отправки почты в пользу использования сервисов надежной доставки почтовых сообщений, которые предоставляют ведущие почтовые системы — Yandex, Mail.RU, Google. Это не только гарантирует доставку почты, но и уменьшает шанс сервера попасть в черные списки сайтов, рассылающих спам.

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

Предпочитаете сервисы Yandex? Тогда читайте соответствующее руководство для подключения своего домена к инфраструктуре Yandex.

Источник

Я построю свой почтовый сервер с 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.

Это позволит избежать возможной проблемы Dovecot’a «Time has moved backwards». Также можно в /etc/sysconfig/ntpd изменить ключ на -L, чтобы ntpd не слушал сеть.

[*] В завершение подготовительного этапа ставим утилиты, которые облегчат нам тестирование и дальнейшую работу:

Для нашей базы данных используем 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

Что это такое:

• Это наш Mail Delivery Agent, локальный транспорт
• Собственный SASL, через который будет работать Postfix
• Работа с квотами
• Предоставление пользователю imap и pop3

Пара изменений в /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

А вот конфигурационный файл Amavis‘а — полная противоположность расхваливаемым мною конфигам Dovecot. Он представляет собой обычный perl скрипт, который к тому же ещё и плохо форматирован. Я вношу изменения просто — переименовываю файл в .pl и редактирую с подсветкой синтаксиса; это хоть немного облегчает жизнь.

и в /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 в консоли. При первой же аутентификации или первом полученном письме структура директорий будет создана автоматически.

Тестируем логин IMAP

Тестируем SMTP без авторизации

Тестируем SMTP c авторизацией без SSL
Предварительно закодируйте в base64 тестовые логин и пароль, которые посылаются последовательно после AUTH LOGIN. Входящие требования с кодом 334 тоже закодированы в base64.

Тестируем SMTP c SSL

1. В комплекте с amavis идут вирусы и спам. Тестовые, разумеется. И чтобы сканеры не паниковали, они лежат запакованные. Поэтому перед дальнейшими тестами распакуем эту радость:

Теперь можно тестировать отправку вирусов и спама:

Информацию по обработке можно читать в логах (по умолчанию /var/log/maillog). Чтобы увидеть больше информации, поднимите уровень verbose в /etc/dovecot/conf.d/10-logging.conf и log-level в /etc/amavisd/amavisd.conf.

Теперь питание компьютера можно отключить можно начинать работать с почтовым сервером, создавать домены, пользователей, алиасы и т.п. Напоследок несколько общих моментов и рекомендаций:

1. Для работы с конфигурационными файлами я использую git, превратив директорию /etc в репозиторий. Такой подход позволяет удобно шарить конфиги между сотрудниками техотдела и пошагово контролировать процесс настройки. В работе с такой комплексной системой, как почтовый сервер, подобная практика может сильно облегчить жизнь.
2. Одной из моих задач была миграция c courier на dovecot. И да, это реально. Официальная документация wiki2.dovecot.org/Migration/Courier даёт почти всю необходимую информацию. В дополнение к ней порекомендую вручную выполнить POP3 команду UIDL на старом и новом сервере под одним и тем же пользователем с непустым почтовым ящиком, сравнивая результаты. Они должны быть одинаковыми, иначе почтовый клиент пользователя скачает всю почту из ящика заново.
   Также можно по окончании миграции на новом сервере удалить ненужные папки и файлы
3. Не забудьте про iptables — откройте только нужные порты и скройте от любопытных глаз служебные.
4. Идущий в комплекте с CentOS логгер rsyslog мне никогда не нравился, и я его меняю на syslog-ng из EPEL. Кстати, при непосредственном участии syslog-ng рисуется график из шестой главы — сбор и запись статистики ведётся путём парсинга логов.
5. Таблица vacation создаётся, но в dovecot не поставлен плагин Sieve и «автоответчика» нет. Поэтому таблица — просто задел «на будущее». Гайд и так гигантский получился.

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

Ещё раз подчеркну, что это начальный этап установки. Даже если не считать подключение мониторинга, который крайне желателен на почтовом сервере, работы ещё непочатый край. Однозначно потребуется тщательная настройка антиспам политики; если планируется использовать дополнительные релеи, то потребуется доработка запросов; обязательно будет нужно выверять параметры ограничений и т.п.

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

Источник