Exim vs Postfix vs OpenSMTPD в 2026: какой MTA выбрать для VDS

Выбор MTA для VDS в 2026 году выглядит проще, чем десять лет назад: крупных игроков немного, документации много, готовых связок с Dovecot, Rspamd, OpenDKIM и веб-панелями тоже хватает. Но на практике именно почтовый транспорт часто становится самым чувствительным компонентом: ошибка в правилах relay превращает сервер в источник спама, слишком строгий фильтр режет легитимные письма, а неудачная настройка очереди маскирует проблемы с DNS, TLS или репутацией IP.

В этой статье сравним Exim, Postfix и OpenSMTPD не как абстрактные проекты, а как рабочие MTA для администратора VDS. Нас интересуют эксплуатация, безопасность, предсказуемость, удобство диагностики и жизнеспособность решения в 2026 году. Это не инструкция по установке почтового сервера с нуля, а практичный обзор, который помогает выбрать основу до того, как вы начнёте писать конфиги и переносить домены.

MTA отвечает за приём, маршрутизацию, постановку в очередь и передачу сообщений по SMTP. Он не заменяет IMAP-сервер, антиспам, DKIM-подпись, DNS-гигиену и мониторинг, но именно через него проходит вся транспортная логика доставки.

Короткий вывод: кому что выбирать

Если нужен универсальный, хорошо документированный и предсказуемый MTA для большинства VDS-задач, в 2026 году чаще всего разумно начинать с Postfix. Он хорошо разделяет компоненты, аккуратно масштабируется, понятен в диагностике и стал фактическим стандартом для самосборных почтовых серверов на Linux.

Exim стоит выбирать, когда нужна гибкая маршрутизация и сложная логика обработки письма прямо на уровне MTA: много доменов, нетиповые маршруты, условная доставка, кастомные ACL, особые правила для разных групп отправителей и получателей. Он силён там, где почтовая политика меняется не только параметрами, но и сценариями.

OpenSMTPD хорош для минималистичных и понятных конфигураций: простой outbound relay, небольшой почтовый шлюз, аккуратный SMTP-сервис без тяжёлой комбинаторики. Особенно он близок администраторам, которым нравится подход OpenBSD: меньше сущностей, меньше магии, конфиг читается почти как правило на естественном языке. Но для больших Linux-инсталляций вокруг него меньше готовой эксплуатационной практики, чем вокруг Postfix.

Что сравниваем: не только скорость SMTP

Производительность MTA сама по себе редко является главным узким местом на небольшой или средней VDS. Чаще доставка упирается в репутацию IP, обратную DNS-запись, лимиты внешних получателей, задержки greylisting, работу антиспама, дисковую подсистему очереди и качество логов. Поэтому вопрос Exim vs Postfix vs OpenSMTPD лучше задавать шире: какой MTA проще безопасно держать в продакшене.

Для администратора важны несколько практических критериев. Первый — модель безопасности: как MTA изолирует процессы, какие компоненты имеют привилегии, насколько легко избежать открытого relay. Второй — конфигурационная модель: можно ли понять поведение сервера через полгода после настройки. Третий — очереди: удобно ли смотреть, замораживать, удалять, повторять и объяснять задержки доставки. Четвёртый — интеграции: SMTP AUTH, Dovecot SASL, LMTP, milters, Rspamd, DKIM, TLS-политики, backup MX. Пятый — комьюнити и документация: когда ночью в логах появляется странный статус, стандартность решения экономит часы.

Ещё один критерий для VDS — ресурсы. Почтовый сервер не обязан быть прожорливым, но антиспам, антивирусная проверка, веб-почта, IMAP-индексация и логи быстро меняют картину. Сам MTA обычно потребляет мало CPU и RAM, однако плохая конфигурация очереди или бесконтрольный приём писем может нагрузить диск и сеть сильнее, чем веб-сайт с умеренным трафиком.

Postfix: практичный стандарт для VDS

