 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Aleksey Barabanov 2:5020/400 12 Oct 2003 17:57:44 To : Valentin Nechayev Subject : Re: DSN ( Re: DNSы лежат в одной сети :-( ) -------------------------------------------------------------------------------- .ua> From: Aleksey Barabanov <abb@wessen.ru> Valentin Nechayev wrote: > AB> Вот не согласен, что для прочтение автоматической почты нужен > AB> пользовательский интерфейс. > > А какой ещё? > Разумеется, он не обязан быть таким же, как для других типов писем. > Он может рисовать стрелку в фолдер Sent на письмо, которое не дошло, > ставить на нём пометки против получателей, регистрировать в отдельном > списке "что кому не дошло", и так далее. Hо почему ему не быть при этом > пользовательским интерфейсом? Здесь вы просто предлагаете отимпрувить соответственным образом сам MUA. Согласен. Авторы и авторские коллективы имеют публичные адреса. Если прислушаются, то всем будет хорошо. Hо можно и не дожидаясь пока они это сделают решить вопрос точно также как решается проблема с DSN с последнего хоста с DSN-поддержкой ;) > Обратитесь, пожалуйста, к обоснованиям SMTP - то есть к RFC821, а также > и к его более ранним предшественникам, к обоснованию DSN. Там это всё > рассматривалось. Получен механизм, который и максимально адекватен > условиям функционирования Internet, который надёжен и при этом достаточно > функционален. Hу а если разные MUA не умеют отлупы показывать иначе чем > plain text - чья в том вина? Механизма? Это не вина. Это изменившаяся ситуация. Посмотрите статистику фильтрации спама на публичных почтовых системах. Такого ведь раньше не было. Раньше ведь никто не предлагал специально изменять ответы почтовых систем на неадэкватные. > Заставляет не почта, а факт недохода. А ещё точнее - факт персонального > интереса к недоходу письма или извещения. Тут вопрос не в интересе. У хоста получателя вообще нет никакого интереса. Он даже не предполагает что ему идет письмо. И когда письмо приходит, то хост получатель принимает его за свой счет даже не зная ничего о содержимом. А всякого рода технические сообщения, идущие через "зеленый коридор", это классный способ подать внутрь системы вообще любой траффик. > Ась? Вам кто-то мешает настроить себе фильтр соответствующего содержания? > "Tools, not policy" - говорят freebsd'шники. Средства есть. От procmail > до Bat'а. Стройте себе какие угодно средства разбора, что мешает? > > С другой стороны, есть тенденция слишком много подобной функциональности > сваливать на почту. Hо для нотификации о недоставке - в общем случае - > иного средства просто нет. ;) Hу спасибо что хоть оставили лазейку "с другой стороны" ;) > AB> Существование формальных условий составления писем проходящих через > внешний AB> контороль это есть слабость по дизайну. > > Для всех целей дизайна? Да. Если в файрволе есть открытый порт, то стойкость защиты снижается до стойкости листенера на этом порту. Здесь точно также : если есть что-то принимаемое в обязательном порядке в зависимости от формальных признаков, то сразу возникает вероятность подделки именно этих признаков. > AB> Hо кроме этого можно задуматься и о собственных ящиках. Hапример > стандартная AB> реакция на ошибку в адресе - боунс об отсутствии > пользователя. А зачем ? Вы AB> где-нибудь видели систему, которая в ответ > на логин пароль кроме обрывания AB> сессии по ошибке начинает ласково и на > нескольких языках информировать об AB> отсутствии такого пользователя в > локальной среде. Hу бред ведь. Кроме того, AB> что это позваляет > безнаказанно перебирать логины. > > Это другая проблема. Кое-где надо действительно молчать в тряпочку > и не слать никогда никаких отлупов. Двойной стандарт ;) > Кому не важен? Вам лично? Мне - важен. > "User unknown" и "Mailbox is over quota" требуют совершенно различных > реакций: первое - искать живой адрес другими средствами, второе - пытаться > перепосылать. И это ещё самый простой пример. Хороший пример. Это свидетельствует, что нужен дифференцированный подход. Процитирую : "Это другая проблема" ;) > Сделать средство запроса прохождения через систему - метод в принципе > неплохой. Hо вот реализацию его я себе не представляю - это ж надо все MTA > переделать. Hу я не могу дать на все свои ответы. У меня пока больше вопросов. Hо если говорить о конкретике, то грейлисты это уже эквивалент системы с запросом. > > AB> Hет. Это говорит о том, что многие системы по-умолчанию имеют > избыточное AB> информирование. > > Возьми MUA, который умеет показывать только то, что просишь. > RFC1894 был специально так разработан, чтобы и глазами читать без проблем, > и программой разбирать. Я знаю такого клиента - лотус ноутс. Hо мне не подходит в силу проприетарности и несоблюдения открытых стандартов Сети. > Когда будет сделано, что все сервера в мире будут отдавать выдержки из > логов по запрошенному queue ID (при этом соблюдая должную security), > то это сведётся к проблеме написать такое пользуясь уже готовыми > механизмами. Hо так как условие выполнено не будет никогда - сочувствую и > рекомендую прекратить желать несбыточного ;)) А помечтать нельзя ? ;) -- Bye. Aleksey Barabanov <alekseybb at mail.ru> Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: home (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/7824e6e2c681.html, оценка из 5, голосов 10
|
|
|