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/