Re: qmail or not qmail?
Hello!
On Saturday 30 January 2010 11:14:33 Artem Chuprina wrote:
> Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 30 Jan 2010 00:53:01 +0300:
> AP> Как поставить отдельные обработчики для локально и удаленно
> AP> доставляемой почты? Как назначить разные обработчики для почты,
> AP> пересылаемый на разные хосты? И так далее. А тупая обработка _всей_
> AP> принятой почты одинаково - даром не нужна.
>
> Что значит "как"? Для локально и удаленно доставляемой они там уже
> разные. Прямо в поставке. Для некоторых хостов я почту отправляю по
> UUCP. Делается это через transport_maps.
>
> Или тебе какую обработку? Если ты говоришь о локально vs. удаленно
> _доставляемой_, то там остается уже только отправлялка.
Как пример - поступила себе почта на балансировщик кластера системы
документооборота. Часть писем должна быть обработана локально, другие
следует переправить на одну или все рабочие ноды. Где-то по адресату
сортируется, а где-то по хидерам или содержимому - обработка может
производиться согласно конфигам или путем передачи внешнему скрипту через
пайп. Возвращаясь к старому вопросу об отбое на этапе приема - балансировщик
понятия не имеет о пользователях, существующих на каждой из нод, так что
обязан честно переслать далее корреспонденцию, удовлетворяющую
определенным требованиям, пусть уже рабочие ноды разбираются.
Конфигурация вполне тривиальная, но легко строится только на qmail.
> AP> И притом, запуская qmail-smtpd, я могу быть уверен, что код для
> AP> работы с pop или imap в принципе не задействован, так что мне не
> AP> требуется о нем думать (не нужны мне эти довески). А в postfix все
> AP> перемешано, и уязвимость в общей либе может "выстрелить" в любой
> AP> момент.
>
> А в postfix кода pop или imap нет вообще. Поэтому я не "могу быть
> уверен", а просто уверен, что он не задействуется.
Еще раз - в постфиксе нет разделения кода, а есть навороченная либа и к ней
дополнительные либы с расширением функционала. Это что - для замены
постгреса на эскулайт мне половину постфикса перелопатить надо?..
> AP> и это большое преимущество, в то же время в любой момент, если
> AP> вдруг мне понадобится pop или imap доступ сделать (хотя зачем?), я
> AP> могу тут же запустить нужный обработчик (через tcpserver). Могу
> AP> через stunnel соединяться, или ssl-enabled tcpserver
> AP> запустить... все идеально настраиваемо. В то время как в постфикс
> AP> засунута поддержка ssl через фиг знает что,
>
> Ты не поверишь - через абсолютно тот же самый libssl, что stunnel. И
> запустить postfix через stunnel - тоже никаких проблем. А вот как ты
> будешь через stunnel передавать в qmail авторизацию по клиентскому
> сертификату так, чтоб qmail это понял - это я б посмотрел...
Это шутка была? Вот так через stunnel:
http://www.ekkaia.org/software/mail/qmailssl.php
Нативный способ - через ucspi-ssl, являющийся аналогом оригинальному
ucspi, но с поддержкой ssl. Если хочется "с наворотами", можно
использовать его расширенный вариант ucspi-tls:
http://www.suspectclass.com/sgifford/ucspi-tls/ucspi-tls-qmail-howto.html
Есть и еще варианты, но навскидку не вспомню.
Все перечисленные решения позволяют запускать любой сервис, не
привязываясь к именно qmail. Ага, unix-way.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: