Русскоязычное руководство по установке почтового сервера Qmail

поколение пепси выбирает sendmail-x ;)

Полезно. :)

А зачем alternatives придумали

Скажите господа, не флейма ради. Под какие задачи нужно выбирать sendmail и под какие будет лучше мне изучить qmail?

Гут Гут. Помню было время ставил кумейл. Из доков были тока отрывки

> Под какие задачи нужно выбирать sendmail и под какие будет

> лучше мне изучить qmail?

Оба подходят под задачу - поудалять гланды через задницу и убить много свободного времени.

Под задачу - работать, надо выбирать postfix.

ВЪЯБЛОЧКО! То что искал+)

>Если вы работаете с сервером через удаленную консоль, например ssh или telnet, то чтобы не набирать все команды в ручную, можно скопировать нужную команду в буфер обмена, а затем (на примере ssh-клиента PuTTY) в консоле просто нажать правую кнопку мыши и текст из буфера обмена вставиться в командную строку автоматически. (Прим. перевод.)

Чума! А про то, что мышку можно держать одной рукой, а не двумя, почему не написал переводчик?

exim, переписать алиас с root на юзера и все настройки. все остальное работает из коробки

http://www.qmail.org/not-open-source.html

Лишь Exim рулезен. :)

Интересно, а обновляться оно будет?..

Хотя, конечно, очень хорошая дока по qmail.

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

И трахаться с прикручиванием через задницу какой-нибудь новой мега-фичи?

На дворе не 1997 год, господа! Ставьте postfix и не компостируйте мозги.

>Нафига этот qmail нужен?

Нафиг не нужен. И документация нафиг надо. Но речь сейчас _не об этом_, верно?

> Но речь сейчас _не об этом_, верно?

А еще речь о том, что во FreeBSD принято ставить из портов, а не руками.

Интересно, будет ли оное 2.0 от дядюшки Бернштейна?

Если оно и будет, то будет таким же кривым в настройке и с такой же лицензией. Короче: в топку. Хочется трахаться -- трахайтесь с qmail, а если надо работать - используйте postfix.

>Хочется трахаться -- трахайтесь с qmail Глупый совет по содержанию, а по форме неприличный.

>а если надо работать - используйте postfix. Лучше сказать: "я в работе использую postfix и другим рекомендую", а лозунги с изложением истины в последней инстанции из сомнительных источников есть отстой.

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

Ага "бинарный текстовый конфиг"(с) сендмайла - это очень просто! )

> Ага "бинарный текстовый конфиг"(с) сендмайла - это очень просто! )

А ты в В cf файл не лазь :) Да и ничего бинарного там нету, есть только макрокоманды языка м4 :)

Редактируй sendmail.mc и из него него собирай sendmail.cf.

mc файл достаточно прост (если ничего хитрого не накручивать)

И причем тут это?

> Если оно и будет, то будет таким же кривым в настройке

Это у qmail кривая настройка? Там всё понятно и логично.

>Это у qmail кривая настройка? Там всё понятно и логично.

Куча файлов - это "понятно и логично"?

А как прикрутить к qmail пользователей из ldap или mysql? А как, не занимаясь идиотизмом с qmail-smtpd, прикрутить clamav одновременно со Спамообороной?

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

единственные проблемы - это разные патчи и версии, но это легко решается при наличии в вашей системы /dev/brains и нормальном mknode на /dev/hands =)

в общем кумыл рулит.

P.S. Юзал постфикс - не то, не нравица, юзал exim - тоже не нравится, sendmail - хм, категорически отрицаю уже 5 лет, может менталитет такой у меня - хз ;), кумейл рулит! ;)

P.P.S. ИМХО ;)

