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$d8...@wagner.wagner.home> -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org