Поддержка DSN в Postfix

Cравни такое условие:
1) Вы должны иметь возможность купить дорогой автомобиль.
и такое:
2) Вы должны купить дорогой автомобиль (иначе, к примеру, вас убьют)

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

И такое впечатление складывается, что писали этот (и много других) rfc
совсем не техническме специалисты, а слюнтяи-гуманитарии. Я очень хорошо
понимаю, какие чувства испытывал DJB, когда ему приходилось следовать
этим писаниям.

> Cравни такое условие:

Зачем ? Еще раз. Что непонятно во фразе: "сендер должен иметь возможность попробовать все адреса" ? Сендер имеет возможность ? Не имеет. Все, проехали.

Конечно имеет! Для этого ему всего лишь нужно наложить патчик.

> Зачем ? Еще раз.

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

Грубо говоря, разница примерно такая же, как между SHOULD и MUST.
"SHOULD" ни к чему не обязывает, и имеет лишь рекомендательный
характер. То есть, логически мыслящий человек сразу видит, что в данном
месте у него есть выбор: если ему не выгодно, он может не следовать
рекомендации. В условиях криво и противоречиво написанного rfc, а так же
учитывая, что правила _уже_ нарушены другой стороной (ответ 4xx) DJB
имел полное право игнорировать этот пункт.

> А затем, что "иметь возможность" - понятие _растяжимое_по_времени_,

Совершенно верно. А время ограничивается несколькими пунктами ранее.

Времени достаточно.

Ещё более простой пример: "Будь хорошим мальчиком" и "Не бей морду
соседу" ;) В первом случае морду соседу набить таки можно, если он
того заслужит ;)

> учитывая, что правила _уже_ нарушены другой стороной (ответ 4xx)

Давай ты приведешь цитату, где написано, что нельзя послать сендера с такой ошибкой. Заметь, я _не_ сказал "послать на стадии соединения или helo".

> Заметь, я _не_ сказал "послать на стадии соединения или helo".

Кстати, я совсем зря это не сказал. Блин, вот тоже польза. :-)

В общем, давай цитату, где написано, что нельзя. Может и тебе польза от перечитывания RFC случится...

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

по приведенному выводу vmstat видно совсем обратное.

> Мужики, похоже, много чего не знают... Хотя вот именно этот момент не то, чтобы сомнительный, просто он временный. Сейчас это так и есть, может быть. А завтра спаммеры и это отработают.

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

Буфера? :))

> по приведенному выводу vmstat видно совсем обратное.

Дай свой анализ в таком случае... По какому полю ты судишь об "обратном"
и что такое "обратное"? Какое самое слабое место в системе на твой
взгляд?

>> rfc: "_MUST_ delay retrying after _one_ attempt has failed".

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

Я дочитал. Даже синтаксический анализ этого текста проводился. Как
отдельно, так и совместно с прочими rfc.

Документ неоднозначен, это очевидно. Но в этой части rfc ТРЕБУЕТ:

1. перед каждой "попыткой доставки" (ПД) запросить dns и
отсортировать результат.
2. записи с одинаковым приоритетом обязаны быть перемешаны (в dns).
3. предпринять ПД.
4. если сообщение отправлено, закончить.
5. ОБЯЗАТЕЛЬНО подождать. РЕКОМЕНДУЕТСЯ не менее 30 минут, но не требуется.
6. если сообщение устарело (РЕКОМЕНДУЕТСЯ ждать неделю), инжектить
баунс, завершить.
7. повторить с пункта 1.

Под ПД rfc подразумевает (пункты [8-a] я сократил):

1. соединиться с первым сервером в списке
2. если соединение удалось, перейти к 5.
3. убрать из списка первый сервер.
4. если в списке остались серверы, вернуться в пункту 1.
5. получить приветствие.
6. если приветствие 554, считать сообщение устаревшим, завершить ПД
ошибкой.
7. если приветствие отличается от 220, завершить ошибкой.
8. обработать HELO, MAIL, RCPT, DATA.
9. если 5хх, считать сообщение устаревшим, завершить ПД ошибкой.
a. если 4хх, завершить ПД ошибкой.
b. завершить ПД успехом.

