под нагрузкой postfix не форкается на каждое письмо.

> из них 1500 - апачи, почта рулится через postfix-cyrus-ldap

Говорю же, читай. Про таких как ты админов написано.

> под нагрузкой postfix не форкается на каждое письмо.

Мне плевать - форкается или нет. Я спрашиваю, сколько он принимает в
секунду в среднем в час-пик.

IMHO у него на одном тазике вместе с апачами, лдапом, цирусом, и after queue фильтрами больше 20m/s не может быть в принципе.

Спам на postmaster.

Народ, а кто-нибудь может помочь резать спам, который валится на postmaster (с поддельными адресами) средствами самого postfix (2.1, в перспективе 2.2)?

Насколько я понимаю, почта на postmaster не обрабатывается всякими restrictions, только header_check, так?

Как оно говорится: "Сильно не пинайте".

Единственное отличие "postmaster" от любого другого адреса, в том, что разрешено не указывать доменную часть адреса в rcpt. Все.

А тупо резать все на postmaster нельзя: 1) это явно запрещено rfc 2) а на какой адрес вам писать о проблемах (100% abuse@ у вас тоже нет).

>Мне плевать - форкается или нет. Я спрашиваю, сколько он принимает в секунду в среднем в час-пик.

тебе голый посфикс или в купе с cyrus, spamd и amavis ? вместе около 200-200к в сутки

>Борисычу пишу, так как резко он планку поднял - со ста до пяти тысяч. Вот и спрашиваю: Шура, сколько вам надо для полного счастья? ;)

я планку не поднимал. сказано же: на каждое письмо 3 лишних форка (это минимум) расточительно, а про 10-20k в секунду - это откровенный гон.

>Говорю же, читай. Про таких как ты админов написано.

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

> вместе около 200-200к в сутки

Ну, и для чего ты запросил 5000 форков в таком случае? Давай согласимся,
что 50 форков в секунду для твоих объёмов будет достаточно с баальшим
запасом. А теперь вернёмся к твоему утверждению о том, что форки - зло
согласно твоей идеологии из-за потери производительности. Не хочешь
обратно свои слова взять?

> а про 10-20k в секунду - это откровенный гон.

В смысле, цифра занижена? Я знаю. Линукс, конечно же, может гораздо
больше на хорошем железе.

И все же, в чем практическая польза от DSN, если не все мыльницы в интернете поддерживают его? Все равно же со 100% достоверностью не получишь notification

> в доки djb тыкать. оттуда следует только то, что не нужно почту на
спам вообще проверять

djb держит на своих серверах тысячи списков рассылки. 10 миллионов
юзеров. Ты много там спама видел?

Особой пользы нет, вред есть. DSN нужен примерно 1 из 2000 клиентов.

Это где у djb 10M ящиков??? Дайте ссылку почитать

Странное вообще обсуждение. Ну если будет писем больше, чем может переварить мой почтовый сервер, ну сделаю 2 компьютера вместо одного, пропишу в djbdns, чтобы он возвращал первичный MX на случайный из них, и в чем проблема? Мало будет двух - сделаю три. или четыре.

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

> Это где у djb 10M ящиков??? Дайте ссылку почитать

Для "писателей" в третий раз: http://cr.yp.to/qmail/antispam.html ;)

"mail system handles mail for tens of millions of people."

То бишь для десяткОВ миллионов.

>"mail system handles mail for tens of millions of people."

Вы слишком буквально понимаете слова своего гуру, это всего лишь его домыслы на тему, что "традиционные" методы фильтрации спама не работают на таких объемах. Вы себе представляете стоимость системы на 10M Ящиков? Бедному профессору это не потянуть. Если считаете, что я не прав, то с удовольствием приму ссылку на MX построенный на qmail обслуживающий 10M юзеров.

> Бедному профессору это не потянуть.

University of Illinois at Chicago.

> ссылку на MX построенный на qmail обслуживающий 10M юзеров.

a.mx.cr.yp.to

Ну, а самым первым был hotmail ещё в далёком 1997-ом. Тоже не меньше
юзеров было.

>> а про 10-20k в секунду - это откровенный гон.

> В смысле, цифра занижена? Я знаю.

Чтобы вы больше не спорили, на P4 2.0 на пользовательском ядре 2.6.10 в течении одной секунды выполняется 4051 форк. Выполнилось бы и больше, но ядро говорит "Resource temporarily unavailable".

Чтобы мы больше не спорили посмотри, что там в манах пишут про лимиты.

но даже твоих 4051 форков Борисычу хватит чтоб перемолоть в 100 раз
больше почты, чем у него сейчас ;)