Postfix проектировался как безопасная и более управляемая альтернатива классическим MTA. Его сильная сторона — модульная архитектура: разные задачи выполняют отдельные процессы, а конфигурация разделена между main.cf и master.cf. Это снижает когнитивную нагрузку: администратор видит, где общие параметры, а где сервисы вроде smtpd, submission, pickup или smtp.

На VDS Postfix удобен тем, что под него есть много проверенных рецептов. Нужно принимать почту для домена и отдавать в Dovecot по LMTP — типовой сценарий. Нужно отправлять через smarthost — типовой сценарий. Нужен submission на 587 порту с SMTP AUTH и обязательным TLS — снова типовой сценарий. Нужно подключить Rspamd через milter-интерфейс — документации и примеров достаточно.

Сильные стороны Postfix

• Предсказуемая архитектура и хорошие значения по умолчанию. Postfix не пытается быть языком программирования внутри MTA, поэтому его проще ревьюить.
• Широкая совместимость с Debian, Ubuntu, AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora: везде это обычный пакет без экзотики.
• Хорошая эксплуатационная диагностика: очереди, логи, коды отказов и поведение postscreen понятны большинству почтовых администраторов.
• Удобная гранулярность ограничений: smtpd_recipient_restrictions, smtpd_relay_restrictions, rate limits, ограничения на получателей и отправителей.
• Нормальная база для роста: от одного домена до нескольких десятков или сотен доменов при грамотном разделении ролей.

Слабые места Postfix

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

Вторая особенность — Postfix не является антиспамом. У него есть postscreen, проверки DNSBL, ограничения SMTP-диалога и интеграции, но полноценная фильтрация обычно выносится в Rspamd или аналогичный компонент. Это правильно архитектурно, но нужно учитывать при планировании ресурсов VDS.

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

Exim: максимальная гибкость и высокая ответственность

Exim исторически силён в сценариях, где почтовая маршрутизация требует нетривиальной логики. Его конфигурация строится вокруг ACL, routers, transports, authenticators и retry-правил. В руках опытного администратора это очень мощный инструмент: можно тонко управлять приёмом, проверками, маршрутизацией, локальной доставкой, условиями для разных доменов и нестандартными политиками.

На практике Exim часто встречается в хостинговой среде и в панелях управления, где нужно обслуживать множество доменов и пользователей. Там его гибкость полезна: можно описывать сложные правила, учитывать локальные алиасы, маршруты, лимиты, разные backends и особенности клиентских доменов. Но именно эта гибкость повышает цену ошибки.

Сильные стороны Exim

• Очень гибкая логика обработки писем: решения можно принимать на основании множества условий, а не только статических карт.
• Хорошая пригодность для сложного виртуального хостинга и кастомных политик доставки.
• Детальная настройка ACL на этапах SMTP-диалога: можно проверять отправителя, получателя, HELO, IP, заголовки и результаты внешних проверок.
• Зрелость проекта и большая история эксплуатации. Многие нестандартные задачи уже кем-то решались.

Слабые места Exim

Главная претензия к Exim — сложность сопровождения. Конфиг может быть великолепно написан, а может превратиться в набор условий, в котором страшно менять одну строку. Для одного администратора это нормально, для команды без общей дисциплины — риск.

Второй момент — безопасность. У Exim богатая поверхность возможностей, а значит, нужно внимательно следить за обновлениями и не откладывать патчи. Это не повод избегать Exim, но повод закладывать регламент: обновления, тестовый прогон конфигов, резервная копия перед изменениями, мониторинг очереди и алерты на всплески отказов.

Exim хорош, когда вы заранее понимаете, зачем нужна его гибкость. Если задача простая — один домен, IMAP, SMTP AUTH, DKIM, DMARC и обычная доставка — Postfix почти всегда будет проще. Если же вам нужно строить почтовую логику с большим количеством условий, Exim может оказаться удобнее, чем попытка имитировать эти условия в Postfix через множество карт и сервисов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

OpenSMTPD: минимализм, читаемость и аккуратные границы