Вот и все, ТРЕБУЕМОЕ для совместимости поведение.

При желании можешь повторить анализ самостоятельно, мы его заказывали в FSU, Tallahassee, Florida.

>Дай свой анализ в таком случае... 

ты по какой цифре в выводе vmstat углядел что затык - дисковые операции?
то что idle 94? дык почему у тебя тогда bo и bi почти нули ? у меня они десятками тысяч измеряются, к тому же /proc/meminfo почему-то с vmstat никак не коррелирует, лажевые резалты ты показал.

> то что idle 94?

Да. Этого должно быть достаточно, так как idle складывается из IO-wait
на ядрах 2.4.x.

> дык почему у тебя тогда bo и bi почти нули

А потому, что запускал одноразовые репорты без обновления (без delay).
Вот правильные данные из нового запуска:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  2   6248   5832  92736 131968    0    0     0  8960  748  2331 32 15 53  0
 0  3   6248   5652  92740 132072    0    0     0  5404  462  1486 16 13 71  0
 1  2   6248   8368  92784 128800    0    0     0 10104  679  2312 35 22 44  0
 2  1   6248   8312  92784 128836    0    0     0  3188  498  1154 10  3 87  0
 4  0   6248   7692  92784 128940    0    0     0  6280  455  1670 25 15 60  0

> /proc/meminfo почему-то с vmstat никак не коррелирует

В meminfo инфа в байтах. Делай поправку соответственно.

> 7. если приветствие отличается от 220, завершить ошибкой.

Это вот откуда следует ? Про 421 не забыли ли, который имеет право появиться в любой момент ?

> мы его заказывали в FSU, Tallahassee, Florida.

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

> Это вот откуда следует ? Про 421 не забыли ли, который имеет право появиться в любой момент ?

Не имеет. Приветствие MUST be 220 или 554, если сервер не хочет тебя видеть, другое запрещено. В obsolete rfc821 можно было говорить 421 в любой момент, в rfc2821 только в ответ на команду, прочувствуй разницу.

>> мы его заказывали в FSU, Tallahassee, Florida.

> Ты знаешь, я первый раз про такую организацию слышу...

Florida State University. А заказывали филологам и/или юристам.

>Не имеет. Приветствие MUST be 220 или 554, если сервер не хочет тебя видеть, другое запрещено Цитату в студию. Нет там MUST и явного запрета на другие коды нет. Плюс на _любом_ этапе сесси можно сказать "421 Что-то мне плохо" и хлопнуть дверью.

> Не имеет. Приветствие MUST be 220 или 554, если сервер не хочет
> тебя видеть, другое запрещено. В obsolete rfc821 можно было
> говорить 421 в любой момент, в rfc2821 только в ответ на команду,
> прочувствуй разницу.

Не чувствую. Это может быть ответ на helo и этого достаточно. О чем речь вобще ? Или ты думал, что я про 421 в ответ на connect ?

Давай по-другому.

1. qmail, если 421 на helo (или любую другую команду) получит, на следующий mx пойдет ?
2. если на стадии data случится таймаут, qmail на следующий mx пойдет ?

Если ответ на оба вопроса да, тогда, значит, по пункту обработки mx я зря на qmail наезжаю. Если нет, говорить не очем в этом плане.

Кстати, что касается 821/2821. Первое - вообще-то не rfc, а второе все еще никак им, STD, не станет... Это уж если до спора с применением ссылок на стандарты, а не на рекомендации. Хотя, на самом деле, я тоже на 2821 ориентируюсь, на самом деле.

>Florida State University. А заказывали филологам и/или юристам.

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

> > 7. если приветствие отличается от 220, завершить ошибкой.

> Это вот откуда следует ? Про 421 не забыли ли, который имеет право появиться в любой момент ?