Полнофункционального?! Ребята ничего не путают? Вот мои небольшие заметки: 1. Голый qmail не умеет практически ничего, кроме получения почты 2. Патченный неизвестно кем qmail имеет гораздо большую вероятность получить какую-то багу, чем тот же postfix, который пишет один(?) человек и который тоже известен прекрасным качественным кодом (libwrap тоже он написал, к примеру. а это о чем-то, да говорит) 3. qmail нельзя распространять с патчами. 4. Для добавления какой-либо простейшей функции частенько его нужно патчить/компилировать/использовать внешние обработчики очереди (попробуйте хотя бы сделать bcc для входящей/исходящей почты) 5. Человек, сделавший такие log-файлы, ээээ...не знаю, как его назвать (рекомендую на нормальном траффике отловить движение письма какого-нибудь или вообще хоть _что-нибудь_ понять из его логов) 5. Документации нормальной нет (или я плохо искал). Кругом какие-то обрывки по десять строк на одни и те же темы. 6. Не вижу ни одного преимущества qmail, хотелось бы услышать от кого-нибудь. 7. По тестам скорости qmail сливает всем (кроме sendmail, afair). Для желающих найду ссылку. 8. Ну и еще масса всякие мелких претензий, которые озвучены давно :) 9. А так, в принципе, работает.

-- hiddenman

Чертовые TeX paragraphs w/quiting по-умолчанию :-E Надеюсь, прочитать все смогут?

p.s. Еще добавлю, что даже на незначительнной нагрузке он делал просто невероятный LA какой-то. Уж не знаю, где ручка для регулирования этого.
--
hiddenman

>А как прикрутить к qmail пользователей из ldap или mysql? А как, не занимаясь идиотизмом с qmail-smtpd, прикрутить clamav одновременно со Спамообороной?
Легко и непринужденно.

1. Качаем LDAP (+еще куча всего вкусного) патч c www.nrg4u.com.
2. Качаем http://www.inter7.com/?page=simscan
3. Ну и SpamAssasin+ClamAV.

Собираем. Последовательно. В доках все есть.
Да! ClamAV тоже неплохо работает из под daemontools. Как и spamd.
ОЧЕНЬ стабильно.

Нее, в пятницу буду qmail сносить со всех оставшихся серверов, на которых еще нету postfix'а. Хватит. Все эти cat ./log/main/current | tai64nlocal | less затрахали вусмерть. Все эти пересборки и бесконечные патчи - фф топку.

И daemontools кстати давно уже устарел. Нормальный чувак один написал runit (http://smarden.org/runit/): ставится через apt-get install, возможностей больше, а трахатни меньше. Еще бы кто-то djbdns переписал и было бы ваще щасье :)) Кстати, у меня djbdns из под runit работает. А daemontools вв топпку тоже

> Под какие задачи нужно выбирать sendmail и под какие будет лучше мне изучить qmail?

Кратко:
1) sendmail
- поставить и не думать о настройках
- требуется почта для одного домена или симмитричных доменов (типа webmaster@anyhost.com - это все один ящик)
- предоставляемые почтовые сервисы вполне устраивают
2) qmail
- большие почтовые сервера (пример mail.com, mail.yahoo.com ... по ошибкам и другим заголовкам явно видно что там стоит qmail)
- независимые виртуальные хосты
- тонкая настройка под себя

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

В моем опыте был случай (давно правда было)... Cтоял sendmail на машинке PII-400/128. Клиентов было всего порядка 10,000. Загрузка со временем стала подниматься просто неописуемая, доходило дело что на машину залогиниться просто не мог. Все дело оказалось в том что письма складывались в mbox. На помощь пришел qmail, который установился с первого раза и достаточно быстро... Познакомившись немного поближе с qmail быстренько сделал virtualhosts, чего в sendmail сделать просто не мог (приходилось делать алиасы, например для каждого webmaster@host.com, а хостов более 500). Как результат - загрузка сервера упала практически до нуля и сервер прожил аж до 2003 года. После чего Verio.net просто дали время на то что бы перенести все на новую машину ибо это железо уходит на свалку (пришлось сделать свой src.rpm что бы ставить быстрее). Но больше всего qmail понравился тем, что я могу настраивать ящики как мне того захочется (у меня своя система аутентификации, своя система обработки почты и т.д., т.е. я могу почту насраивать как я хочу, а не как мне позволяет MTA).

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

