qmail - это единственный попавший в поле моего зрения почтовый MTA, который при необходимости можно без особых проблем легко модифицировать, в том числе и на рабочей системе, не останавливая ни на минуту ее функционирования - ибо qmail состоит из маленьких модульных программок, каждая из которых может быть заменена с другой с сохранением функциональности. Либо изъята при необходимости. Попробуйте разобраться в исходниках монстра sendmail, или хотя бы в его конфигурационном файле, и вы сразу поймёте разницу. К тому же, qmail можно очень быстро настроить для реальной работы с почтой без относительных проблем -  и он будет в достаточной мере защищен.
Лично мне очень нравится и то, что письма в почтовых ящиках qmail хранит в виде отдельных файлов - каждому сообщению по файлу. Можно легко управлять такой структурой каталогов сторонними средствами, и машинных ресурсов такой метод обработки занимает на порядок меньше, чем при традиционных методах.

Итак, непосредственно установка:

Первым этапом деинсталлируем все MTA, имеющиеся в системе. А особенно sendmail. Либо просто останавливаем соответствующие сервисы.

Всё необходимое сгоняем в один каталог. Распаковываем в соответствующие каталоги. Проще всего для этого (о ужас!) воспользоваться Midnight commander'ом, если вы еще не прониклись идеологией командной строки и не все делаете из нее. Далее, необходимо создать группыи пользователей, под которыми будут работать программы пакета. Обязательно до того, как собирать пакет!
Все делаем под пользователем root.

mkdir /var/qmail
groupadd nofiles
useradd -g nofiles -d /var/qmail/alias alias
useradd -g nofiles -d /var/qmail qmaild
useradd -g nofiles -d /var/qmail qmaill
useradd -g nofiles -d /var/qmail qmailp
groupadd qmail
useradd -g qmail -d /var/qmail qmailq
useradd -g qmail -d /var/qmail qmailr
useradd -g qmail -d /var/qmail qmails

Собираем qmail

make setup check
./config-fast mymaildomen.ru

В последней команде mymaindomen.ru - имя вашей машины. В данном случае - исключительно для примера. У вас будет своё имя.  Это самое имя будет светиться в дельнейшем в команде HELO и в заголовках отправляемых и принимаемых писем.

Заходим в каталог /var/qmail/alias

cd /var/qmail/alias
touch .qmail-postmaster
touch .qmail-mailer-daemon
touch .qmail-root
chmod 644 .qmail*

Внутри созданных файлов должно внести имена реальных пользователей системы, которые будут получать почту за postmaster, mailer-daemon, root соответственно.

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

/var/qmail/bin/maildirmake /etc/skel/Maildir
echo "./Maildir" > /etc/skel/.qmail

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

/var/qmail/bin/maildirmake /home/user/Maildir
cp /etc/skel/.qmail /home/user/
chown user:user /home/user/.qmail

Копируем стандартный загрузчик:

cp /var/qmail/boot/home /var/qmail/rc

Теперь можно проверить локальную доставку почты:

csh -cf '/var/qmail/rc &'

после этой команды заглянем в /var/log/maillog. Там должна обнаружиться строчка "status" от запущенного sendmail.
Пошлём письмо пользователю user:

echo to:user | /var/qmail/bin/qmail-inject

сообщение должно немедленно оказаться в каталоге /home/user/Maildir

Привязываем справочную систему :

echo "MANPATH /var/qmail/man" >> /etc/man.config

в /etc/xinetd.d создаем файл "smtp" следующего содержания:

service smtp

{

   disable = no

   flags = REUSE NAMEINARGS

   socket_type = stream

   protocol = tcp

   wait = no

   user = qmaild

   server = /usr/sbin/tcpd

   server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd

   log_on_success = HOST

   log_on_failure = HOST

} 

в /etc/hosts.allow вносим разрешение для локала 192.168.0.х - только этой подсети будет позволено отправлять почту

tcp-env: 192.168.0.:setenv=RELAYCLIENT

делаем в /etc/init.d файл с именем "qmail" следующего содержания (присвоить право на исполнение для любого пользователя):

#!/bin/bash
csh -cf '/var/qmail/rc &'
exit 0

В файл /etc/rc.d/rc.local.local поместить в конец строчку для его вызова при старте системы:

/etc/init.d/qmail

Установить "подмену" для внутренних почтовых клиентов:

ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail

Теперь можно проверять функционирование smtp:

telnet localhost 25

Подаваемые команды (ответы системы пропущены):

helo myheloname
mail <user@mymaildomen.ru>
rcpt <user@mymaildomen.ru>
data
Subject: Test message
(пустая строка)
Текст сообщения
.
quit