Стоп.

7. если приветствие отличается от 220

Это о чем речь ? Вообще-то, я считал, что это речь про ответ на helo. Если да, то я настаиваю на том, что кому-то надо RFC перечитать. Если речь про connect, то надо писать конкретно. А еще кто-то про разночтения в RFC говорит... :-)

Мы же вроде бы уже договорились, что требование "обеспечить возможность"
без требования её реализовать не имеет смысла. DJB как математик сразу
сложил (+1) + (-1), и получил ноль на выходе ;) Всё, до свидания. Пункт
игнорируется. Элементарная логика. Какие ещё споры могут быть? На самом
деле таких тёмных местечек в rfc много.

> Не те, ни другие нифига не понимают в подобных документах.

Вот как раз только эта связка (филолог+юрист) и может делать подобные
заключения. Филолог в совершенстве владеет всеми тонкостями языка.
Он не пропустит лажу с двойственным прочтением. Ну, а для юриста
привычная работа - читать между строк соглашения и контракты. Этот
отловит даже то, что пропустит филолог. Если ты думаешь, что для
подобного анализа нужны глубокие познания в предметной области, то
ты ошибаешься. Напоминаю учебную фразу, которую давал своим студентам
на разбор академик Щерба:

"Глокая куздра штеко будланула бокра и кудрячит бокрёнка".
(http://www.svetozar.ru/lingvo/derivation/1.shtml)

Дык вот, для филолога в порядке вещей обработать такое ;)

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

Не со мной явно. :-)

> DJB как математик сразу сложил (+1) + (-1), и получил ноль на выходе ;)

Я допускаю, что он неплохой математик. Но неплохому математику следует математикой и заниматься.

Ну, ты же видишь, что дело серьёзное. Математики тоже ой как нужны.
Вот уже даже филологов привлекают. И всё для того только, чтоб понять,
что же в этих RFC написано. А написаны они примерно так:

Aoccdrnig to a rscheearch at an Elingsh uinervtisy, it deosn't mttaer in
waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht
frist and lsat ltteer is at the rghit pclae.
;)

> Не со мной явно. :-)

Да пожалуйста. Блажен, кто верует. Я разложил вопрос по косточкам.

> Но неплохому математику следует математикой и заниматься.

Cледует? Опять "SHOULD" ;) DJB клал на такие пожелания ;)
А я бы наоборот, запретил бы ему заниматься математикой, и сказал бы,
что он MUST continue software projects. Хочу (в порядке убывания
ценности) djbssh, djbldap, djbdhcp для начала... В мире наберётся не
более 3-х человек, которые по-настоящему умеют писать софт. DJB - один
из них.

> > Не со мной явно. :-)

> Да пожалуйста. Блажен, кто верует. Я разложил вопрос по косточкам.

За таким стремлением, разложить по косточкам, я пока только baka-kun вижу, но у него 7-ой пункт в алгоритме доставки хромает.

> В мире наберётся не более 3-х человек, которые по-настоящему умеют
> писать софт. DJB - один из них.

Я даже не буду спорить не только о его математических способностях, но и об умении писать софт. Это умение тоже может быть неплохим. Но у некоторых, гениальных в чем-то, людей, бывает, возникает звездная болезнь, когда они начинают считать, что гениальны они во всем. Со своей трактовкой RFC djb смело может идти в пешее эротическое путешествие и его творения годятся только в качестве скелета для по-настоящему законченного продукта. Кто хочет и может этим заниматься, тот может их использовать, кто не хочет - может брать уже готовое и правильно работающее.

Я тоже не увидел от тебя опровержения логической цепочки
"должен иметь возможность исполнить" + "не обязан исполнять" = "пустой звук".

> бывает, возникает звездная болезнь