OpenSMTPD пришёл из мира OpenBSD, и это заметно по философии. Конфигурация стремится быть читаемой: есть действия, правила match, таблицы, relay, локальная доставка. Для небольших задач это приятно: файл smtpd.conf можно открыть и быстро понять, что сервер принимает, куда доставляет и кому разрешает отправку.

На VDS OpenSMTPD особенно интересен в двух сценариях. Первый — лёгкий outbound MTA для системных уведомлений, приложений и небольших внутренних сервисов. Второй — небольшой аккуратный почтовый шлюз, где не требуется гигантская экосистема расширений. Он не пытается конкурировать с Postfix по количеству интеграционных рецептов и с Exim по глубине условной логики, но выигрывает в простоте.

Сильные стороны OpenSMTPD

• Очень читаемая конфигурация для простых и средних сценариев.
• Минималистичная модель, в которой меньше соблазна добавить слишком много логики прямо в MTA.
• Хорошее соответствие задачам небольшого relay, системной отправки и компактного почтового шлюза.
• Аккуратная философия безопасности, унаследованная от OpenBSD-подхода.

Слабые места OpenSMTPD

Главный минус — меньшая распространённость в Linux-продакшене по сравнению с Postfix и Exim. Это влияет не только на количество статей, но и на готовность соседних компонентов. Если вы собираете стек с Dovecot, Rspamd, webmail, панелью управления, множеством виртуальных доменов и нестандартной маршрутизацией, то Postfix или Exim обычно дадут более протоптанную дорогу.

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

Безопасность: где легче не ошибиться

Для публичного SMTP-сервера безопасность начинается не с выбора MTA, а с запрета открытого relay. Сервер должен принимать почту для своих доменов и разрешать исходящую отправку только авторизованным пользователям, доверенным сетям или приложениям. Любой MTA из тройки Exim, Postfix, OpenSMTPD можно настроить безопасно, но вероятность ошибки различается.

Postfix обычно проще защитить за счёт понятных default-паттернов и большого количества проверенных конфигураций. В нём важно не смешивать роль входящего MX и authenticated submission: порт 25 живёт по правилам межсерверного SMTP, порт 587 — по правилам клиентской отправки с авторизацией и TLS.

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

OpenSMTPD выигрывает читаемостью. Если конфигурация небольшая, аудит занимает мало времени. Но администратору всё равно нужно понимать SMTP-модель: где приём для локальных доменов, где relay наружу, где авторизация, где TLS и какие таблицы считаются доверенными.

В 2026 году безопасный MTA — это не самый модный MTA, а тот, чью конфигурацию вы можете объяснить, проверить после обновления и быстро диагностировать по логам.

Доставляемость: MTA важен, но не всемогущ

Многие проблемы доставки ошибочно списывают на Exim, Postfix или OpenSMTPD, хотя причина лежит за пределами MTA. Внешние почтовые системы смотрят на репутацию IP, наличие корректного PTR, соответствие HELO, SPF, DKIM, DMARC, TLS, историю жалоб, частоту отправки, качество списков получателей и поведение при ошибках. MTA выполняет транспортную часть, но не делает плохую почтовую практику хорошей.

Для VDS это особенно важно. Новый IP-адрес может не иметь устойчивой репутации, а резкий старт массовой рассылки ухудшит положение независимо от выбранного MTA. Если сервер нужен для транзакционной почты сайта, уведомлений панели, заявок, счетов и служебных сообщений, настройте умеренные лимиты, корректные bounce-адреса, отдельный домен или поддомен для отправки и мониторинг отказов. Если почтового домена ещё нет, заранее проверьте доступные зоны и стоимость через регистрацию доменов.

Postfix удобен для контроля исходящих потоков: можно задавать лимиты, транспорты, relayhost, отдельные правила для доменов-получателей. Exim позволяет делать ещё более тонкие политики, включая условия на уровне ACL и маршрутов. OpenSMTPD достаточен, если политика простая и нет задачи строить сложную систему отправки.

Очередь и диагностика: что будет в день инцидента