Если все прошло удачно, а так оно и должно быть, если не было ошибок, то пользователь локальной системы с именем user получит ваше сообщение.

На этом этапе считается, что qmail установлен. Он может получать и отправлять почту во внешний мир.

Ага! Спросите вы, а как нам, несчастным пользователям MS Windows, получить свою почту с этой машины???
Забавно, что данный момент напрочь выброшен из всех официальных руководств по настройке как абсолютно несущественный и никому не нужный. Тем не менее, в составе пакета есть специальный демон, позволяющий получать почту по протоколу pop3. Категорически не рекомендуется пользоваться им вне локальной сети, потому что пароли передаются открытым текстом.

Что ж. Ставим пакет checkpassword. Он будет у нас проверять пароли. Не забудьте патчик errno, если ваша система современна.
Команды те же:  make setup check

Теперь создаём в каталоге /etc/xinetd.d файлик pop3 следующего содержания:

service pop3

{

        disable = no

        socket_type             = stream

        protocol                = tcp

        wait                    = no

        user                    = root

        server                  = /var/qmail/bin/qmail-popup

        log_on_success          = HOST

        log_on_failure          = HOST

        server_args             = mymaindomain.ru /bin/checkpassword /var/qmail/bin/qmail-pop3d Maildir

}

Перезапускаем xinetd или просто перезагружаем машину.
Всё. Можно пользоваться. Можно радоваться. Не забудьте закрыть порт 110 фаерволом со стороны интернета.

На этом чтение можно закончить. Потому что дальше - достаточно пессимистичные вещи.

Почему все так плохо? А вот почему:
Стандартный qmail довольно существенно спамит и в том случае, если релей со стороны интернета корректно закрыт.

Возможность рассылки спама заложена в самих принципах работы протокола SMTP. Машина обязана принять письмо, если домен получателя содержится в списке файла /var/qmail/control/rpchosts. А дальше, если конечный адресат не обнаружен, вступает в действие механизм, называемый bounce messaging. Система высылает по адресу возврата письмо, содержащее сообщение от программы qmail-send и исходный текст письма со всеми вложениями. Последнее время этой особенностью протокола активно пользуются спамеры и некоторые почтовые вирусы - задается в качестве адреса получателя несуществующий адрес вашего почтового домена, в качестве адреса возврата - реальный адрес "жертвы", и ваш сервер qmail срабатывает ничуть не хуже любого open relay. Возможно несколько путей к решению этой проблемы. Наиболее простой - урезать максимальный размер bounce message до величины, когда вложения в текст уже не помещаются. Спам все равно будет рассылаться, но существенно уменьшится в объёме. Что делать - редактировать исходный код qmail-send! Если вы не в ладах с языком программирования С, лучше этим не занимайтесь. Если сумели разобраться, что к чему - заодно рекомендую заменить помпезные фразы текста bounce на что нибудь покороче и попонятнее.

Второй способ достаточно действенен в случае корпоративного почтового портала - можно вообще не рассылать bounce messages! Для этого надо организовать приём почты так, чтобы вся почта на домен ссыпалась в один и тот же почтовый ящик. Как это сделать - написано в FAQ на английском языке, прилагаемом к qmail. Это та самая сказочка о наивном пользователе Бобе, который хотел управлять двумя военными доменами одновременно. В кратком пересказе делаем следующее:

в /var/qmail/control создаем файлик virtualdomains

В этом файлике должна содержаться строчка:

mymaildomen.ru:user

То есть, вся почта на домен mymaildomen.ru должна уходить пользователю user. Но это еще не всё! JB хитро умолчал, что надо поставить соответствующие условия в файлике /var/qmail/users/assign:

+:user:666:666:/home/user:::
.

"666" - в данном случае uid пользователя из /etc/passwd. Поставить реальные значения!
После заполнения файла выполнить /var/qmail/bin/qmail-newu
После любой реорганизации виртуальных доменов рестартовать qmail.

Можно сортировать почту по реальным пользователям, а мусор ссыпать кому-то одному. Просто добавляем в /var/qmail/users/assign строчки примерно такого содержания:

=user1:user1:667:667:/home/user1:::

=user1:user2:668:668:/home/user2:::

+:user:666:666:/home/user:::

.

В этом случае user1@mymaildomen.ru и user2@mymaildomen.ru попадет соответствующим пользователям, а, например, fddffdf@mymaildomen.ru окажется в почтовом ящике пользователя "user".

Вы думаете, мы на самом деле организовали виртуальный домен? Ан нет!

