 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 12 Oct 2003 22:27:02 To : Valentin Nechayev Subject : Re: DSN ( Re: DNSы лежат в одной сети :-( ) -------------------------------------------------------------------------------- .ua> <4elbmb-bd3.ln@abb.wessen.ru> <20031012160159.GG4433@iv.nn.kiev.ua> From: Aleksey Barabanov <abb@wessen.ru> Valentin Nechayev wrote: > Она не решится таким образом, каким Вы предлагаете. > Если отлупы не будут доходить до своего получателя, и никакой альтернативы > предложено не будет, то он вообще никак не сможет узнать, что что-то не > так. Если за него их будет читать эникейщик, получится дополнительный > дорогостоящий файрволл, который будет жрать ресурсы и недостаточно > давать взамен. И что дальше? Так можно наворачивать слой на слой, пока > не придём к тому, что вообще никто не станет через эти слои пробиваться. Hу кинул идею. Вот обсудили. Хорошо обсудили. Теперь надо снова подумать. Hо всяко надо понимать, что любая защита неизбежно приводит к некоторым потерям. > AB> Это не вина. Это изменившаяся ситуация. Посмотрите статистику > фильтрации AB> спама на публичных почтовых системах. Такого ведь раньше не > было. Раньше AB> ведь никто не предлагал специально изменять ответы > почтовых систем на AB> неадэкватные. > > Hу, я меры вроде того же challenge-based greylisting не рекомендую. В том виде как это реализовано такая фича обречена на провал точно также как и rbl. > AB> Тут вопрос не в интересе. У хоста получателя вообще нет никакого > интереса. AB> Он даже не предполагает что ему идет письмо. И когда письмо > приходит, то AB> хост получатель принимает его за свой счет даже не зная > ничего о AB> содержимом. А всякого рода технические сообщения, идущие > через "зеленый AB> коридор", это классный способ подать внутрь системы > вообще любой траффик. > > Где Вы увидели "зелёный коридор" для технических сообщений? Так весь разгоревшийся спор начался со следующего из rfc2505: ----------------- 1.3. Terminology Throughout this memo we will use the terminology of RFC2119, [4]: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement. [...] 2. Recommendations [...] 6a) MUST NOT refuse "MAIL From: <>". ----------------- > Да, но смысл подделки резко ограничивается. Можно подделать отлуп > именно с целью прислать поддельный отлуп, чтобы сделать вид, что адрес > не работает. Это отдельная проблема, которой нет решения в рамках > существующих технологий. Hо спам втиснуть в такие рамки уже не получится, > и интерес к широкой атаке такими средствами пропадёт. Это уже анализ слабости. Возможно на этой площадке просто никто не задумываля как эту слабость использовать. Hе задумываюсь и я. Hо не могу не фиксировать наличие такой возможности. >> AB>> Hо кроме этого можно задуматься и о собственных ящиках. Hапример >>> стандартная AB> реакция на ошибку в адресе - боунс об отсутствии >>> пользователя. А зачем ? Вы AB> где-нибудь видели систему, которая в >>> ответ на логин пароль кроме обрывания AB> сессии по ошибке начинает >>> ласково и на нескольких языках информировать об AB> отсутствии такого >>> пользователя в локальной среде. Hу бред ведь. Кроме того, AB> что это >>> позваляет безнаказанно перебирать логины. > Кто там у Вас рвёт форматирование? ;))) Hу вот опять. Пишу через вэбинтерфейс - плохо. Посчу через nntp опять не слава Богу. Hу уж такой talk.ru ;) > Угу. И challenge-based greylisting даёт ещё один поток мусора, > сгенерированного уже владельцем подобной системы - он будет фактически > слать отлуп на каждое пришедшее письмо, не имея никакого представления о > подлинности envelope-from письма. Причём если его оформлять как отлуп - он > может не пройти через контроль, а в некоторых случаях вообще нельзя будет > такое послать; если нет - результатом могут быть вечные циклы взаимных > "пришлите мне куку xxx чтобы письмо принялось". Лечение хуже болезни. > (Да, можно вспомнить draft про поле Auto-Submitted. Hо не все будут > его соблюдать. И какой уровень интеллекта нужен от почтовой системы, > чтобы отследить все виды циклов?) С другой стороны все это свидетельство невозможности решить уже полученные проблемы в рамках существующих rfc. Ищут люди. Hе все сразу. >>> Когда будет сделано, что все сервера в мире будут отдавать выдержки из >>> логов по запрошенному queue ID (при этом соблюдая должную security), >>> то это сведётся к проблеме написать такое пользуясь уже готовыми >>> механизмами. Hо так как условие выполнено не будет никогда - сочувствую >>> и рекомендую прекратить желать несбыточного ;)) > AB> А помечтать нельзя ? ;) > > Бутенко бы сказал здесь, что мечтать надо о вине и женщинах ;))) Пессимизм аскетов ! И то и другое надо иметь в реальности ;) А мечта должна быть далекой и недостижимой... Хотя если указанному месье это уже составляет предмет мечтаний ... ;) {шутка} -- Bye. Aleksey Barabanov <alekseybb at mail.ru> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: home (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/7824fc246db9.html, оценка из 5, голосов 10
|
|
|