Хм, ну а Postfix не лучше?

Лучше. Но меня не это интересует.

> Ну, пусть написан как пример, не развивается.

Почему как пример, если он реально пашет, как ломовая лошадь? Почему не
развивается? А что можно развить в pop/smtp? Всё давно развито ;) Более
того, в качестве бесплатного приложения qmtp в коробке. Это типа кусочек
будущего. Ну, а новое поколение программы развивается в ветке qmail2.
Только её ещё никто пока не видел ;)

> Ну, нет такой производительности, как у sendmail.

Цифры в студию. У меня прямо противоположные данные.

fagot, ты не один в интернете.

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

Вот тут-то и начинаются проблемы.

1). qmail отвратно работает с secondary MX.

В результате, при перегрузке primary-MX, qmail продолжает долбится на этот primary, вместо того, чтобы как все нормальные MTA отправить почту через secondary.

2). qmail, поставленный горе-админом на релее, в случае практически любых проблем с радостью убъёт письмо, не оставив от него никаких следов.

3). qmail (насколько я помню из своего сисадминского детства :) ) требует (требовал?) нетривиальных телодвижений для правильной настройки relaying. Шаг влево/шаг вправо - и через тебя начинают рассылать горы спама.

Вобщем резюме: не нужно на виду у всех есть какашки. Либо употребляй их в гордом одиночестве, либо переходи на нормальную пищу и не напрягай окружающих.

>> Ну, пусть написан как пример, не развивается.

> Почему как пример, если он реально пашет, как ломовая лошадь? Почему не развивается? А что можно развить в pop/smtp?

Навскидку: антивирус, спамфильтр, SPF. Новые AUTH, SSL/TLS. Интеграция с разичными БД и псевдо-БД. IMAP, в конце концов.

>> Ну, нет такой производительности, как у sendmail.

> Цифры в студию. У меня прямо противоположные данные.

Можешь поделится с общественностью своими цифрами?

Заодно методику тестирования покажи. Если, конечно же, ты тестировал не с установками по умолчанию. :)

MTA, который в случае проблем с primary mx не умеет по-нормальному использовать secondary "there's no reason for primary mx to persistantly drop connections" (c) -- не имеет права на существование. Не говоря уж о ограниченной функциональности, которая не расширяется кроме как сторонними патчами, причем автор на таких админов ругается злыми словами.

> Навскидку: антивирус, спамфильтр

Навскидку, qscaq+clamav, bmf/bogofilter и т.д. Пойми, в qmail есть всё,
что требуется для интеграции сторонних программ, даже если они будут
встраиваться через 100 лет. Человек детально продумал архитектуру один
раз. Программа работает без изменений уже 7 лет. И будет работать до
скончания эры smtp.

> Новые AUTH, SSL/TLS.

Это тоже аргумент для бедных. Архитектура qmail позволяет встраивать
любые схемы аутентификации.

> Интеграция с разичными БД и псевдо-БД.

Да сколько угодно. Глянь на vpopmail, vmailmgr - решения для массмэйл.
Опять же, это сторонние программы, которые даже не интегрируются в
qmail, а кооперируют с ним, не требуя изменения ни единой строчки кода
самого qmail.

> IMAP

Какие у тебя проблемы с imap? Courier-imap из коробки прекрасно
работает с maildir - самым надёжным решением для хранения почты.
И это снова благодаря гениально продуманной простой гибкой архитектуре
qmail.

> Можешь поделится с общественностью своими цифрами?

Своих цифр нет. Ориентируюсь на сторонние тесты, которые можно найти в инете.
Пример:
http://www.benchmarks.dmz.ro/article.php?story=20020711175408345

Results:
Qmail: 26.88 mails/sec
Sendmail: 22.83 mails/sec.
This is 17.7% better performance for Qmail.

> не умеет по-нормальному использовать secondary

Ты не точен и не определил понятие "нормально".