Почтовый инцидент редко выглядит красиво. В очереди растут тысячи сообщений, пользователи жалуются на задержки, внешние серверы возвращают 4xx или 5xx, антиспам начинает тормозить, а в логах перемешиваются временные ошибки DNS, TLS и greylisting. В такой момент важны не теоретические преимущества MTA, а то, насколько быстро администратор поймёт, что происходит.

Postfix в этом смысле очень удобен. Его очередь и журналы хорошо знакомы большинству администраторов, а типовые действия понятны: посмотреть размер очереди, отделить deferred от active, проверить конкретное сообщение, выяснить домен-получатель, увидеть причину задержки. Формат логов достаточно регулярный, его удобно отдавать в централизованное логирование.

Exim тоже даёт мощные инструменты диагностики, но требует знания своей терминологии. Если команда привыкла к Exim, инциденты разбираются быстро. Если Exim достался в наследство без документации, входной порог выше: нужно понимать, какие routers и transports применились, почему сработал конкретный ACL, где сообщение заморожено и что делать с retry-правилами.

OpenSMTPD в небольших сценариях выигрывает простотой: меньше компонентов — меньше мест, где искать. Но в крупной среде может не хватать привычного багажа коллективного опыта. Если у вас сменная команда или внешняя поддержка, распространённость Postfix иногда становится самостоятельным преимуществом.

Мини-шпаргалка по очередям

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

# Postfix
postqueue -p
mailq
postconf -n
postsuper -r ALL
postsuper -d QUEUE_ID
journalctl -u postfix --since "1 hour ago"

# Exim
exim -bp
exim -Mvh MESSAGE_ID
exim -Mvl MESSAGE_ID
exim -Mrm MESSAGE_ID
exim -qff
journalctl -u exim --since "1 hour ago"

# OpenSMTPD
smtpctl show queue
smtpctl show message MESSAGE_ID
smtpctl remove MESSAGE_ID
smtpctl schedule all
journalctl -u opensmtpd --since "1 hour ago"

На Debian и Ubuntu почтовые события часто дополнительно попадают в /var/log/mail.log, а на RHEL-based системах — в /var/log/maillog, если используется rsyslog. В системах с journald полезно сразу смотреть конкретный unit через journalctl, чтобы не смешивать MTA, Dovecot, Rspamd и системные сообщения.

Интеграции: Dovecot, Rspamd, DKIM и панели

Современный почтовый сервер редко состоит только из MTA. Обычно рядом живут Dovecot для IMAP и LMTP, Rspamd для антиспама и DKIM, веб-почта, TLS-сертификаты, DNS-записи SPF и DMARC, fail2ban или другой механизм реакции на перебор паролей, мониторинг и резервные копии.

Postfix здесь наиболее предсказуем: большинство популярных связок сначала документируют именно для него. Dovecot SASL, LMTP-доставка, Rspamd milter, OpenDKIM, транспортные карты, виртуальные mailbox-домены — всё это имеет множество примеров. Если планируете защищать SMTP AUTH и IMAP от перебора паролей, пригодится отдельная инструкция по jail для Postfix и Dovecot в fail2ban.

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

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

Отдельный современный вопрос — международные адреса и SMTPUTF8/EAI. Если у вас есть пользователи или клиенты с нелатинскими адресами, не ограничивайтесь выбором MTA: проверьте поддержку во всём стеке, включая Dovecot, веб-почту, приложения и внешние шлюзы. Подробнее эту тему удобно разбирать на примере Postfix, Dovecot и SMTPUTF8/EAI.

Ресурсы VDS: сколько нужно CPU, RAM и диска

Сам MTA обычно не требует много ресурсов. Для небольшого домена с умеренным трафиком важнее стабильный диск, достаточный запас под очередь и логи, корректное время на сервере и нормальная сеть. Но как только вы добавляете антиспам, IMAP-индексы и веб-почту, минимальная VDS быстро становится тесной.