>Все эти cat ./log/main/current | tai64nlocal | less затрахали вусмерть.

А головой подумать? Не нравится multilog - настрой вывод в syslog MAIL. Две минуты работы.

>Все эти пересборки и бесконечные патчи - фф топку

О чем ты говоришь? Или начитался идиотских советов, типа: "Качаем LDAP (+еще куча всего вкусного) патч". Тогда тебе точно надо postfix ставить (ведь под него так много замечательных хауту - делай раз, делай два, а думать не обязательно)

Главное достоинство Qmail - чрезвычайно продуманная архитектура. Если ты ее не понял - Qmail не для тебя. А если один раз разобрался - ни какая документация не нужна больше. Все логично, понятно, реализовано именно так как ты ожидаешь. Нужна доставка для аккаутнов из LDAP - ни каких патчей, ни каких пересборок. Говоришь Qmail'у, чтобы использовал не собственный MDA, а внешний (maildrop, procmail - что больше по душе). А, уже, внешний MDA настраиваешь брать mailbox из LDAP, MySQL или откуда у тебя фантазия брызжет. Нужна при этом тонкая фильтрация, антивирус - все в твоих руках настраивай procmail.

Нужно фильтовать почту не на этапе local delivery, а на этапе smtp сессии - опять ни каких проблем. qmail-smtpd после отработки smtp envelop (но до окончания smtp сессии) вызывает qmail-queue. Встраивай между ними все что твоей душе угодно (лично я пользуюсь как готовыми решениями, типа qmail-qfilter, так и собственными perl скриптами на 40 строчек). Нужна более длительная обработка - ни кто не мешает построить цепочку из 5 - 10 фильтров между qmail-smtpd и qmail-queue.

Я вовсе не призываю всех делать так-же. Просто хочу показать изящество, красоту и простоту решений на Qmail.

По мне - Qmail пластелин, из которого я легко вылеплю почти все что угодно.

> Все эти пересборки и бесконечные патчи - фф топку.

интересно посчитать кол-во этих бесконечных патчей :)
А по поводу пересборки - делается .src.rpm или нечто аналогичное для сответствующего типа пакета и пересборка превращается в легкую процедуру, нетребующую особых усилий, как для мозгов так и для пальцев. Зато труд щедро вознаграждается благодарностями клиентов.
Если же вполне хватает простой доставки письма в ящик - то согласен, что время затраченное на настройку qmail может показаться расточительным (только многоразово ли?).

Чувак, если у тебя есть гора времени чтобы лепить из пластелина, а за тебя рад. У меня ее нет. Я решение на postfix + courier pop3/imap(-ssl) + mysql + spamassassin поднял вместе с чтением how to примерно часа за 3. Чтобы то же саме сделать с qmail с нуля, надо не 3 часа, а 3 дня. А если еще возникнут вопросы типа посылать на 3 буквы почту с доменов без обратных зон не скачивая ее, а еще в процессе установления smtp соединения (helo|ehlo), забороть bounces которые рассылаются по каждому чиху и еще много чего что умеют нормальные mta, но в qmail делается либо патчами от х.з. кого, либо написанием "перловых/питонячих/башевых" скриптов на 40 строчек, то в сумме время, потраченное на наточку qmail никак себя не окупает, ибо другие MTA, да тот же postfix, по большому счету ничем не хуже, а умеют все это из коробки и настраиваются правкой всего лишь 2х файлов (postfix) - main.cf и master.cf, а так же, в отличие от qmail отлично документированы.

qmail может себе mail.ru позволить поставить и точить его до посинения. У них наверняка от оригинального qmail уже тока #include <stdion.h> остались.

Это тоже путь, но не мой.

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