> Не говоря уж о ограниченной функциональности, которая не расширяется кроме как сторонними патчами

Чем сторонние патчи (читай: модули расширения) хуже встроенных решений?
Это юникс, парень ;)

1). Ты аккуратно выкинул фразу про SPF. :)

2). Я отвечал на твою реплику "что нового может быть в smtp/pop3"

> Ты не точен и не определил понятие "нормально".

При получении от primary MX кода 40x qmail не лезет на secondary.

> Чем сторонние патчи (читай: модули расширения) хуже встроенных решений? Это юникс, парень ;)

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

Вы забываете один тонкий момент. qmail _будет_ работать c secondary,
если primary MX изначально в дауне! Qmail _не_ будет пробовать
secondary, если primary отозвался, но дропает соединение.

И ещё:
"RFC974 says that an MTA should try a domain's MX hosts in order, but
doesn't say anything about what sort of failure should make an MTA
decide that an MX is sufficiently unresponsive that the sender should
try the next MX."

Смысл уже несколько иной, неправда ли?
"Совсем не работает с secondary MX" против "Не делает того, что не требуется согласно RFC".

Если быть точным, ответ автора qmail выглядит так:

"There is no legitimate reason for a primary MX to persistently drop
connections. SMTP clients are not required to try secondary MX hosts."

Второе предложение в этой цитате все почему-то опускают.

> Ты аккуратно выкинул фразу про SPF. :)

Есть такой поисковик, google называется. Набиваешь в окне поиска
"qmail spf" и жмёшь на "I am lucky!" ;)
http://www.saout.de/misc/spf/

> Тем, что после каждой компиляции нужно тестировать результат.

И как якобы отсутствие необходимости в таком тестировании помогает
предотвратить неизменно появляющиеся дыры в том же sendmail?

>"There is no legitimate reason for a primary MX to persistently drop connections. SMTP clients are not required to try secondary MX hosts."

Второе предложение в этой цитате все почему-то опускают.

Это уже похоже на культ Бернштейна. Вам почту доставить, или показать всему миру, что мы мол тута самые умные? И настройки релея у него да, неочевидная.

> И как якобы отсутствие необходимости в таком тестировании помогает предотвратить неизменно появляющиеся дыры в том же sendmail?

В огороде бузина, а в Киеве дядька.

sendmail (exim, postfix и любая другая программа, для изменения поведения которой достаточно изменить конфиг) может не работать потому, что у него есть ошибка. Но эта ошибка не будет появлятся или исчезать при изменениии конфига.

А вот qmail (или любая другая программа, требующая перекомпиляции для изменения поведения) вполне может сломаться после наложения очередного патча.

> "There is no legitimate reason for a primary MX to persistently drop
connections. SMTP clients are not required to try secondary MX hosts."

Кол-во активных соединений на 25-тый порт превысило заданный предел. MTA на primary вернул 4xx.
qmail недовольно хмыкнул и не пошёл на свободный secondary.

Это нормально?
Для сферических коней в вакууме - возможно.
Для реальной жизни - нет.

Вот именно за это мы и не любим Берштейна.

> http://www.saout.de/misc/spf/

Тебе не страшно бету на продакш ставить?

Для тех, кто не в курсе, речь идет об этом: http://www.linux.org.ru/jump-message.jsp?msgid=636259

Что касается рекомендации не использовать qmail, то я обосновал ее. qmail не соответствует RFC на SMTP а это значит, что он не может считаться MTA. Как я уже говорил, достоинства и недостатки RFC, который является стандартом, бесполезно. Хорош он или плох, это стандарт и ему нужно следовать.

Во-вторых, при выборе нового почтового сервера, следует выбирать программу, имеющую будущее. qmail его не имеет. Если он уже стоит - ну пользуйся на здоровье. Надо только принимать во внимание его архитектурные недостатки.

Кстати, по поводу интеграции сторонних систем аутентификации - убогий checkpassword совершенно недостаточен для интеграции SASL - там аутентификация может производиться вовсе даже не по паролю.