Чтобы домен был виртуальным, его имя не должно присутствовать в файлике /var/qmail/control/locals! То есть, если ваш домен - единственный, особой разницы нет, но если их несколько - то нарушение этого правила приведет к тому, что вся почта будет валиться пользователям первого домена. При заведении "правильного" виртуального домена qmail добавляет имя домена слева от имени пользователя. Соответственно, для домена mmmm.ru имена для распределения потоков в файле /var/qmail/users/assign будут представлены в форме mmmm-user3. Отсечь всю почту на такой домен одному пользователю можно инструкцией:

+mmmm-:user3:669:669:/home/user3:::

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

С корпоративным клиентом разобрались. Однако, если позарез необходимо отбивать почту для несуществующих пользователей домена до ее получения, придется менять исходный код qmail-smtpd. Файлик называется qmail-smtpd.c. Наиболее простой способ внести изменения - посмотреть, как работает ограничение на "черный список" обратных адресов из файла control/badmailfrom и сделать так же. "Код ошибки" должен быть 5хх, чтобы сервер-рассыльщик не делал повторных попыток соединения.

Можно существенно снизить количество спама у пользователей, если запретить системе принимать письма с хостов, идентифицирующих себя в команде helo полным именем вашего сервера, вашим доменным именем или вашим IP. Нормальные сервера таких фокусов не устраивают. Как ни странно, таким образом в некоторых случаях можно отсечь до 45% спама.

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

Изощряемся дальше. Самое сложное в программном отношении - отказаться от приёма писем, содержащих "нехорошие" вложения типа файлов с двойным расширением .doc.exe, .pif, .scr, .bat, .vbs, .vba, .com. Сложное - потому что придется в потоке анализировать содержимое тела письма, а это достаточно нетривиальная задача, поскольку авторская методика JB заставляет отказаться от использования библиотечных функций обработки строкового контента. Если рискнули на эту задачу - смотрим как сделано прерывание smtpd при получении писем с объёмом, превышающим лимит. Т.е. демон просто немедленно прерывает сессию с выдачей соответствующего сообщения. Кстати, этот метод может не снизить объем трафика, потому как у меня есть подозрения, что далеко не все MTA корректно обрабатывают данную ситуацию. В описании стандарта SMTP сказано, что поле data должно быть полностью принято сервером. Так что, нагло нарушаем стандарты.

Вы ждете от меня рабочего кода? Ну уж нет! "Сделай сам - а не жди манны небесной" - должно быть святым правилом того, кто имеет дело с UNIX. Несомненно, у вас получится лучше, чем когда-то у меня. Если не наделаете ошибок. Внимательно выверяйте код; любые баги в подобного рода программках чреваты далеко идущими последствиями! Можете и по интернету поискать - а вдруг кто уже сделал, но не забудьте проверить и их ошибки... Но сильно не надейтесь. Потому что такие доработки - уже из области коммерческого применения, а деньгами делиться не принято. Да и лицензию JB можно легко нарушить... Моя версия qmail-smtpd получилась такой, что diff просто не может найти точек синхронизации.

Допустим, все вышесказанное как-то передалали. Работает. На что обратить внимание еще?
Заметили одну особенность? Стандартный qmail не регистрирует неудачные попытки соединения. Вы никогда не узнаете, что именно было отбито вашим сервером, какие именно пользователи пытались логиниться по pop3; да и анализировать логи qmail - занятие для истинного мазохиста. Вот большое поле для вашей деятельности! Только не увлекайтесь. Большие проекты обычно быстро умирают.

Дочитав до этого момента, некто может воскликнуть: "Какой позор! Этот ламер показывает, как ставить qmail совершенно левым образом, без daemontools и tcp-ucs!". Не вижу смысла говорить здесь об этом методе запуска сервисов. Да, немного надежнее. Да, круто - график процессов показывает. Но действительно ли это необходимо для мало загруженных серверов - не уверен. Кто хочет, может найти массу информации по поводу запуска через daemontools в других местах. Как и монстров, порожденных из qmail - с поддержкой mysql и radius, анализаторами вирусов, smtp-авторизацией; можно найти и чудовищ, переписанных на php и perl... Много чего есть в этом мире - и красивого и уродливого. Ради бога, не пишите модули MTA для интерпретаторов скрипта, если хотите, чтобы они сохраняли эффективность работы. Имхо.

И последнее. Настойчиво не рекомендую ставить qmail из .rpm! Ничего хорошего в этом нет, одни только проблемы.

Как всегда, исправления и дополнения принимаются. Как и ссылки на соответствующие тематике ресурсы.