Для аккуратного личного или корпоративного домена с небольшим количеством ящиков можно начинать с умеренного количества RAM, но обязательно оставлять запас. Rspamd, Redis, Dovecot и веб-почта потребляют больше памяти, чем кажется в момент установки. Если планируются вложения, активный IMAP, индексация поиска и хранение почты на сервере, диск становится не менее важен, чем CPU.

Postfix и OpenSMTPD хорошо подходят для лёгких конфигураций. Exim не обязательно тяжелее, но сложные проверки, внешние запросы и богатая логика ACL могут увеличить задержки при пиковом потоке. На любом MTA нужно следить за длиной очереди, временем доставки, количеством отказов, размером логов, inode, свободным местом и ошибками файловой системы.

Сценарии выбора в 2026 году

Один домен, почта для сайта и админов

Для классического сценария — почта домена, несколько ящиков, отправка уведомлений сайта, IMAP через Dovecot, DKIM и DMARC — оптимален Postfix. Он даст меньше сюрпризов, проще диагностируется и хорошо описан. OpenSMTPD тоже возможен, если вы сознательно хотите минимализм, но Postfix будет удобнее для типовой связки.

Много доменов и хостинговая логика

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

Исходящий relay для приложений

Для сервисов, которым нужно отправлять транзакционные SMTP-сообщения через локальный relay, подойдут все три. Postfix будет самым привычным вариантом, OpenSMTPD — самым лаконичным, Exim — избыточным, если нет особых правил. Здесь особенно важны лимиты отправки, отдельные учётные данные, журналирование и контроль bounce-сообщений.

Сложная маршрутизация и нетиповые политики

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

Минимальный безопасный SMTP-шлюз

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

Ошибки выбора, которые дорого обходятся

• Выбирать MTA по принципу «нравится название». Для почтового сервера важнее эксплуатационная предсказуемость, чем личная симпатия к проекту.
• Считать, что MTA решит доставляемость. Без PTR, SPF, DKIM, DMARC, корректного HELO и аккуратной отправки письма всё равно будут теряться или попадать в спам.
• Копировать конфиги без понимания relay-правил. Открытый relay может привести к блокировкам, жалобам и репутационным проблемам.
• Ставить слишком маленькую VDS без запаса под очередь и логи. Почта любит накапливать проблемы: если диск заполнится, сбои начнут каскадировать.
• Не мониторить очередь. Почтовая очередь — ранний индикатор проблем с DNS, TLS, репутацией, внешними провайдерами и локальными фильтрами.
• Не разделять входящую почту и клиентскую отправку. Порт 25 и submission на 587 должны иметь разные правила и разные ожидания безопасности.
• Забывать про TLS для клиентской отправки, IMAP и веб-почты. Для публичных сервисов пригодятся корректные SSL-сертификаты, а не временные самоподписанные решения.

Итоговая рекомендация

В 2026 году Postfix остаётся лучшим выбором по умолчанию для большинства почтовых серверов на VDS. Он достаточно гибкий, хорошо документирован, понятен в сопровождении и поддерживается огромным количеством готовых связок. Если вы не знаете, почему вам нужен именно Exim или OpenSMTPD, начните с Postfix.

Exim выбирайте осознанно: когда гибкость ACL, routers и transports действительно нужна, а у вас есть опыт или готовность аккуратно сопровождать сложную конфигурацию. Он может быть отличной основой для нестандартных почтовых платформ, но не любит бездумного копирования.

OpenSMTPD выбирайте для компактных и ясных задач, где важны минимализм и читаемость. Он хорош как небольшой SMTP relay или аккуратный MTA для простой инфраструктуры, но не всегда удобен как универсальная база для большого Linux-почтовика.

Главное — не рассматривать MTA в отрыве от всей почтовой системы. Хорошая VDS, корректные DNS-записи, TLS, DKIM, DMARC, мониторинг очереди, резервные копии и понятные регламенты обновлений важны не меньше, чем выбор между Exim, Postfix и OpenSMTPD. MTA должен быть тем компонентом, который вы можете спокойно обслуживать, объяснять и чинить в день инцидента.