дык и где там хоть слово о windows сказано??

недопонял. 70% + 13% +7% больше чем 98

Будете смеяться, но насколько я понимаю это не так уж плохо, как кажется.

Можно предположить, что при установке серверов максимальный траффик, который они могут держать наверняка определялся как средний, домноженный на какую-то величину. Следовательно, если бы средний был в 50 раз меньше нынешнего среднего (а это оставшиеся 2% :-) ), то и максимальный наверняка был бы тоже раз в 50 меньше нынешнего максимального. А это значит, что та DOS атака, которая была пару месяцев назад выбила бы все, что можно... Она ведь и так вывела из строя несколько серверов.

Мы сегодня уже посмеялись на эту тему и предложили поставить автопосялатель у себя на сервере :) Типа, если в течении часа один и тот же сервер спрашивает тот же IP - возращаем адрес веб-сервера, где написано - НАСТРОЙ КЕШ, СТ!

Жаль, народ нас не поддержит :)

тому кто постит новости предлагаю занятся английским вплотную

Мда, новости уже сами сочиняете... Куда уж ниже можно упасть... Желтая пресса какая-то.

>>>Мы сегодня уже посмеялись на эту тему и предложили поставить автопосялатель у себя на сервере :) Типа, если в течении часа один и тот же сервер спрашивает тот же IP - возращаем адрес веб-сервера, где написано - НАСТРОЙ КЕШ, СТ!<<<

Поддерживаю! Идея здравая.... Будут мысли, как это осуществить?

>>>недопонял. 70% + 13% +7% больше чем 98<<<

70, 13 и 7 - это проценты от рассматриваемых 98-ми, то бишь проценты среди ненужных запросов

> 70% представляют собой ненужные повторы

Возможно где-то есть большие сети, которые ходят в инет через
один IP. В каждом сегменте свой dns-сервер. Может быть такое?

> 13% - запросы о неправильных корневых доменах,

От этого никто не застрахован. Достаточно на посещаемом сайте
выставить страничку со кривой ссылкой на картинку
http://localhost.localdomain/img.gif и вот тебе тысячи кривых
запросов отовсюду.

> 7% - запросы, в которых уже содержится ip адрес.

А это непонятно. Содержится или чистый IP?
Допустим, запрос PTR 61.32.76.217.in-addr.arpa вполне законен.
А запрос типа "A 217.76.32.61" вообще не должен доходить до
корневых серверов. Согласно rfc любой локальный для клиента dns-сервер, через который он резолвится, должен немедленно
выдать ответ, повторяющий запрос. То есть тот же IP-адрес.
Ему не нужно для этого обращаться к корневому серверу.
Так что это скорее всего умышленные DoS-атаки.

>>Поддерживаю! Идея здравая....

%) идея абсолютно гнилая, отсюда вытекают 2 проблемы..

1)"отдать" лишний раз адрес много "дешевле" чем вычислять обращался ли ЭТОТ хост с ЭТИМ запросом в течении ОПРДЕЛЕНОГО промежутка времени..

2)Кеш никто настравивать не будет, а вот забить на ваш DNS вполне могут, если вы не предоставите ссылку на RFC где подобное разрешаеться..

Кстати, "овчинка выделки не стоит"...
Тобишь, если говорить о производительности корневых серверов, то мощность железа растет бысьрее чем количество запросов.. Если говорить о каналах, то объем вообще всех DNS запросов много меньше общего траффика в целом, и уменьшение его даже на 98% вообще никак не будет заметно. Лучше бы со спамом боролись...

Кстати, недавиче сам наглядно убедился что сушествуюший уже 20 с лишним лет SMTP протокол безнадежно устарел %( Организовать "петлю" и забить канал ненужным траффиком можно даже случайно, что я недавиче и созерцал.. %(

Как сказали на slashdot, remaining 2% are obviously unnecessary. ;)

> недопонял. 70% + 13% +7% больше чем 98

70+13+7=90.

линуксойды до ста считать разучились? :) про остальные 8% можете прочитать в английском оригинале. :)

