Exim 4.53 released

вот бы его с постфиксом и кумылом сравнить...
со шлимылом сравнивать бессмысленно - он всем просирает.

Анонимус решил флейм поджечь? :) "Мы на гре всем буржуям флейм немаленький раздуем"?

Имхо если сравнивать, то exim выше на голову. Покажите мне какой еще MTA умеет ACL?

Возможность на любом! smtp-этапе проверить всё! что только можно проверить и принять решение о том что делать с письмом (а сделать можно что угодно) - куда лучше-то? :)
А уж embedded perl.. Ээх, вкуснотищща.

Exim просто лучший. Но у нас модны деревянные решения :(

гибкость exim : поддержка graylists на втроенном ACL + SQLбаза для прочих MTA - некие демоны.. патчи..

а учитывая простоту настройки и помощь дебага ему имхо нет равных.

>а учитывая простоту настройки и помощь дебага ему имхо нет равных.

вот не надо мне сказок венского леса, простота настройки такая, что берешь дефолтный конфиг, переносишь в него строчку из документации и эксим валится без предупреждения и объяснения "а почему собственно?.."

> со шлимылом сравнивать бессмысленно - он всем просирает.

По дырявости они, пожалуй, в ровень идут.

недырявых программ не бывает - закон кибернетики :))))))))))

Угу. Всё относительно конечно. Есть такие как sendmail, exim, wu-ftpd, internet explorer. А есть такие как postfix, qmail, djbnds... :)

>со шлимылом сравнивать бессмысленно - он всем просирает.
ты болен?

Откуда дровишки?
Можно ссылочки на историю уязвимостей в exim?

про дырки в сендмыле поподробнее, плиз.

Тупые дети.

Для сендмыла есть ентерпрайз солюшен, для мегакорпораций, которое держит

нагрузку 1 млн. писем в час.

Тупой детский поиск на cert.org для шлимыла дает больше 200 ссылок. Для exim'а - 9. Это, конечно. не колво уязвимостей, но сравнивать шлимыл и exim по этому параметру как-то некорректно имхо :)

ЗЫ. Дядько Саныч - мой почтение :)

qmail неуязавим без патчей, но без патчей он не нужен, т.к. ничего практически не умеет.

А если наставить 1000 и 1 патч, то dj не говорит, что он неуязвим(что подразумевает, то он уязвим) и не вносит эти патчи в qmail, который неузязвим, но без патчей... И так далее.

Не находите замкнутого круга? :)

P.S. Голый qmail - академическая работа.

> но без патчей он не нужен, т.к. ничего практически не умеет.

Без патчей он выполняет работу MTA, ничего больше.

> не говорит, что он неуязвим(что подразумевает, то он уязвим)

С логикой что-то не так. "Все тигры млекопитающие, ergo все млекопитающие -- тигры". ;)

> Голый qmail - академическая работа.

Отчасти верно. Но эта "академическая работа" полнофунциональна, а благодаря своей архитектуре очень легко расширяется.

Да и patch патчу рознь, если писать в стиле Дена, получается совсем неплохо. Он сформировал удобный, а главное безопасный набор примитивов (функций), с его строками работать вообще сказка.

Я уже, помнится, говорил, когда перед нами встала задача писать свой MTA или расширять существующий (ни в одном не было необходимого функционала "из коробки"), то выбора практически и не было -- qmail.

http://www.guninski.com/exim1.html

http://www.idefense.com/application/poi/display?id=183&type=vulnerabiliti...

http://www.idefense.com/application/poi/display?id=179&type=vulnerabiliti...

http://www.idefense.com/application/poi/display?id=178&type=vulnerabiliti...

http://www.exim.org/pipermail/exim-users/Week-of-Mon-20030811/057720.html

http://www.securityfocus.com/advisories/5783

http://www.securityfocus.com/advisories/7817

http://www.securityfocus.com/advisories/6688

И так далее, и тому подобное...

> С логикой что-то не так. "Все тигры млекопитающие, ergo все млекопитающие -- тигры". ;)