Может быть именно эта болезнь позволяет ему писать такой прекрасный
софт. Никто не знает ;) Но нужно согласиться, что способности у него
уникальные. Он пишет так, как может быть простые люди научатся писать
лет через 100-200, прочитав гору инструкций и мануалов. А он пишет
здесь и сейчас... неземной софт ;) Это необычно, непривычно, и многих
(большинство) шокирует. А меньшинство просто принимает как дар божий,
с удовольствием работает с его софтом и радуется жизни ;)

> Со своей трактовкой RFC djb смело может идти

Она настолько верна, насколько верно вообще возможно трактовать
документы составленные больным аберрированным земным разумом ;)
На сколько возможно из горы пустой породы вытащить крупинку золота...

> "должен иметь возможность исполнить" + "не обязан исполнять" = "пустой звук".

"должен иметь возможность исполнить" + "не имеет возможности исполнить" = "ошибка в логике".

C "не имеет возможности исполнить" согласен ?

> Может быть именно эта болезнь позволяет ему писать такой прекрасный софт. Никто не знает ;)

Который, сам по себе, имеет ценность только в академическом плане.

> неземной софт ;)

Да, фанаты у таких людей тоже есть, как правило. :-)

> C "не имеет возможности исполнить" согласен ?

Я-то может и соглашусь, но мое мнение субъективно и неавторитетно.
Я бы очень хотел видеть нормальное доказательство этого утверждения.
Условие одно: к исходникам smtp-клиента ты доступ не имеешь.
Ты утверждаешь, что нарушается протокол, правильно? Вот на уровне
протокола попробуй доказать его нарушение. Сможешь? Если нет, то и
нарушения нет... Мне странно, что так упорствуешь. Логика проста.

> Который, сам по себе, имеет ценность только в академическом плане.

И неправда. Я кормлюсь этим софтом не будучи академиком ;) Благодаря
ему я могу оставлять сервера без присмотра на годы без риска. Он очень
сильно экономит моё время.

> Да, фанаты у таких людей тоже есть, как правило. :-)

Я не фанат. Я практик. Мне удобны эти инструменты. И ещё открою страшную
тайну: как человек DJB мне противен. Я уважаю в нём только программиста.

>> 7. если приветствие отличается от 220

> Вообще-то, я считал, что это речь про ответ на helo.

Нет, это именно приветствие сервера, баннер. То, что видит клиент сразу после коннекта.

Вообще, rfc не оговаривает конкретно, что делать клиенту, если сервер выдал лажу. Я бы предпочел на него плюнуть, и занести в rfc-ignorant. Собственно, и сервер имеет полное право плевать на некорректных клиентов. Типичный пример -- <CRLF>, rfc ТРЕБУЕТ именно так. Если клиент выдал лажу, намного безопасней ругнуться и оборвать связь. При этом "See http://pobox.com/~djb/docs/smtplf.html"; в пределах стандарта.

> Вот на уровне протокола попробуй доказать его нарушение. Сможешь?

А то ж. :-) Раз на бакап не пришел, значит, возможности не было.

> > Который, сам по себе, имеет ценность только в академическом плане.

> И неправда. Я кормлюсь этим софтом не будучи академиком ;) Благодаря
> ему я могу оставлять сервера без присмотра на годы без риска. Он очень
сильно экономит моё время.

Ладно, хрен с ними, с MX-ами. Вот ты скажи, на rcpt to:<ahsdvcjsavcjsa@твой.домен> у тебя сервер что скажет ? 250, как t-online.de, или 550, как правильный ? А если 550, это по-умолчанию, или таки ты патч приложил ? Сколько времени затрачено на то, чтобы выдать реакцию от антивирусного или спам-фильтра сразу по окончании data ? Про Sieve я молчу, тут понятно все...

>>> 7. если приветствие отличается от 220

>> Вообще-то, я считал, что это речь про ответ на helo.

>Нет, это именно приветствие сервера, баннер. То, что видит клиент сразу после коннекта.

Так. Тогда возвращаемся к логике перебора MX-ов. Втыкаемся вот сюда:
a. если 4хх, завершить ПД ошибкой.