> дык и где там хоть слово о windows сказано??

http://www.caida.org/projects/dns-analysis/index.xml#bogus

Our analysis helped to find and fix a bug in Microsoft Win2k resolver.

Ничего SMTP не устарел. sendmail имеет встроенные средства обнаружения петель. Т.е. если письмо прошло через этот сервак N-раз (в sendmail это значение равно 25), то сервак его возвращает отправителю или убивает.

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

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

>>sendmail имеет встроенные средства обнаружения петель.

стопчик стопчик.. так sendmail умеет или в RFC на SMTP это описано???

кстати, одним из участников петли, случвшейся у меня был имеено sendmail..
Кстати, там вабще интересное трио получилось
qmail + postfix + sendmail
и ни один из НИХ петли не прекратил!
правда там не одно и тоже письмо письмо фигурировало, но дело это не меняет..

кстати, а как насчет однозначной интдитифакации отправителя??? я об SMTP???

так что не будем.. Протокол не отвечает сегодняшним требованиям.
что касаеться меня, то я протоколы не разрабатываю и тем более никого не убеждаю, просто константирую факт. Ибо если вас все утраивает, то дайте мне (да и многие наверное тоже не против услышать) описание как мне с вероятностью 99.9% избавиться от спама в рамках SMTP??

>>проверки обратного адреса
что вы понимаете под этим понятием????

> Организовать "петлю" и забить канал ненужным траффиком можно даже случайно, что я недавиче и созерцал..

С участием какого MTA произошла сия петля? Случаем не sendmail?
Я точно знаю, что с qmail это невозможно в принципе. Он делает
пометки в заголовке "Delivered-to: xxx". Если видит повтор, делает баунс. Если баунс не прошел, отбрасывает постмастеру. Если же невозможно достучаться до постмастера, то грязно ругается в лог и удаляет письмо.

> правда там не одно и тоже письмо письмо фигурировало, но дело это не меняет.

Ты хоть думай, что говоришь. О какой петле может идти речь,
если письма разные?

> кстати, а как насчет однозначной интдитифакации отправителя??? я об SMTP???

А ты наверное кремлевский мечтатель? Однозначную идентификацию отправителя может дать только судмедэксперт ;)

>>Я точно знаю, что с qmail это невозможно в принципе. Он делает
да ну %))))


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

письмо разное, ТЕЛО ОДНО!


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

по приходу письма на некоторый аддрес(qmail) mail@XXXX.domen.ua
письмо форвардилось на 3 реальным людям, а также отсылалось уведомление на пейджер (кто помнит, были раньше такие девайсы %))) Тобишь отсылалось писмо на ящик пейджерной компашки, которая письмо обрабоатывала и соответсвено писмо отправляло на пейджер.

По определеным причинам, qmail сам письма не шлет на прямую, а форвардит из на SMTP непосредственого провайдера (postfix) , который честно отпраляет их непосредствено на ящик пейджера (sendmail). Вот такое вот трио.. Все это заипательски работало не один год. Пейджера уже давно успели выкинуть.. А вот строчку форварда нет.. Ну кто о ней буд помнить???

Тепер така ситуация.. Ящик пейджера закрываеться...
Что мы имеем??? sendmail (безусловно проверив на валидность отправителя), пытайеться найти ящик, не находит, и соответсвено грязно ругаеться кому вы думали??? имеено виртуальному юзеру mail@XXXX.domen.ua, от кторого письмо собсно и исходило!. Прошу заметить, что ТЕЛО письма одинаковое! и содержит пару строчек типа, "вам пришло писмо от адресата ******".
теперь все просто, qmail получив ругательство воспринимает его просто как письмо и формирует новых 3, одно из которых снова идет на пейджер!
что происходит дальше, наверное понятно... За неполный день письмо упело сходить 28тыс раз. Можно меня кнечно обвинить в кривых руках, НО!!! в петле учавовали еще 2 сервера, оба из которых нехилые такие провайдеры, а один так и вовсе считает себя большим %)..