Ну хорошо, скажу даже больше :) Он не принимает патчи и не гарантирует(в т.ч. и не даёт денег за найденные уязвимости, из чего я подразумеваю, что уязвим) то, что даже с одним приложенным самым распространённым патчем qmail будет неуязвимым.

Так понятнее? :)

А ентот ехим maildir умеет?

> А ентот ехим maildir умеет?

Умеет - надо только при сборке эту опцию включить. Ещё из форматов локального почтового ящика он умеет MBX и Mailstore (правда что такое есть последний и чем он хорош/плох я сам не знаю)

>Без патчей он выполняет работу MTA, ничего больше.

Хреново, надо сказать, выполняет.

//Loseki

Он умеет local delivery куда угодно.

Ты болен?

> Он не принимает патчи и не гарантирует(в т.ч. и не даёт денег за найденные уязвимости, из чего я подразумеваю, что уязвим)

То есть из того, что Ден дает гарантию на _свой_ код, а на _чужой_ не дает, следует...

У тебя с логикой все в порядке? ;)

Я тебе по секрету скажу, что некоторые авторы патчей и приложений к qmail следуют примеру djb, и тоже дают денежную гарантию. А уж то, что и на qmail в чистом виде, и с большинством наложенных патчей не было ни одного работающего эксплоита -- это факт.

Можно сколько угодно говорить, что это "академическая поделка", "требует жуткого количества патчей", "ничего не умеет", "легко устраивает DOS другим серверам", "ничему не соответствует", "принципиально не расширяется", "и вообще тормоз"... Но от фактов не уйти: qmail обслуживает множество доменов, очень хорошо держит нагрузку, легко массштабируется. И не был сломан. Он просто работает.

PS. В кавычках основные заблуждения.

> Хреново, надо сказать, выполняет.

Определение "хреново" в студию. "Хреново" что?

> Но от фактов не уйти: qmail обслуживает множество доменов

назовите десять, хотя бы. которые _не_ находятся под вашим контролем/не поставлены вами. сможете двадцать пять -- давайте двадцать пять. если они еще будут не домашними тазиками кульхацкеров -- еще лучше. я такой навскидку назову только один, но там он весьма heavily modified.

анализируя свои логи, могу сказать: sendmail -- дофига, postfix -- достаточно, exim -- встречается, cgp -- редко. а qmail в списке моих (читай: на моих почтовых серверах) корреспондентов популярен не более, чем нелегальная копия mdaemon под win32. =)))

---vk

>Определение "хреново" в студию. "Хреново" что?

Легко.
Расскажи мне, пожалуйста, как связать логи в /var/log/qmail/smtpd с /var/log/qmail.

Может я чего-то в этой жизни не понимаю, но как из этих логов понять, _откуда_ (с какого ip-шника) мне свалилось письмо?

Второе: какую нагрузку у тебя держит qmail? У меня на одном и том же железе (P3-800/256, FreeBSD+soft-updates+UFS_DIRHASH, кроме MTA разная мутотень вроде apache, etc), гоняющем через себя ежедневно 15-16Гб почты, qmail разгребал очередь крайне медленно. Постфикс же как эмиттер перемалывает всё со свистом.

Ни о какой доп. настройке речь пока не идёт, брались два MTA из коробки.

Да, в чём великий сакральный смысл qmail'а не смотреть в /etc/hosts?

//Loseki

До кучи:

Коробочный qmail+vpopmail - связка, на первый взгляд, неплохая.
Но заставь мне в этой связке qmail не принимать почту на несуществующих пользователей, отфутболивая её на этапе RCPT TO:? А то за backscatter mail нонче запросто в листы засовывают, а молчаливое поедание письма без баунса - тоже не выход.

//Loseki

> я такой навскидку назову только один, но там он весьма heavily modified.

А он всегда в серьезном применении heavily modified. ;) И в отличии от других его намного легче modify.

> Расскажи мне, пожалуйста, как связать логи в /var/log/qmail/smtpd с /var/log/qmail.