Должно быть "попробовать следующий MX". И только в случае 4xx тут, завершить ошибкой. Причем, если не перебирать все MX до конца, то пометить эти два, как отработанные для общего цикла попыток и, после паузы, пробовать следующие N MX.

> Раз на бакап не пришел, значит, возможности не было.

А если была, но не захотел? ;)

> Вот ты скажи, на rcpt to:<ahsdvcjsavcjsa@твой.домен> у тебя сервер что скажет ? 250, как t-online.de

Если честно, то да ;) Qmail непатченный. До недавнего времени меня эта
тема никак не трогала. Я не баунсил такие письма. Они валились напрямую
в спам фильтр для обучения ;) А после него в ящик spam@. Но я подумываю
прикрутить mailfront от Брюса Гюнтера. Его софт проверен, и никогда не
имел проблем с безопасностью. Он работает как прокладка между клиентом
и реальным qmail-smtpd.

> Сколько времени затрачено на то, чтобы выдать реакцию от антивирусного или спам-фильтра сразу по окончании data ?

Я же приводил бенчмарки с обработкой и спама, и вирусов. Смотри и считай.

> Про Sieve я молчу, тут понятно все...

И правильно делаешь ;) То, что делает sieve в qmail'e давным давно
освоено. И как всегда реализовано просто и изящно. За что я его и люблю.
http://cr.yp.to/mess822.html
http://www.superscript.com/qtools/intro.html

> Вот ты скажи, на rcpt to:<ahsdvcjsavcjsa@твой.домен> у тебя сервер что скажет ?

Мой сервер для начала скажет 450. ;)

> 250, как t-online.de, или 550, как правильный ?

Зависит от принятой политики. То есть, считаешь ли ты правильным раскрывать реально существующие адреса или нет. Это же касается VRFY и EXPN.

> Сколько времени затрачено на то, чтобы выдать реакцию от антивирусного или спам-фильтра сразу по окончании data ?

Понимаешь, qmail -- unix-way, эта задача решается размещением на пайпе между qmail-smtpd и qmail-queue еще одного процесса. Например, `mv qmail-queue qmail-queue-djb; mv filter-queue qmail-queue`. Или просто `export QMAILQUEUE=filter-queue`, если не лень наложить патч из пяти строчек. Для примера корректной работы смотри на drweb.

> Про Sieve я молчу, тут понятно все...

Конечно. Например, посмотреть на mvmf для начала. А может и понять, что он тебе не особо и нужен.

> Должно быть "попробовать следующий MX".

Может и должно, а может и нет. Это запрещенная комбинация. С одной стороны не оговорено, как вести себя в таком случае, с другой стороны есть правило, как реагировать на 4xx. И "попробовать следующий MX" с последним не согласуется.

История возникновения rfc2821 очень интересна: документ пропихивали как утверждающий в качестве стандарта поведение сендмейла, все нечеткие и пропущенные моменты rfc821 писались именно с него. В результате всех "доработок" и "улучшений" (sendmail тоже не стоял на месте ;) получили семантически неоднозначный текст, в котором многие моменты не оговорены как "само собой разумеющиеся". А это жопа, прошу прощения.

Конечно жаль, что не ты писал rfc, может толк бы вышел, но имеем такое вот уродство.

> > Вот ты скажи, на rcpt to:<ahsdvcjsavcjsa@твой.домен> у тебя сервер что скажет ?

> Мой сервер для начала скажет 450. ;)

В общем, тоже не плохо, наверное. Одно но. Представь, что у кого-то в адресной книге завалялся какой-нибудь несуществующий адрес в твоем домене, этот кто-то подхватил вирус, при рассылке адрес попал во from и разбежался по сети. Далее этот же или другй вирус начал выбирать адреса из уже из фолдеров OE и слаться в том числе и на этот E-Mail. И тут твое 450. И по разным почтовикам в сети начинают копиться очереди в твою сторону. У тебя какой там предел по количеству процессов ?

> > > 250, как t-online.de, или 550, как правильный ?