А maildir ненадежен на системах с журнализацией и softupdates. Там просто сообщения будут теряться при откате журнала. Именно из-за архитектурной убогости qmail.

Впрочем, культ Берштайна меня задолбал. Давайте не будем продолжать эту тему здесь по причине ее бессмысленности.

> Кол-во активных соединений на 25-тый порт превысило заданный предел.
> MTA на primary вернул 4xx.
> qmail недовольно хмыкнул и не пошёл на свободный secondary.
>
> Это нормально?

Это не просто нормально, это единственно правильное решение.

> Вот именно за это мы и не любим Берштейна.

;) Вспоминается анекдот про Чайковского. Да, Бернштейн - великий
математик и специалист в области криптоалгоритмов. Но мы его любим не
только за это ;)

> > http://www.saout.de/misc/spf/

> Тебе не страшно бету на продакш ставить?

Йо, есть люди, которым не страшно ставить sendmail на продакшн.
После таких экстрималов все патчи к qmail выглядят лёгкими детскими
страшилками ;)

> qmail не соответствует RFC на SMTP а это значит, что он не может считаться MTA.

Ерунда. Ни одно расхождение с RFC в реализации qmail не сделано просто
так. За каждым якобы отходом от стандарта (а в отдельных местах стандарт
очень расплывчат) стоит детальный анализ всевозможных ситуаций, которые
данным стандартом не были предусмотрены вовсе по причине его древности.

> при выборе нового почтового сервера, следует выбирать программу, имеющую будущее. qmail его не имеет.

Бла-бла. В стиле "Я подумал и мы решили". Проявление голых эмоций и
костности мышления.

> Надо только принимать во внимание его архитектурные недостатки.

Как всё-таки легко поставить всё с ног на голову ;) Лучшую архитектуру
в истории написания smtp (и не только) объявить проблемной и ущербной.

> убогий checkpassword совершенно недостаточен для интеграции SASL - там аутентификация может производиться вовсе даже не по паролю.

Ясненько... Подсказка: слово 'password' в составе 'checkpasword'
совсем не означает, что аутентификация может производится только по
паролю! Странно, да? Смотри: интрефейс требует наличия проверяющей
аутентификацию программы и подпрограммы в качестве параметра,
подпрограмма запускается только в случае успешного выполнения
программы проверки. Это всё. Что проверяет программа проверки - это
её личное дело. Она может делать что угодно с переданной информацией,
вплоть до полного её игнорирования и следования своим внутренним
алгоритмам проверки, например, ориентируясь на фазу Луны или
активность солнца...

> А maildir ненадежен на системах с журнализацией и softupdates. Там просто сообщения будут теряться при откате журнала.

Опять неточность. Во-первых никто не мешает использовать те настройки
fs, которые рекомендованы для qmail. Вторая неточность: смотря какой
тип журнализации используется. Например, ext3 в режиме data=journal
полностью устраивает qmail. Если не ошибаюсь, то же относится и к
reiserfs4.

> Именно из-за архитектурной убогости qmail.

Не понял этот момент. Я понимаю, если бы камни кидались в огород
вообще архитектуры юникс и в частности в устройство различных fs.
Каким боком qmail должен отвечать за неспособность OS надёжно
сохранить файл после того как она (OS) отрапортавала вызывающему
процессу, что всё OK, файл надёжно сохранён? Автор qmail дал чёткие
и однозначные рекомендации относительно того, как настраивать fs
для надёжной работы qmail (и не только qmail, кстати).

> Впрочем, культ Берштайна меня задолбал

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

> Вам почту доставить, или показать всему миру, что мы мол тута самые умные?

Во-первых, а почему бы и нет? Пусть не умными, а просто уважающими
законы? Я не считаю ни умным, ни тем более правильным опускаться до
уровня самого неграмотного администратора почтового сервера и делать
некие дополнительные телодвижения ради прощения его самых глупых ошибок.
Да, мы хотим доставить почту. Но! Не любым способом и не любыми
средствами. Пусть каждый самостоятельно заплатит за свои ошибки.
Никакой круговой поруки!

