 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Valentin Nechayev 2:5020/400 12 Oct 2003 20:11:37 To : Aleksey Barabanov Subject : Re: DSN ( Re: DNSы лежат в одной сети :-( ) -------------------------------------------------------------------------------- .ua> <4elbmb-bd3.ln@abb.wessen.ru> From: Valentin Nechayev <netch@segfault.kiev.ua> >>> Aleksey Barabanov wrote: > AB>> Вот не согласен, что для прочтение автоматической почты нужен > AB>> пользовательский интерфейс. >> А какой ещё? >> Разумеется, он не обязан быть таким же, как для других типов писем. >> Он может рисовать стрелку в фолдер Sent на письмо, которое не дошло, >> ставить на нём пометки против получателей, регистрировать в отдельном >> списке "что кому не дошло", и так далее. Hо почему ему не быть при этом >> пользовательским интерфейсом? AB> Здесь вы просто предлагаете отимпрувить соответственным образом сам MUA. AB> Согласен. Авторы и авторские коллективы имеют публичные адреса. Если AB> прислушаются, то всем будет хорошо. Hо можно и не дожидаясь пока они это AB> сделают решить вопрос точно также как решается проблема с DSN с последнего AB> хоста с DSN-поддержкой ;) Она не решится таким образом, каким Вы предлагаете. Если отлупы не будут доходить до своего получателя, и никакой альтернативы предложено не будет, то он вообще никак не сможет узнать, что что-то не так. Если за него их будет читать эникейщик, получится дополнительный дорогостоящий файрволл, который будет жрать ресурсы и недостаточно давать взамен. И что дальше? Так можно наворачивать слой на слой, пока не придём к тому, что вообще никто не станет через эти слои пробиваться. >> Обратитесь, пожалуйста, к обоснованиям SMTP - то есть к RFC821, а также >> и к его более ранним предшественникам, к обоснованию DSN. Там это всё >> рассматривалось. Получен механизм, который и максимально адекватен >> условиям функционирования Internet, который надёжен и при этом достаточно >> функционален. Hу а если разные MUA не умеют отлупы показывать иначе чем >> plain text - чья в том вина? Механизма? AB> Это не вина. Это изменившаяся ситуация. Посмотрите статистику фильтрации AB> спама на публичных почтовых системах. Такого ведь раньше не было. Раньше AB> ведь никто не предлагал специально изменять ответы почтовых систем на AB> неадэкватные. Hу, я меры вроде того же challenge-based greylisting не рекомендую. >> Заставляет не почта, а факт недохода. А ещё точнее - факт персонального >> интереса к недоходу письма или извещения. AB> Тут вопрос не в интересе. У хоста получателя вообще нет никакого интереса. AB> Он даже не предполагает что ему идет письмо. И когда письмо приходит, то AB> хост получатель принимает его за свой счет даже не зная ничего о AB> содержимом. А всякого рода технические сообщения, идущие через "зеленый AB> коридор", это классный способ подать внутрь системы вообще любой траффик. Где Вы увидели "зелёный коридор" для технических сообщений? > AB>> Существование формальных условий составления писем проходящих через >> внешний AB> контороль это есть слабость по дизайну. >> Для всех целей дизайна? AB> Да. Если в файрволе есть открытый порт, то стойкость защиты снижается до AB> стойкости листенера на этом порту. Здесь точно также : если есть что-то AB> принимаемое в обязательном порядке в зависимости от формальных признаков, AB> то сразу возникает вероятность подделки именно этих признаков. Да, но смысл подделки резко ограничивается. Можно подделать отлуп именно с целью прислать поддельный отлуп, чтобы сделать вид, что адрес не работает. Это отдельная проблема, которой нет решения в рамках существующих технологий. Hо спам втиснуть в такие рамки уже не получится, и интерес к широкой атаке такими средствами пропадёт. > AB>> Hо кроме этого можно задуматься и о собственных ящиках. Hапример >> стандартная AB> реакция на ошибку в адресе - боунс об отсутствии >> пользователя. А зачем ? Вы AB> где-нибудь видели систему, которая в ответ >> на логин пароль кроме обрывания AB> сессии по ошибке начинает ласково и на >> нескольких языках информировать об AB> отсутствии такого пользователя в >> локальной среде. Hу бред ведь. Кроме того, AB> что это позваляет >> безнаказанно перебирать логины. Кто там у Вас рвёт форматирование? >> Это другая проблема. Кое-где надо действительно молчать в тряпочку >> и не слать никогда никаких отлупов. AB> Двойной стандарт ;) Почему? Такие случаи очень редки, IMO. >> Сделать средство запроса прохождения через систему - метод в принципе >> неплохой. Hо вот реализацию его я себе не представляю - это ж надо все MTA >> переделать. AB> Hу я не могу дать на все свои ответы. У меня пока больше вопросов. Hо если AB> говорить о конкретике, то грейлисты это уже эквивалент системы с запросом. Угу. И challenge-based greylisting даёт ещё один поток мусора, сгенерированного уже владельцем подобной системы - он будет фактически слать отлуп на каждое пришедшее письмо, не имея никакого представления о подлинности envelope-from письма. Причём если его оформлять как отлуп - он может не пройти через контроль, а в некоторых случаях вообще нельзя будет такое послать; если нет - результатом могут быть вечные циклы взаимных "пришлите мне куку xxx чтобы письмо принялось". Лечение хуже болезни. (Да, можно вспомнить draft про поле Auto-Submitted. Hо не все будут его соблюдать. И какой уровень интеллекта нужен от почтовой системы, чтобы отследить все виды циклов?) > AB>> Hет. Это говорит о том, что многие системы по-умолчанию имеют >> избыточное AB> информирование. >> >> Возьми MUA, который умеет показывать только то, что просишь. >> RFC1894 был специально так разработан, чтобы и глазами читать без проблем, >> и программой разбирать. AB> Я знаю такого клиента - лотус ноутс. Hо мне не подходит в силу AB> проприетарности и несоблюдения открытых стандартов Сети. Hу, раз есть один - будет и больше, нес па? ;))) >> Когда будет сделано, что все сервера в мире будут отдавать выдержки из >> логов по запрошенному queue ID (при этом соблюдая должную security), >> то это сведётся к проблеме написать такое пользуясь уже готовыми >> механизмами. Hо так как условие выполнено не будет никогда - сочувствую и >> рекомендую прекратить желать несбыточного ;)) AB> А помечтать нельзя ? ;) Бутенко бы сказал здесь, что мечтать надо о вине и женщинах ;))) -netch- --- ifmail v.2.15dev5 * Origin: Dark side of coredump (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/736882b9d21e.html, оценка из 5, голосов 10
|
|
|