>но даже твоих 4051 форков Борисычу хватит чтоб перемолоть в 100 раз больше почты, чем у него сейчас ;)

ну что же, запусти сначала у себя чистый (хотя сейчас все кому не лень используют big-todo) qmail так чтобы из .qmail запускалась проверка на спам и вирусы, а потом maildrop в зависимости от результатов проверки раскидывал бы все по разным каталогам и уди(а)вись, если получится принимать хотя бы полтинник писем в секунду, я был бы рад узнать характеристики сервера, а так же его vmstat.

> Чтобы мы больше не спорили посмотри, что там в манах пишут про лимиты.

Согласен, про лимиты я как-то не подумал. После поднятия получилось порядка 6700 форков - другие процессы в это время активно подрабатывали.

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

Что-то мне подсказывает, что одна проверка на вири требует на порядки больше ресурсов, чем один форк. А 10k проверок на вири затребуют соответственно на 10k*порядки больше ресурсов, чем 10k форков. Хоть параллельно их запускай, хоть последовательно.

Следовательно, если машине удается проверить 50 писем в течении секунды на наличие в них хотя бы одного из 122382 вирей (циферь от каспера), то 50 форков на этом фоне просто потеряются.

Совершенно верно подмеченно..

запусти и проверь. год назад сам проверял, dual-mta работало лучше.

> сейчас greylisting и backup mx реально помогают

Ты на primary просто не принимаешь коннекты, или всем отвечаешь 4xx?

Если первое, то все прекрасно дойдет на backup.

Если второе, то почта с qmail без патча до тебя _никогда_ не дойдет. Такое поведение полностью согласуется со всеми rfc, существующими как на момент написания qmail, так и сейчас. Если ты провайдер в России, то жди отзыва лицензии после жалоб, поскольку нарушаешь требования к электросвязи.

А упомянутый патч добавляет проверку для соответствия rfc2821: в случае 554 сразу баунсить сообщение. И добавляет workaround для таких rfc-ignorant серверов, как твой: при 4xx пытаться отправить через следующий MX.

Кстати, отвечая 4xx в приветствии ты нарушаешь rfc2821 (MUST be 220 or 554). Всегда отвечая 4xx на mail|rcpt на primary ты препятствуешь связности сети, что недопустимо, если предоставляешь кому-либо почтовый сервис.

И, естественно, все нападающие на qmail забывают требование rfc: "_MUST_ delay retrying after _one_ attempt has failed". И при каждой попытке "Multiple MX records contain a preference indication that _MUST_ be used in sorting".

> запусти и проверь. год назад сам проверял, dual-mta работало лучше.

Было бы на чем проверять. У меня почтовый вервер только из-за каспера может принять до 5 писем в секунду. Старичок селерон :)

да что тут считать, уже давно все посчитали. первые же ссылки, проверяли хоть и давно, но актуальности не потеряло:
http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/vsqmail.html
http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html

Hiddenman

> Если ты провайдер в России, то жди отзыва лицензии после жалоб,

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

> Неприем почты с хостов без реверса нарушение, или нет?

По rfc -- нет. Если хост не имеет fqdn, он обязан представиться ip-адресом.

С точки зрения "закона" меня все больше местное регулирование волнует, но могу и уточнить, изменилось ли что в России. Хотя это врядли.

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

> По rfc -- нет. Если хост не имеет fqdn, он обязан представиться ip-адресом.

речь не про helo, а просто про хост без реверса (кстати, он не может представиться IP-адресом, он может представиться IP-адрес-литералом).

> И, естественно, все нападающие на qmail забывают требование
> rfc: "_MUST_ delay retrying after _one_ attempt has failed".

Все бы хорошо, но ты не дочитал:

5.3.4 Reliable Mail Transmission

the mapping can result in a list of alternative delivery
addresses rather than a single address, because of (a)
multiple MX records, (b) multihoming, or both.To provide
reliable mail transmission, the sender-SMTP MUST be able
to try (and retry) each of the addresses in this list in
order, until a delivery attempt succeeds.

Далее вроде как, как раз зацепка:

However, there MAY also be a configurable limit on the number
of alternate addresses that can be tried.

Но надо дочитывать:

In any case, a host SHOULD try at least two addresses.

>Единственное отличие "postmaster" от любого другого адреса, в том, что разрешено не указывать доменную часть адреса в rcpt. Все.

А почему тогда спам проходит легко через {client,recipient,helo}restrictions, через которые не должен?

>А тупо резать все на postmaster нельзя: 1) это явно запрещено rfc 2) а на какой адрес вам писать о проблемах (100% abuse@ у вас тоже нет).