> И настройки релея у него да, неочевидная.

Гм, что можно не понять в этой строчке: 1.2.3.6:allow,RELAYCLIENT=""
И какое слово не понятно в этом описании:
http://cr.yp.to/qmail/faq/servers.html#authorized-relay
Мне не хватает фантазии, чтобы придумать, что там такого неочевидного...

> sendmail (exim, postfix [...] может не работать потому, что у него есть ошибка.
> А вот qmail [...] может сломаться после наложения очередного патча.

Результат в обоих случаях - неработающая система.
Вопрос: В чём преимущество неработающих sendmail/postfix над
неработающим qmail? ;)

ВСЕ! ХВАТИТ!

Я просил у oxonian объястить свою позицию. Увы, я не следил на предыдущей темой и пропустил это объяснение.

Теперь я его получил, спасибо.

2oxonian: если флейм не прекратят, убей тему, plz

> Теперь я его получил, спасибо.

Теперь тебя уже никто и не спрашивает ;) Мавр сделал своё дело, мавр
может уходить ;) А тема интересна вне зависимости от твоих личных
потребностей.

> 2oxonian: если флейм не прекратят, убей тему, plz

Нечего было "личный" вопрос задавать в форуме, не хотел флейма - послал бы емейл... А вообще интересно почитать - я только думаю какой почтовик ставить.

>> Кол-во активных соединений на 25-тый порт превысило заданный предел.
>> MTA на primary вернул 4xx.
>> qmail недовольно хмыкнул и не пошёл на свободный secondary.
>>
>> Это нормально?

> Это не просто нормально, это единственно правильное решение.

Окуеть.
primary умирает под нагрузкой, secondary простаивает - и это нормально?
Может пояснишь свою позицию?

Слушай, annonymous, а какой почтовый сервер ты держишь?

Может всё дело в том, что твоим 10 пользователям, рассылающим 20 писем в день просто всё пофиг?

>> И настройки релея у него да, неочевидная.

> Гм, что можно не понять в этой строчке: 1.2.3.6:allow,RELAYCLIENT=""
> И какое слово не понятно в этом описании:
> http://cr.yp.to/qmail/faq/servers.html#authorized-relay
> Мне не хватает фантазии, чтобы придумать, что там такого неочевидного...

ОК, покажи настройки для следующей ситуации (это один сервер):
1). Из сети 10.0.0.0/24 почту могут отправлять все, куда угодно и без авторизации - это сеть умных пользователей.
2). Из сети 10.10.10.0/24 почту могут отправлять только авторизованные пользователи. Неавторизованные не могут _никуда_ (в том числе и на локальные/виртуальные домены) - это сеть глупых пользователей.
3). Кто угодно (но не забываем про пункт 2) могут отправлять письма для домена mydomain.com. Мы для них подрабатываем secondary.
4). Пользователи из сети 192.168.0.0/24 могут отправлять письма в домен anotherdomain.com пользователю so и больше никуда. Там сидит дядька, который читает все письма и форвардит их куда надо.

Не правда ли, вполне жизненный сценарий?
Ждём.

>>> Кол-во активных соединений на 25-тый порт превысило заданный предел.
>>> MTA на primary вернул 4xx.
>>> qmail недовольно хмыкнул и не пошёл на свободный secondary.
>>>
>>> Это нормально?

>> Это не просто нормально, это единственно правильное решение.

> Окуеть.
> primary умирает под нагрузкой, secondary простаивает - и это нормально?

Встречный вопрос: зачем primary вообще что-то отвечает тем, кого он не
может обслужить? Он ведь типа умирает. У него ведь типа превышен предел
соединений. Зачем он нарушает ограничение, зачем он отрывает драгоценные
ресурсы на бесполезные переговоры. А если это DoS? Он вообще прекратит
работу? А какой толк тогда в установленных для него ограничениях?
Плохой, непослушный и глупый этот primary ;) Мне его жаль.

