Re: qmail or not qmail?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 30 Jan 2010 13:13:28 +0300:
>> AP> Как поставить отдельные обработчики для локально и удаленно
>> AP> доставляемой почты? Как назначить разные обработчики для почты,
>> AP> пересылаемый на разные хосты? И так далее. А тупая обработка _всей_
>> AP> принятой почты одинаково - даром не нужна.
>>
>> Что значит "как"? Для локально и удаленно доставляемой они там уже
>> разные. Прямо в поставке. Для некоторых хостов я почту отправляю по
>> UUCP. Делается это через transport_maps.
>>
>> Или тебе какую обработку? Если ты говоришь о локально vs. удаленно
>> _доставляемой_, то там остается уже только отправлялка.
AP> Как пример - поступила себе почта на балансировщик кластера системы
AP> документооборота. Часть писем должна быть обработана локально,
AP> другие следует переправить на одну или все рабочие ноды. Где-то по
AP> адресату сортируется, а где-то по хидерам или содержимому -
AP> обработка может производиться согласно конфигам или путем передачи
AP> внешнему скрипту через пайп. Возвращаясь к старому вопросу об отбое
AP> на этапе приема - балансировщик понятия не имеет о пользователях,
AP> существующих на каждой из нод, так что обязан честно переслать
AP> далее корреспонденцию, удовлетворяющую определенным требованиям,
AP> пусть уже рабочие ноды разбираются. Конфигурация вполне
AP> тривиальная, но легко строится только на qmail.
Ты не поверишь, вторичный MX моей конторы выполняет ровно такую работу -
и построен на postfix, и легко строится на любом из четырех изученных
мной MTA. Нет, он не балансировщик. Там другая задача.
Ну, строго говоря, сортирует он по адресату - ибо мне по хедерам и
содержимому не нужно. Но я знаю, как это сделать.
>> AP> И притом, запуская qmail-smtpd, я могу быть уверен, что код для
>> AP> работы с pop или imap в принципе не задействован, так что мне не
>> AP> требуется о нем думать (не нужны мне эти довески). А в postfix все
>> AP> перемешано, и уязвимость в общей либе может "выстрелить" в любой
>> AP> момент.
>>
>> А в postfix кода pop или imap нет вообще. Поэтому я не "могу быть
>> уверен", а просто уверен, что он не задействуется.
AP> Еще раз - в постфиксе нет разделения кода, а есть навороченная либа
AP> и к ней дополнительные либы с расширением функционала. Это что -
AP> для замены постгреса на эскулайт мне половину постфикса
AP> перелопатить надо?..
Тебе, скорее всего, да. А другие, вероятно, с легкостью обойдутся без
этих извращений. Более авторитетно сказать не могу, ибо мне ни
постгреса, ни эскулайта туда не надо, а Berkeley DB там в комплекте.
>> AP> и это большое преимущество, в то же время в любой момент, если
>> AP> вдруг мне понадобится pop или imap доступ сделать (хотя зачем?), я
>> AP> могу тут же запустить нужный обработчик (через tcpserver). Могу
>> AP> через stunnel соединяться, или ssl-enabled tcpserver
>> AP> запустить... все идеально настраиваемо. В то время как в постфикс
>> AP> засунута поддержка ssl через фиг знает что,
>>
>> Ты не поверишь - через абсолютно тот же самый libssl, что stunnel. И
>> запустить postfix через stunnel - тоже никаких проблем. А вот как ты
>> будешь через stunnel передавать в qmail авторизацию по клиентскому
>> сертификату так, чтоб qmail это понял - это я б посмотрел...
AP> Это шутка была? Вот так через stunnel:
AP> http://www.ekkaia.org/software/mail/qmailssl.php
AP> Нативный способ - через ucspi-ssl, являющийся аналогом оригинальному
AP> ucspi, но с поддержкой ssl. Если хочется "с наворотами", можно
AP> использовать его расширенный вариант ucspi-tls:
AP> http://www.suspectclass.com/sgifford/ucspi-tls/ucspi-tls-qmail-howto.html
AP> Есть и еще варианты, но навскидку не вспомню.
AP> Все перечисленные решения позволяют запускать любой сервис, не
AP> привязываясь к именно qmail. Ага, unix-way.
Ага, ты таки даже не понял, про что я тебя спросил. Поэтому вопрос о
том, как ты будешь это делать, снимается. Никак не будешь, потому что
не понимаешь, что же, собственно, нужно.
--
HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в <b9td98$d8k$3@wagner.wagner.home>
Reply to: