Сергей Супрунов

Мы уже привыкли к «великолепной четвёрке» – Sendmail, Postfix, Exim, qmail – на рынке открытых серверов электронной почты. Sendmail хоть и занимает первую строчку «хит-парада», всё же неуклонно теряет свои позиции. Но команда разработчиков, похоже, не собирается так просто сдаваться...

Зачем нужен «ещё один» Sendmail?

Основным недостатком «старичка» Sendmail, который сразу же упоминается, как только речь заходит о сравнении различных почтовых серверов, является его монолитная архитектура. Размещение всего функционала в одном двоичном файле, безусловно, тянет за собой целую массу проблем: и не слишком эффективное расходование ресурсов; и неустойчивость системы в целом, когда ошибка в одном компоненте может привести к полной неработоспособности сервера; и сложность разработки... Также редко кто забывает о «дырявом» прошлом этого пакета, по инерции интерполируя это и на настоящее, и даже на будущее. Ну а сложность настройки – это вообще притча во языцех, хотя типовая настройка Sendmail уже очень давно занимает лишь десяток-другой простых и, что называется, интуитивно понятных строк в mc-файле.

Можно долго спорить о том, насколько серьёзны эти недостатки (и недостатки ли это вообще), но понятно одно – «имидж» Sendmail на данный момент не слишком хорош, особенно среди начинающих системных администраторов, и как бы разработчики ни старались улучшать этот пакет, на него всё равно смотрят искоса.

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

Таким образом, на свет появился Sendmail X, недавно переименованный в MeTA1. В качестве основных требований к разрабатываемой системе декларируются:

n  полная поддержка RFC2821 и ряда расширяющих стандартов;

n  надёжность, исключающая потерю сообщений;

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

n  масштабируемость, т.е. способность наращивать производительность (почти) пропорционально увеличению вычислительной мощности оборудования;

n  расширяемость;

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

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