Разбираем далее. Опять встречный вопрос: является ли ваш secondary полностью независимым, и не пересылает ли он полученную почту
обратно к primary? ;) Вы чувствуете, в чём заключается дурдом этой
ситуации? ;)

> какой почтовый сервер ты держишь?

qmail

> Может всё дело в том, что твоим 10 пользователям

Мои 2000 пользователей довольны отличной работой почтового сервера.

> Не правда ли, вполне жизненный сценарий?

Ага, соглаcен. Неправда ;) Сценарий ублюдочный. Уже одно прочтение
вызывает рвотный рефлекс и омерзение. Дело не в сценарии, конечно, а в
мыслях того человека, который до такого гадости додумался. Повторить его
для qmail несложно. Только попроси кого-нить другого. И наверное тебе
придётся что-то заплатить за это.

1

> Встречный вопрос: зачем primary вообще что-то отвечает тем, кого он не
может обслужить? Он ведь типа умирает. У него ведь типа превышен предел
соединений.

Он не умирает.
Но предел соединений превышен.

> Зачем он нарушает ограничение, зачем он отрывает драгоценные
ресурсы на бесполезные переговоры. А если это DoS? Он вообще прекратит
работу?

DoS отбивается другими средствами.

> А какой толк тогда в установленных для него ограничениях?

Толк в том, что 10 spamassassin'ов он ещё сможет пережить, а вот 100 - нет.
Поэтому 11-го клиента он послает.
Причём не с помощью TCP RST, а вежливо, разъяснив причину проблемы.

> Плохой, непослушный и глупый этот primary ;) Мне его жаль.

Мой - вполне послушный.

> Разбираем далее. Опять встречный вопрос: является ли ваш secondary полностью независимым, и не пересылает ли он полученную почту
обратно к primary? ;) Вы чувствуете, в чём заключается дурдом этой
ситуации? ;)

Ну как бы тебе это объяснить.

Ты можешь представить себе, что secondary может быть не просто перекидывальщиком писем на primary?

> Ага, соглаcен. Неправда ;) Сценарий ублюдочный. Уже одно прочтение вызывает рвотный рефлекс и омерзение. Дело не в сценарии, конечно, а в мыслях того человека, который до такого гадости додумался. Повторить его для qmail несложно. Только попроси кого-нить другого. И наверное тебе придётся что-то заплатить за это.

Ты из тех сисадминов, которые за ответы на элементарные вопросы на собеседовании денег просишь?

> Толк в том, что 10 spamassassin'ов он ещё сможет пережить, а вот 100 -
> нет.Поэтому 11-го клиента он послает.

Ну, что же, плохо это. Я бы так никогда не сделал. И потом, 10 конкурентных соединений - что-то житковато даже для маленькового
офисного сервачка.

> Причём не с помощью TCP RST, а вежливо, разъяснив причину проблемы.

TCP RST - это тоже неправильно ;) Ну, хорошо, пусть он разъянил причину,
хотя никто его об этом не просил, и что с того? Это называется
"temporary failure, try again later", правильно? Где написано, что smtp
клиент обязан тут же ломиться на следующий в списке MX? Давайте выясним
раз и навсегда, есть такой указ или нет?

> Ты можешь представить себе, что secondary может быть не просто перекидывальщиком писем на primary?

Легко. Тока вопрос был конкретно к тем админам, которые настаивали на
необходимости обращения к secondary MX в случае малейших проблем с
primary. Я спрашивал: а у вас это так?

> Ты из тех сисадминов, которые за ответы на элементарные вопросы на собеседовании денег просишь?