>qmail может себе mail.ru позволить поставить и точить его до посинения. У них наверняка от оригинального qmail уже тока #include <stdion.h> остались.

Вызывающе неверная информация. Qmail в Mail.ru не используется.

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

Угу. И получается непереносимое решение, которое даже повторить не получится по причине того, что все на патчах и соплях.

Желающие есть!
Ссылку в студию, пожалуйста.

> 3 дня это в том случае когда этот qmail уже знаешь вдоль и поперек и просто делаешь какое-то решение, скажем с нуля.

Наверное имелось ввиду часа 3 а не дня 3.. Один раз я потратил 3 дня что бы написать свою систему аутентификации, учета, и управления ящиками а-ля vuser..., только с нужными для меня параметрами... Т.к. система написана на перле, то простого копирования на новые сервера (что занимает даже не 3 часа, а минуты или секунды) пока вполне хватало.

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

У меня обычно это выглядит так: собрал, поставил, отконфигурял и годами работает. При необходимости (желание клиента) пишем соответствующий обработчик (часа 2-3) и все довольны...

> qmail может себе mail.ru позволить поставить и точить его до посинения.

Не помню использовал ли mail.ru вообще когда-то qmail. Но mail.yahoo.com судя по хидерам до сих пор пользует этот MTA, mail.com так же... Наверное они просто идиоты, что бы свой бизнес делать на том что нужно точить и патчить до посинения... А может просто дело в том что не нужно его точить и патчить, а гораздо выгоднее потратить пусть даже 3 дня, и потом быть уверенным в своем бизнесе? Хотя я думаю что потратили они гораздо больше чем 3 дня если включать исследования предшествующие окончательному выбору MTA.

Я полностью согласен что дома пользовать qmail необходимости нет (хотя дома у меня тоже он работает), но для больших почтовых серверов считаю что вполне достойная система, хотя и не единственная, но, как мне кажется, наиболее гибкая из всех знакомых мне систем (sendmail, smail, zmailer, CommuniGate, exim, postfix, xmailserver, courier).

А если нужно на скорую руку, то гораздо быстрее, выгоднее и правильнее будет ставить то, что знаешь...

>Не помню использовал ли mail.ru вообще когда-то qmail. Но mail.yahoo.com судя по хидерам до сих пор пользует этот MTA, mail.com так же... Наверное они просто идиоты, что бы свой бизнес делать на том что нужно точить и патчить до посинения... А может просто дело в том что не нужно его точить и патчить, а гораздо выгоднее потратить пусть даже 3 дня, и потом быть уверенным в своем бизнесе? Хотя я думаю что потратили они гораздо больше чем 3 дня если включать исследования предшествующие окончательному выбору MTA.

Хорошо. Приведите аргументы, чем же так лучше qmail по сравнению, скажем, с postfix / exim / communigate. Но аргументы, а не ссылки на mail.com / mail.yahoo.com.

>Чтобы то же саме сделать с qmail с нуля, надо не 3 часа, а 3 дня.

Чувак, это ТЕБЕ надо 3 дня. А мне достаточно часа.

>но в qmail делается либо патчами от х.з. кого

Чувак, это ТЫ не знаешь от кого и какие патчи. А я патчами на qmail не пользуюсь принципиально (акромя, естественно, #include <errno.h>, но это и не патч вовсе).

Дык, тебе ли судить о qmail?

>Хорошо. Приведите аргументы, чем же так лучше qmail по сравнению, скажем, с postfix / exim / communigate.

Последняя версия qmail-1.03 датирована 06-1998. Посчитай, сколько раз нужно было бы проапгрейдится (в т.ч. по критическим уязвимостям), если бы у тебя стоял все это время не qmail, а postfix / exim / communigate. (Это ответ тем, которые вякают, что с qmail, якобы, нужно "постоянно тра--ся")

Какая еще программа (не только open source, но и из коммерческих) имеют, хотя бы, отдаленное подобие "The qmail security guarantee. In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail"? У всех как раз наоборот - AS-IS с отказом от любых гарантий/ответственности.

Эти $500 за 9 лет так ни кто и не получил...

IMHO, этого более чем достаточно, что бы потратить некоторое время на изучение этого замечательного, но, правда, чуть-чуть не такого как все остальные, MTA.

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

А мы лучше согласимся... :)