ВОПРОСЫ????

1)почему sendmail получив пистмо с одинаковыми
RCPT TO:
MAIL FROM:
DATA

ничего не предпринмал и продолжал тупа отбиваться что нет такого юзера?????

2) Почему QMAIL не понимал тогоже, и не выкинул постмастеру даже предупрежения о том, что некому mail@XXXX.domen.ua пришло за сегодня 28 тыс писем от одго адресата????

3) Меньше всего вопросов к тупо форвардящему postfix. Но, он тоже никого не предепреждал, что заниметься одним и темже тысячи раз..


Вот такая вот история...
и МТА сами тут не причем...

2ifconfig (*) (2003-01-26 11:52:48.48)

Виновен в данной ситуации только администратор машины, где живет qmail. Он забыл Golden Rule, который говорит о том, что
любой автоматический ответ должен иметь пустой envelope sender.

> 1)почему sendmail получив пистмо с одинаковыми

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

> 2) Почему QMAIL не понимал тогоже, и не выкинул постмастеру даже предупрежения

Смотри ответ на пункт 1). Его задача доставлять без лишних вопросов.

> 3) Меньше всего вопросов к тупо форвардящему postfix.

Ровно столько же вопросов должно быть к двум остальным.
Qmail тоже тупо форвардил ровно туда, куда ему сказали.
Sendmail тоже выполнял стандартную процедуру. Отвечал, что
ящик не найден.

>>Виновен в данной ситуации только администратор машины, где живет qmail. >>Он забыл Golden Rule, который говорит о том, что
любой автоматический ответ должен иметь пустой envelope sender.

Да кто против то.. Это вобшем то понятно, вопрос в том, что подобная ошибка, может закольцевать почту и напрячь не в чем не повинные сервера совершенно других граждан и организаций. А механизм выявления подобных ощибок(можно назвать и халатностей) не определен на уровне протокола.

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

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

Это глупость. Точно так же можно сказать про http, ftp и т.д.
Любой юзер теоретически может напрячь сетку так, что она просядет.
Для это и придумали системных администраторов ;)
В твоем случае администратор должен был бы по идее собирать
статистические данные со своего сервера хотя бы раз в день и
засылать себе по почте. Сразу бы и увидел проблему.

------
Представь, если бы живой почтальон перед тем как принести тебе
очередное письмо, вскрывал бы его и читал с целью проверить,
не является ли оно копией предыдущего ;)
------

Аналогия с почтальоном и бумажным письмом не верна.

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

С/у, Ден.

можно забить на корневые сервера. грузишь _все_ домены второго уровня в кэш (примерно 300к файл), и на ТЛД отправляешь только идиотские запросы типа ххх.нтдомен. если кто использует такой же подход просьба сообщить об ощущениях.

А смысл? named это и сам делает. hint: кеширование.

а какой смысл кэшировать почти статические данные - весь первый уровень ? кроме того, на одно обращение меньше и сервера 1-го уровня менее заняты

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

Конверты в данном случае в каждом новом витке разные. Причем
меняет их только sendmail... Смотрите: qmail и postfix только
переправляют почту без изменения конверта. Теперь я склоняюсь
к мысли, что главной причиной зацикливания все-таки является
sendmail! Не знаю как postfix, но qmail остановил бы цикл
после первого витка, если бы он был на месте sendmail'a
пейджинговой компании. Qmail в заголовках принятого им письма
добавляет адрес получателя с фактом попытки передать ему письмо:

Delivered-to: 12345@pager.com

Если два других MTA не меняли бы конверта, как в данном случае, то при получении второй раз Qmail увидел бы свою
запись "Delivered-to:" и сделал бы баунс с пустым обратным
адресом и с сообщением:

"This message is looping: it already has my Delivered-To line. (#5.4.6)"

Все. Цикл бы остановился после двух витков.
Знатоки sendmail'a желают что-то сказать в свое оправдание?

> можно забить на корневые сервера. грузишь _все_ домены второго уровня в кэш