Ну, как же, как же...
Вопрос-то был "жизненный", а не тестово-испытательный ;)
Хочешь извращений - пожалста. Только мне такие дела противны. А всё,
что мне противно я могу терпеть исключительно только из-за хорошей
оплаты. А если, к примеру, я ловлю кайф от работы, могу и вовсе денег
не взять.

> Ну, что же, плохо это. Я бы так никогда не сделал. И потом, 10 конкурентных соединений - что-то житковато даже для маленькового офисного сервачка.

Ну замени 10 и 100 на 1000 и 10000 соответственно.

> TCP RST - это тоже неправильно ;)

Уй. А что правильно?

> Ну, хорошо, пусть он разъянил причину, хотя никто его об этом не просил, и что с того? Это называется "temporary failure, try again later", правильно? Где написано, что smtp клиент обязан тут же ломиться на следующий в списке MX? Давайте выясним раз и навсегда, есть такой указ или нет?

В RFC2821 ?

> > Ты можешь представить себе, что secondary может быть не просто перекидывальщиком писем на primary?

> Легко. Тока вопрос был конкретно к тем админам, которые настаивали на необходимости обращения к secondary MX в случае малейших проблем с primary. Я спрашивал: а у вас это так?

У всех MTA по умолчанию это так. Кроме самдогадайсякого.

> Ну замени 10 и 100 на 1000 и 10000 соответственно.

Ну ты же сам сказал, что сервер и на десяти еле жив...

> Уй. А что правильно?

Правильно молчать как рыба об лёд, до освобождения свободного
соединения. Не освободится вовремя - значит smtp клиент должен сам
отвалиться по timeout'у и продолжить попытки позднее.

> В RFC2821 ?

А точнее? Цитату, пожалуйста.
Тут говорилось о необходимости пробовать следующий в списке MX после
получения 4xx ошибки.

Читаем rfc2821:

4.2.1 Reply Code Severities and Theory

[...]

4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not
occur. However, the error condition is temporary and the action
may be requested again. The sender should return to the beginning
of the command sequence (if any). It is difficult to assign a
meaning to "transient" when two different sites (receiver- and

sender-SMTP agents) must agree on the interpretation. Each reply
in this category might have a different time value, but the SMTP
client is encouraged to try again. A rule of thumb to determine
whether a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)

Резюме: smtp клиенту рекомендуется повторять попытки, что и делает qmail.
Теперь давай своё прочтение.

> У всех MTA по умолчанию это так.

Ты не понял. Вопрос был про самостоятельность запасного MX'a.
Пересылает он полученную почту опять к primary или нет.
А что касается железной логики в стиле "все делают это", мне честно
говоря наплевать. Все пошли топиться, все захотели удавиться...
Я уважаю их право, но...

Почему не следует использовать QMail?

> одно расхождение с RFC в реализации qmail не сделано просто так.

Совершенно неважно, просто так это сделано или нет. Internet существует только потому, что все согласились пользоваться определенным сводом правил - RFC, например. Поэтому установка qmail, IMHO, эквивалент "раздражающего поведения", как это определено в FIDO policy (это если кто-то еще помнит те времена ;) ).

> Проявление голых эмоций и костности мышления.

Давай мы с тобой согласимся не переходить в нашей дискуссии о qmail на личности оппонента. Во-первых, это ничего не добавит конструктивно, во-вторых, мне просто придется грохнуть это дело, хотя я и считаю, что тема вцелом близка теме этого форума.

> Ясненько... Подсказка: слово 'password' в составе 'checkpasword' совсем не означает, что аутентификация может производится только по паролю!

Не означает. Только SASL тем не менее туда прикручивается только патчиньем исходников. Кроме того, мне вообще непонятна эта идея, но об этом подробно написал netch и я не вижу смысла повторяться.

> Во-первых никто не мешает использовать те настройки fs, которые рекомендованы для qmail.

Во-первых, никто не мешает пользоваться MTA, который не занимается всякой ерундой типа проверки pid при обработке очереди и работы с файлами в асинхронном режиме.