--- Makefile.old        Wed Feb 21 09:39:59 2001
+++ Makefile    Mon Sep 16 10:54:46 2002
@@ -1420,11 +1420,11 @@

 qmail-queue: \
 load qmail-queue.o triggerpull.o fmtqfn.o now.o date822fmt.o \
-datetime.a seek.a ndelay.a open.a sig.a alloc.a substdio.a error.a \
+datetime.a seek.a ndelay.a open.a sig.a alloc.a strerr.a substdio.a error.a \
 str.a fs.a auto_qmail.o auto_split.o auto_uids.o
        ./load qmail-queue triggerpull.o fmtqfn.o now.o \
        date822fmt.o datetime.a seek.a ndelay.a open.a sig.a \
-       alloc.a substdio.a error.a str.a fs.a auto_qmail.o \
+       alloc.a strerr.a substdio.a error.a str.a fs.a auto_qmail.o \
        auto_split.o auto_uids.o

 qmail-queue.0: \
--- qmail-queue.c.old   Fri Apr 27 14:07:08 2001
+++ qmail-queue.c       Mon Sep 16 10:36:08 2002
@@ -16,6 +16,7 @@
 #include "auto_uids.h"
 #include "date822fmt.h"
 #include "fmtqfn.h"
+#include "strerr.h"

 #define DEATH 86400 /* 24 hours; _must_ be below q-s's OSSIFIED (36 hours) */
 #define ADDR 1003
@@ -248,6 +249,8 @@
  if (fsync(intdfd) == -1) die_write();

  if (link(intdfn,todofn) == -1) die(66);
+
+ strerr_warn2("qmail-queue: ",todofn,0);

  triggerpull();
  die(0);

> qmail разгребал очередь крайне медленно.

BIG_TODO_PATCH

> Но заставь мне в этой связке qmail не принимать почту на несуществующих пользователей

И на этот случай патчи есть. ;)

А теперь смотрим квоту :/

">Без патчей он выполняет работу MTA, ничего больше.

Хреново, надо сказать, выполняет."

И где тут противоречие? Я ж сразу сказал, что не годится оно _без патчей_ не в борщ, ни в красную армию, что ты замечательным образом и подтвердил тремя патчами, прикручивающими к qmail'у то, что в других MTA присутствует из коробки.

Сужу по своей практике: задачи, которая была бы настолько хитрой, что требовала дописывания чего-либо к существующему MTA, не вставало никогда. Как правило "всё уже украдено^W написано до нас". И оттестировано в 99% случаев использования другими, что радует.

Разумеется, это не значит, что таких задач нет вообще. Ну и если есть время пописать, поковырять продукт, вдумчиво понакладывать патчи, просматривая их на предмет "а не конфликтует ли патч A версии 0.4 с патчем Б версии 3.3?" - это, конечно, прекрасно. Но заниматься этим при наличии таких же фич из коробки - ну ево.

При этом у меня нет идиосинкразии на DJB, но вот такой неудобный в обслуживании продукт получается.

//Loseki

PS бтв, поправь меня, если я не прав: qmail действительно ограничивает число одновременно работающих qmail-send'ов (или как там эти процессы назывались) в зависимостит от LA? Что-то такое у меня в памяти осело и если правда - то это вообще пинцет. Какая-то, бл, железка будет считать себя умней человека, да и ещё не даёт возможности этот крыжик выключить.

>>> Без патчей он выполняет работу MTA, ничего больше.

> Я ж сразу сказал, что не годится

Почту принимает? Да. Рассылает? Да. Значит MTA.

> оно _без патчей_ не в борщ, ни в красную армию

А ты не считай отдельно "продукт", отдельно "патчи". По сути qmail разрабатывается сообществом как единое целое "qmail+patches", считай последние опциями configure --with-something. Все дело в запрете djb распространять измененные версии, остается только накладывать патчи и пересобирать. Благо примеры уже были: lame вспоминается.

> qmail действительно ограничивает число одновременно работающих qmail-send'ов (или как там эти процессы назывались) в зависимостит от LA?

Other MTAs include, in effect, a specialized version of inetd that watches the load average. qmail's design inherently limits the machine load, so qmail-smtpd can safely run