On Fri, Oct 16, 2015 at 09:13:14AM +0300, Valentin Nechayev wrote:
> Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail +
> roundcube":
>
> > >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > > sendmail очень неудобен и сложен в настройке, особенно если требуется
> > > гибкость,
> > Неправда. Так может говорить только тот, кто не читал документацию
> > на используемый софт, но с exim или postfix ситуация такая же:
> > неудобно тому, кто доку не читает,
>
> Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
> его использования в продакшене и десятков патчей на разные темы) ты
> опровергать не будешь? Так вот - я категорически подтверждаю слова
> cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
> выходит за рамки простой стратегии "накидать опций по ману в
> ${hostname}.mc и вызвать make", и эта сложность далеко выходит за
> пределы того, что определяется "естественными" факторами сложности
> тематики. По пунктам:
Раз пошла такая пьянка -- режь последний огурец.
Я как бы тоже sendmail использую года так с 1995 во всеяких сложных
конфигурациях, postfix -- примерно с 2003, ну и еще и exim несколько
меньше. Так что тоже выскажусь.
в простых ситуациях все три продукта ставятся и работают. и не
ломаются. в конце концов это же не qmail (хотя мне встречались и его
апплогеты, может конечно это был эффект утенка, а может просто иного
сложно ждать ударенных безопасностью и не понимающих ее связи с
реальностью).
sendmail в vps я не использовал, но на железе уровня 2005 года спамер,
сперший пароль, наплодит 30 тыщ писем в очереди, но проблемой будет не
тормоза системы, а попадание в спамлисты.
да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
выбрать набор каких-то фиксированых проверок и их порядок. если надо
что-то нестандартное -- патчи сырцы!
сейчас найти рецепты для sendmail кажется несколько сложнее.
postfix/exim в последнее время по фичам несколько подтянулись
(научились наконец DSN без патчей!), но у всех трех с SRS не очень
хорошо.
в плюсы postfix/exim можно записать sender email verify из коробки --
к sendmail нужно через milter крутить.
в минусы же postfix -- логи хуже sendmailовских. ну и вообще, общую
переусложненность postfix:
postfix 48387 51021 51021 51021 0 I - 0:00.02 pickup -l -t fifo -u
root 51021 1 51021 51021 0 Ss - 0:18.19
/usr/local/libexec/postfix/master -w
postfix 51023 51021 51021 51021 0 I - 0:14.45 qmgr -l -t fifo -u
postfix 51218 51021 51021 51021 0 S - 0:00.02 smtpd -n smtp -t
inet -u -o stress=
postfix 51219 51021 51021 51021 0 S - 0:00.01 anvil -l -t unix -u
postfix 52607 51021 51021 51021 0 S - 0:00.01 trivial-rewrite -n
rewrite -t unix -u
postfix 52677 51021 51021 51021 0 I - 0:00.01 cleanup -z -t unix
-u
postfix 52680 51021 51021 51021 0 I - 0:00.01 smtp -t unix -u
postfix 52682 51021 51021 51021 0 I - 0:00.01 smtp -t unix -u
postfix 52684 51021 51021 51021 0 I - 0:00.01 pipe -n dovecot -t
unix flags=DRhu user=mailnull:mailnull argv=/usr/local/libexec/dovecot/deliver
-d ${recipient}
postfix 52709 51021 51021 51021 0 S - 0:00.02 smtpd -n smtp -t
inet -u -o stress=
postfix 52793 51021 51021 51021 0 I - 0:00.01 smtp -t unix -u
postfix 52795 51021 51021 51021 0 I - 0:00.01 smtp -t unix -u
куча каких-то демонов, как-то перадающих задание друг другу,
сквозной queue-id заводится достаточно поздно и если отлуп происходит до
его заведения (из-за rDNS у отправителя или еще по каким подобным причинам)
то при большом потоке почты искать причину можно до морковкиного заговения.
да, я в курсе, что postfix писался для того что бы управлять рассылками на
пень-100.
только те, кому такое (смасштабированное) нужно сейчас -- об этом спрашивать не
будут.
ну и заодно камень в огород dovecot -- тоже переусложненный в устанвке продукт,
на мой взгляд,
требующий для своего функционирования кучу различных пользователей, отличных
еще и от постфиксовых,
если склероз не врет. в этом плане cyrus, работающий целиком от одного
пользователя --
гораздо проще и удобней.
в общем, несмотря на то, что весь интернет полон шпаргалками на тему
"postfix+dovecot+mysql+вебморда" -- я его настоятельно не советую.
и да, SQLite не советую тоже, как я понял у него очень плохо с совместным
доступом.
тут надо выбирать
- или berkley DB
- или нормальный SQL
- или спрашивать про пользователей у IMAP
> 3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
> и/или рефакторингу как минимум последние 30 лет. Для софта это просто
> безумный срок.
> Кто будет возражать - прошу вначале прочитать и понять логику таких
> замечательных функций, как getrequests(), sendall(), dropenvelope(),
> описать её словами. Продолжить содержимым файла queue.c, разобрать
> тёмные моменты логики.
я разбирался, ничего, жив остался.
> 5. Настройка по умолчанию несопровождаема кроме установки вида
> "получать daily run output в локальный ящик". Начать с дефолта
> LogLevel=9, который не пишет завершения заданий (и от этого нельзя
> вести анализ доставки по логу).
Шо?
Oct 16 13:50:35 inter sm-mta[96000]: t9G9oP4x095819: to=leader-...@yandex.ru,
delay=00:00:04, xdelay=00:00:01, mailer=esmtp, pri=203421, relay=mx.yandex.ru.
[213.180.204.89], dsn=2.0.0, stat=Sent (Ok: queued on mxfront3j.mail.yandex.net
as 1444989035-eeXLwLnCXA-oYK8vqd7)
лог -- по дефолту.
В общем, моя кочка зрения:
postfix -- нафиг
в простых случая и exim и sendmail справятся
если думать лень и хочется готовых рецептов и менять *точно* ничего никогда не
будет (как и усложнять) -- наверное exim проще
если светит в перспективе усложнение (вообще-то оно почти всегда светит) --
лучше потратить время на sendmail.
REFAL конечно требует несколько выворачивать мозг, но это, вообще-то полезно.