> Например, ext3 в режиме data=journal полностью устраивает qmail.

Угу. Когда в процессе rename() система рухнет, а после откатывания журнала файлы окажутся на старом месте но qmail не захочет их обрабатывать, потому что ему или не нравится inode или pid и почта просто потеряется, думаю, ты пересмотришь этот вопрос. ;)

> Автор qmail дал чёткие и однозначные рекомендации относительно того, как настраивать fs для надёжной работы qmail (и не только qmail, кстати).

Угу. "all filesystems suck". Это вместо того, что бы fsync() делать. Но для профессора computer science это слишком низкий полет. Он занят - поливает sendmail грязью в мэйл-листах. ;)

Кстати, вот данные о производительности sendmail из ISBN 0321115708 "Sendmail peroformance tuning". На Sun SparcStation 20 (85MHz CPU, 32MB памяти) sendmail 8.12.2 доставляет 242 сообщения в секунду.

> все согласились пользоваться определенным сводом правил - RFC, например.

Во-первых, я ещё не увидел реального списка нарушений rfc со стороны
qmail, Имеет смысл его привести, так как до сих пор в этом форуме
основное обвинение qmail сводилось к тому, что он якобы неверно
отрабатывает 4xx коды ошибок и не пробует запасные MX. Я привёл цитату
из RFC, подтверждающую правильность действий qmail, и никто пока
ничего не сказал в своё оправдание. Очень возможно, что и остальные
претензии в нарушении rfc такие же дутые. Без списка этих нарушений
разговор беспредметен.

Во-вторых, не боги пишут rfc. Простые смертные. И нередко они делают
ошибки. Иногда глупые, а бывает - очень глупые. И когда автор
конкретной софтины пытается состыковать эти глупости в реальном
проекте, и они явно не стыкуются из-за элементарных пробоев в логике
у писавшего rfc, то автор вынужден по неволе выбирать компромис,
либо полностью отбрасывать нелогичную часть, тем самым естественно
нарушая глупые требования. Грубо говоря, в начале документа вам
говорят, что нечно должно быть белым, а в конце требуют, чтобы оно
было чёрным. Реальные примеры нужно? Не будем далеко ходить и возьмём
автора того самого последнего rfc, описывающего smtp (rfc2821) -
господина J. Klensin, и почитаем рецензию Бернштейна на его
редакторские потуги по составлению этого документа:
http://cr.yp.to/smtp/klensin.html

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

Только в обмен на предметный разговор с фактами и цифрами, а не с
эмоциями и мнениями. "qmail не имеет будующего", "qmail нарушает rfc"
- это не дискуссия, это мнения и эмоции. В них содержится ноль
полезной информации.

> Не означает. Только SASL тем не менее туда прикручивается только патчиньем исходников.

Ну да, это неудивительно, учитывая, что сам стандарт моложе qmail,
и к моменту выхода qmail не имел никакого распространения. Тем не
менее, патчи работают. И я не вижу ничего странного в патчах для
софта с открытыми исходниками.

> Угу. Когда в процессе rename() система рухнет

А откуда такие данные? Я не встречался с описанной проблемой.
Чем можно подтвердить эту теорию? Кто пострадал от этой проблемы?

> Это вместо того, что бы fsync() делать.

31 fsync() я насчитал в исходниках qmail. А ты о чём говоришь?

> sendmail 8.12.2 доставляет 242 сообщения в секунду.

Ну кто же так представляет данные о производительности? С чем
сравниваетя, на каком наборе данных, в каких условиях и т.д.

>Угу. Когда в процессе rename() система рухнет,

А разве тот-же mailbox не без изъянов? Что будет, если один большой файл с письмами испортится?

Я вот тут надыбал такое сравнение, http://www.geocities.com/mailsoftware42/

Да, скорее всего оно довольно субъективно, и конечно патчи - это очевидно хуже, но по "yes" признаку функционал у qmail весьма и весьма...