> Зависит от принятой политики. То есть, считаешь ли ты правильным раскрывать реально существующие адреса или нет.

Когда дело доходит до конкретного E-Mail, это уже не скроешь, можно, в конце концов, и письмо послать. А, с другой стороны, сказав 250 на rcpt to, ты сделаешь бессмысленной встречную проверку адреса отправителя (а делаться она может и для mail from, с учетом <>, и потом, в data, уже для from и без учета <>). Учитывая, что она сейчас много где используется и спаммеры с этим считаются, твой домен может быть выбран для формирования случайных E-Mail для from. Эффектом будет прохождение спама на чужих серверах и поток отлупов по несуществующим rcpt to лично тебе. Что сейчас и происходит с t-online.de.

> `mv qmail-queue qmail-queue-djb; mv filter-queue qmail-queue`

Хорошо. То есть filter-queue получает сообщение по мере поступления qmail-у и может вызвать реакцию а-ля "554 virus Worm.Zafi.D detected by ClamAV" ? Хорошо. А спам-фильтр - еще один пайп ? Или надо что-то отдельное использовать, чтобы толпу разных фильтров объединить ?

> Для примера корректной работы смотри на drweb.

Тут еще, параллельно, надо на qmail смотреть. :-) drweb, вроде как, ошибку отдает, но что там с smtp-сессией в этот момент, по нему не видно. А что будет, если drweb грохнется ? Прием почты прекратится ?
Понятно, что есть аргумент, что писать надо, чтобы не падало...

> > Про Sieve я молчу, тут понятно все...

> Конечно. Например, посмотреть на mvmf для начала.

Только предварительно вопрос: mvmf - это какой rfc ? ;-) А поддержка Sieve уже начала появляться в почтовых клиентах...

> > Сколько времени затрачено на то, чтобы выдать реакцию от антивирусного или спам-фильтра сразу по окончании data ?

> Я же приводил бенчмарки с обработкой и спама, и вирусов. Смотри и считай.

Я про личное время на прикручивание.

> То, что делает sieve в qmail'e

Я про главный аргумент baka-kun-у написал. :-)

> В общем, тоже не плохо, наверное. Одно но.

Никаких "но". Это грейлистинг. Обычно такой мусор вторую попытку и не делает. И, предвидя вопрос: нет, сразу 550 -- не лучше.

> У тебя какой там предел по количеству процессов ?

SMTP concurrency в пиках 170-180. При сконфигурированном лимите в 250.

> Когда дело доходит до конкретного E-Mail, это уже не скроешь, можно, в конце концов, и письмо послать.

Можно, но зомби не могут делать автоматизированный подбор по rcpt и/или vrfy. Да и ради брутфорса никто не будет заводить реальный адрес и рассылать письма.

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

Опасный механизм: а) DDoS для третьего сервера -- легко, б) DDoS для тебя -- еще проще, в) как _твоя_ реализация проверки реагирует на 450? г) надеюсь, для проверки в исходящий mail from ты помещаешь адрес из входящего rcpt to? Если нет, выкинь такую проверку нафиг. Да и вообще выкинь, spf и тот полезней.

> А спам-фильтр - еще один пайп ? Или надо что-то отдельное использовать, чтобы толпу разных фильтров объединить ?

У каждого из таких фильтров настраивается, кому отдавать. Можешь сделать цепочку qmail-smtpd -> drweb-qmail -> clamav -> spamassasin -> trophie -> qmail-queue. А можешь поставить simscan, например, и уже в нем задавать цепочку проверки.

> Тут еще, параллельно, надо на qmail смотреть. :-)

Не больше, чем на cat и less в цепочке `cat foo | grep bar | less` ;)

> Понятно, что есть аргумент, что писать надо, чтобы не падало...

Так и запишем: "не смотрел, но осуждает" ;)

> Только предварительно вопрос: mvmf - это какой rfc ?

rfc3028, естественно. И много больше. Читай http://www.mvmf.org/