Даже корневые сервера меняются. Кажется в ноябре была замена одного или двух. А уж второго уровня - и подавно.

Podal by kto-nit' iz provaiderov v sud na etu M$ za ih dynamic updates - vot by ya posmotrel by :)

Best regards, Dmitry.

2anonymous (*) (2003-01-27 13:36:54.838): и чем тебя dynamic updates тебя так напрягает? А-А-а! Видимо ты забыл прочитать соответствующий rfc (извиняйте батько, номер в лет не помню, а искать лень - сам поищещь), где эти самые dynamic updates описаны...

mail loops

anonymous (*) (2003-01-27 04:11:20.899): ты не понял, что происходила генерация квитанции, а не повторения письма? Если бы ты понял - ты бы на sendmail не гнал. Никакой Delivered-To не может копироваться из письма в генерируемый на него отлуп...

Ситуация известна. К сожалению, нормальное опознавание и лечение придумать тяжело. Определить на уровне протокола её нереально. Более того, по сравнению с другими тяжёлыми проблемами (никто не видел, как в результате аналогичных loop'ов sendmail реагирует на mime boundary nesting too deep? там начинается такое, по сравнению с чем ситуация описанная ifconfig'ом - штатное состояние;))) - это ещё так себе, разминка...

Нет, я не верю, что это может как-то лечиться сменой протокола.

> ты не понял, что происходила генерация квитанции

Да, я понял, когда уже написал. Мозги засахарились слегка.
Значит остается в силе первый диагноз про Golden Rule +
халатность админа, который за серваком не наблюдал. Все вместе
говорит о том, что админ был мягко говоря неопытный, грубо
говоря - ламер ;(

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

С/у, Ден.

>>админ был мягко говоря неопытный, грубо говоря - ламер ;(

А что это меняет??? Если к вам приходит парень и покупает у вас канал, с доступом к вашим ресурсам вы будете выяснять его квалификацию??? обычно, ваш SMTP будет обязан принимать почту у ваших клиентов. И я не хочу зависить от случайных ошибок. Заметте, даже не умышленых, а случайных..

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

Если хотите, можно провести ассоциацию с опасной/безопасной бритвой.

Я не буду долго распостраняться на тему как я вижу новый протокол, но то что в нем должны быть реализованы хотябы такие веши -как запрешено всем, разрешено только зарегистрированым. Тобишь хочешь иметь собсный SMTP, регистрируй его в организациях подобных RIPE, только после этого, ты будешь иметь право (тобишь другие зарегистреные сервера примут почту у тебя) отправлять почту во внешний мир. А не так как сейчас, что для рассылки спама SMTP сервера подымают на несколько часов на диалапе.
Анализировать и отыскивать хотя-бы примитивные ошибки как описаная. Только не говорите что-то очень сложно. В данном примере я вижу кучу алгоритмов чтобы избещать подобного. К примеру, после десятого письма от одного адресата другому с одинаковой md5 сумой тела, принимаюший сервер мог бы и поинтресоваться у отправляющего, а не занимаеться ли тот фигней?? и только после подтверждения что все коректно и так должно быть, проболжать работать..

А пока находяться ребята которые кричат, что у нас клевый протокол, а у вас руки кривые, мы все будем получать ТОНЫ спама, кучи ненужного траффика и прочего дерьма.

> что протокол не обеспечивает примитивной защиты от дурака.

Да не в протоколе дело! Ты обвиняешь дорогу за то, что на ней
случаются аварии с участием пьяных водителей ;)
Посмотри на smtp-сервер mail.ru. Попробуй отослать через него
много писем. Все дело в руках.

> для рассылки спама SMTP сервера подымают на несколько часов на диалапе.

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

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

И через пару лет от твоих алгоритмов почтой будет невозможно
пользоваться в принципе... Виндовое мышление.

> К примеру, после десятого письма от одного адресата другому с одинаковой md5 сумой тела,

А сейчас расскажи, что такое "тело" ;)

Сообщение вида "I wasn't able to deliver your message" относится к телу?