От чего же нет? Есть. Но он alias на postmaster, тот на human's адрес, что роли не играет. Или нет? А что значит тупо? И как можно вообще резать?

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

Только для тебя ;) Тест на домашней машинке с IDE диском. Пускаю тест
и пишу результат одновременно.

Запускаем приём 5000 писем с вирусом Eicar. Они режектятся на уровне 
очереди. Проверка через clamd.

$ time for i in `seq 1 5000`; do /var/qmail/bin/qmail-inject -a me < ~/TEST-VIRUS-MAIL; done >&/dev/null

real    1m11.918s
user    0m12.010s
sys     0m13.400s

Считаем: ~70 писем/сек.

Тестируем отдельно фильтрацию спама на обычном письме размером 3кб.
В базе около полумиллиона образцов спама.

$ time for i in `seq 1 5000` ; do /usr/local/bin/bogofilter <~/TEST-MAIL-GOOD; done

real    1m13.018s
user    0m55.180s
sys     0m17.840s

Та же картина: ~70 писем/сек.

Тестируем всё вместе - проверку на вирусы и на спам. Всё то же письмо.
~/.qmail выглядит так:

|/var/qmail/bin/condredirect spam /usr/local/bin/bogofilter                                                             
./nsmail/Inbox

time for i in `seq 1 5000`; do /var/qmail/bin/qmail-inject -a dmitryv <~/TEST-MAIL-GOOD; done >&/dev/null

real    5m10.338s
user    0m12.320s
sys     0m13.820s

Итого: ~16 писем/сек.

Процессор во время исполнения занят не более чем на 40%.
Смотрим vmstat:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  1   6300  25388 139668  69572    0    0    82    72  129    46  5  1 94  0
 0  2   6300  23712 139676  71284    0    0    82    72  129    46  5  1 94  0
 3  0   6300  21612 139680  72960    0    0    82    73  129    46  5  1 94  0
 2  1   6300  22048 140384  71792    0    0    81    81  129    50  5  1 94  0

И видим, что основной затык - I/O операции. 

Параметры машинки:
$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 12
model name      : AMD Athlon(tm) 64 Processor 2800+

~$ cat /proc/meminfo 
total:    used:    free:  shared: buffers:  cached:
Mem:  527806464 508919808 18886656        0 143884288 78098432
Swap: 1011666944  6451200 1005215744

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

$ uname -a
Linux server1 2.4.29 #6 Thu Jan 20 16:30:37 PST 2005 i686 unknown unknown GNU/Linux

# hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   2256 MB in  2.00 seconds = 1128.00 MB/sec
 Timing buffered disk reads:  168 MB in  3.00 seconds =  56.00 MB/sec

OS Slackware-10.1 c родным ядром с оптимизацией для i486.

> In any case, a host SHOULD try at least two addresses.

А помнишь разборки с терминологией SHOULD/MUST? ;)

> > In any case, a host SHOULD try at least two addresses.

> А помнишь разборки с терминологией SHOULD/MUST? ;)

:-)

Но, в данном контексте, это не сильно важно: "sender-SMTP MUST be
able to try (and retry) each of the addresses in this list". Не в
эту попытку, так в следующую, но перебрать он MUST все. ;-)

Ха, а тут ещё одна проблемка у писателей rfc.
Почувствуй разницу: "MUST be able to try" и "MUST try" ;)

> Запускаем приём 5000 писем с вирусом Eicar. Они режектятся на
> уровне очереди. Проверка через clamd.

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

И даже "must try" - неверно. "Try" - это сильно абстрактно и
расплывчато. Я попробовал, но чего-то там у меня не получилось ;)
Должно быть: "must connect" c записью в лог ответа!

Точнее будет: режектятся не доходя до очереди.

> Почувствуй разницу: "MUST be able to try" и "MUST try" ;)

Не чувствую. "Должен пробовать" и "должен иметь возможность пробовать". Разница то какая ? Если он не имеет возможности (не умеет/запрещено в конфиге/разное) - rfc-ignorant.

И qmail тут совсем не приделах. Как настроишь, так и будет.

> Точнее будет: режектятся не доходя до очереди.

То есть, послать smtp-сендера с реджектом он может ? Ну ладно тогда.

Разница колоссальная. Теоретическая возможность есть почти всегда.
Ибо нет ничего невозможного.

> Теоретическая возможность есть почти всегда.

А где это там про теоретическую возможность ? Или про то что это должно быть конфигурируемо ? Там конкретно про возможность. В общем, нет разницы.