> Хорошо. Приведите аргументы, чем же так лучше qmail по сравнению, скажем, с postfix / exim / communigate. Но аргументы, а не ссылки на mail.com / mail.yahoo.com.

1) qmail позволил мне сделать собственную систему smtp/pop/imap аутентификации (у меня своя база в разработанном мною формате, хранящая список доменов и ящиков). Правда нужно так же справедливости ради сказать что imap - не входит в состав qmail. Я пользую BincImap, который полностью совместим с принципами qmail.
2) я могу управлять почтой и обрабатывать оную практически на любом этапе так как это нужно клиенту не прилагая особых усилий для создания соответствуюих обработчиков (как правило не более 10 строк кода на perl).
3) легкость программ (ни один из известных мне MTA не весит меньше или хотябы столько же столько qmail)
4) самое главное наиболее гибкая настройка по сравнению с тремя перечисленными выше MTA (хотя это наверное входит в п.п. 1 и 2).
5) можно принять за аргумент простота логики как работы так и настроек. Что бы понять все тонкости достаточно взглянуть на big images (там кажется 3 или 4 картинки всего) и картинка становится настоль очевидной что можно писать достаточно сложные конфигурации практически с первых же дней работы с этим MTA.

Это первое что пришло на ум для сравнения со всеми тремя... Можно отдельно по каждому еще пройтись и выдать еще несколько пунктов...

Но опять же.. Я не говорю что postfix/exim/communigate - плохие поделия, они, за редким исключением (у последнего есть маленькая проблемка с виртуальными хостами на одном IP), вполне достаточны для решения стандартных задач при _стандартных_ условиях.

> Последняя версия qmail-1.03 датирована 06-1998.

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

каке-то камни в огород qmail пошли, кину и свои 5 копеек:

я люблю qmail за то что у него все работает из коробки, ставим qmail, сразу появляется web-морда для почты и для заведения ящиков, где такое есть (cgp я отвергаю)?

Настоящее удовлетворение можно получить только после 3-х летней "life with qmail", перейдя за пару дней на postfix от того, что qmail просто достал своей тупостью. Мертвый продукт 5-и летней давности. Что тут еще сказать? Патч на патч и после этого еще 5 патчей - это не серьезно.

-- sbr

честно говоря, довольно долго обслуживал и ставил сервера с qmail и sendmail потом как то посмотрел exim с тех пор выкидываю где возможно нафиг qmail или sendmail лучше exim ничего не видел !!!

>Нафига этот qmail нужен?

Для легкого (~200к) релейного (чисто переправить почту от своих пользователей, имеющих ящики на стороне) SMTP сервера с проверкой на вирусы clamav`ом. Остальные MTA тяжеловаты для столь простой задачи. Кстати, может кто альтенативу подскажет.

>Но я думаю что сейчас большинство MTA уже достаточно надежны

На чем основана подобная уверенность? Из того, что в sendmail нашли и залатали 1001 дырку еще не следует, что она была _последней_ .

Как раз - наоборот: про программу с такой богатой "дырявой" историей можно гарантированно сказать, что дыры в ней обязательно еще будут находить. И много дыр. А про сколькие дыры разработчики даже не знают, но их втихаря эксплуатируют отдельные личности? Лишь изредка, наверное случайно, про такие уязвимости становится известно и эти дыры, наконец, закрывают. Нужны примеры: sendmail, 15 лет незакрытая дыра с удаленным исполнением, одному Богу ведомо сколько хостов с sendmail поимели за это время через нее.