> Кстати, вот данные о производительности sendmail из ISBN 0321115708 "Sendmail peroformance tuning". На Sun SparcStation 20 (85MHz CPU, 32MB памяти) sendmail 8.12.2 доставляет 242 сообщения в секунду.

А как насчет производительности SMTP серверов ?

> fagot ** (*) (06.09.2004 10:18:32)

Составители обзора не слишком компетентны (?).

Беглый взгляд показал следующие ошибки:

Exim:
* SMTP over SSL/TLS - yes (http://www.exim.org/exim-html-4.30/doc/html/FAQ_17.html#TOC308)
* POP before SMTP - yes (http://www.exim.org/exim-html-4.30/doc/html/FAQ_7.html#TOC227)
* Supported Backends - помимо LDAP/MySQL - PostgreSQL, текстовые файлы и всеразличные *db.
* Mailing list manager - yes (http://www.exim.org/howto/mailman21.html)
* Web-based Administration - yes (как минимум webmin + специализированные средства типа http://www.xmn-berlin.de/~marte/exim/ma.html)

Итого: по всем пунктам, кроме встроенных POP3/IMAP серверов - yes.

> На Sun SparcStation 20 (85MHz CPU, 32MB памяти) sendmail 8.12.2 доставляет 242 сообщения в секунду.

На главной странице проекта qmail (http://cr.yp.to/qmail.html) приведены
такие данные:

16MB Pentium-100 под BSD/OS.
8192 локальных отправок за 78 секунд. 105 в секунду.
По-моему нет смысла трогать тему производительности. qmail примерно
равен и даже несколько быстрее. Но любим мы его далеко не только за это ;)

> По-моему нет смысла трогать тему производительности. qmail примерно равен и даже несколько быстрее. Но любим мы его далеко не только за это ;)

Ты опечатался. Надо "qmail тормознее в разы, но все-таки мы его любим".

> Во-вторых, не боги пишут rfc. Простые смертные. И нередко они делают ошибки.

Угу. Только почему-то все остальные производители MTA соглашаются поддерживать их, а Бернштайн себе на уме. Я уже сказал - бессмысленно обсуждать SMTP - это плохой, устаревший стандарт, но "худой мир лучше доброй войны", поэтому лучше, если все ему следуют а не каждый расширяет и интерпретирует разные его куски так, как ему вздумается.

> И я не вижу ничего странного в патчах для софта с открытыми исходниками.

А я вижу. Если автор потерял интерес к продукту и не желает изменить лицензию так, что бы продукт можно было развивать и улучшать, проще пользоваться чем-то другим, благо альтернатив хватает.

> А откуда такие данные? Я не встречался с описанной проблемой. Чем можно подтвердить эту теорию? Кто пострадал от этой проблемы?

выключи машину в момент доставки и увидишь. пострадавшим будешь ты, если у тебя это понтанно случится.

> А ты о чём говоришь?

об асинхронной доставке в локальные ящики. за подробностями обратись в упомянутую мной книжку.

> Ну кто же так представляет данные о производительности? С чем сравниваетя, на каком наборе данных, в каких условиях и т.д.

Подробности - в книге.

> признаку функционал у qmail весьма и весьма...

я сформулирую критерии? например - наличие API для расширения функционала доставки писем. ;) Это я к тому, что критерии можно формировать как угодно.

> почитаем рецензию Бернштейна на его редакторские потуги по составлению этого документа

Я буду рад, если Бернштайн разработает что-то лучше, засабмитит это в IETF и пройдет процедуру сертификации. Пусть это станет стандартом.

> Ты опечатался. Надо "qmail тормознее в разы, но все-таки мы его любим".

И всё? А говорит ещё "не будем переходить на личности". А что ещё
остаётся обсуждать кроме твоей личности, при такой дискуссии? ;)
Ты мужчина или нет? Слово сказал - отвечаешь? Или продолжаешь
болтологией заниматься?