> принимаюший сервер мог бы и поинтресоваться у отправляющего, а не занимаеться ли тот фигней??

А вот такой ахинеи я еще не слышал ;)

>>Да не в протоколе дело! Ты обвиняешь дорогу за то, что на ней
случаются аварии с участием пьяных водителей ;)

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

>>Посмотри на smtp-сервер mail.ru. Попробуй отослать через него
много писем. Все дело в руках.

Ну и? протокол описывает такое поведение mail.ru ?? Если нет, то все что сделано там есть инициатива только персонала. А насчет рук, дык батенька если к каждому SMTP да целый табун админов, то может быть.. Но где их взять??
Тоесть задачи, которые должны быть описаны в спецификации протокола перекладываются на плечи персонала. Причем решает их каждый, кто во что гаразд.

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

>>А сейчас расскажи, что такое "тело" ;)
объясняю %) те символы, которые идут после DATA и заканчиваються символом '.'
будешь возражать что можно посчитать md5 ???


>>А вот такой ахинеи я еще не слышал ;)
тебя удивляет сам факт двустронего обмена данными??? если да, то что в этом пугает??

Кстати, все красиво ты написал, но несмотря на такие прямые руки у некоторых админинов (я к ним не отношусь кнечно), все стонут от СПАМА, вирусов и подобного. Дай совет где нуна подкрутить, чтбы с вероятностью 99% избавитсья от спама?

Кстати, то Golden Rule которое здесь упоминали, есть ни что иное как костыль, который позволяет хоть как то обеспечить решение проблемы в современных условиях.
Может быть еще будешь оправдывать другой костыль в виде Base64 ???
народ тут обеспокоен лишними DNS запросами, а у нас почта пухнет до полутора раз потому что нам надо соблюдать стандарт. Сколько лишнего трафика гоняеться благодоря кодированию в Base64??

Спенцификация SMTP была принята в августе 82 года, когда почта играла совершенно другое значение и назначение. Тогда врядли кто задумывался, что когда то народ дойдет до того, чтобы слать друг другу AVI рамером в 700М.
Очнись, прошел 20 с лишним лет. IPv6 вон тоже не от хорошей жизни появился.

> Дай совет где нуна подкрутить, чтбы с вероятностью 99% избавитсья от спама?

Зависит от MTA. Я работаю с qmail'ом. rblsmtpd + десяток
строчек в ~/.qmail и вот они твои 99% ;)
А у меня соотношение спама к нормальной почте 10:1.
Так что без спецсредств я бы уже давно закопался в спаме.

Кто виноват в зацикливание почты можно определить только после анализа обмена. Кроме обычных MTA там еще фигурируют программки закидывающие почту в пейджер. Как она пашет, одному черту известно. Легко может полностью пересобрать письмо с утратой информации о лупе. Пустить почту в вечный луп не так уж и просто, кто-то должен основательно приложить ручонки. Кратковременные лупу могут происходить из-за разного рода проблем.Это бывает. SMTP давно пора переписывать. И начать надо сейчас. У меня уже сносили почтарь указав в спамерской рассылке обратный адрес ivan17@XXX.ru . Так не спасут и RBL разные, получаешь все по полной программе.А спамер $10 баксов заработал - урод. А модификация SMTP совсем простая. Письмо должно приходить только с релея, прописанного в MX-ах для домена отправителя. Далее отвественность за спам и открытый релей однозначная. И если рассмотром инцидентов займутся организации раздающие домены в сети, то все войдет в цивилизованные рамки. DNS как протокол вполне нормальный, только вот кешировать надо корень всем и весь. После этого отвергать все запросы на несуществующие домена 1-го уровня. Билли же выставить счет. Если кто видел логи запросов байнда, тот знает какая хрень валиться от винды.

> MTP давно пора переписывать.

Расслабься. Умные дядьки давно работают над этим.

> У меня уже сносили почтарь указав в спамерской рассылке обратный адрес ivan17@XXX.ru .

Не понял. Поясни, что значит "сносили почтарь"?