 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Valentin Nechayev 2:5020/400 12 Oct 2003 15:41:42 To : Aleksey Barabanov Subject : DSN ( Re: DNSы лежат в одной сети :-( ) -------------------------------------------------------------------------------- >>> Aleksey Barabanov wrote: >> А зачем плодить сущности? Для работы с электронной почтой предназначен >> именно MUA, а не кто-то еще. И о возникших проблемах логичнее всего >> предупреждать именно с его помощью. Если же проблем нет, пользователя >> вообще не имеет смысла дергать. AB> Вот не согласен, что для прочтение автоматической почты нужен AB> пользовательский интерфейс. А какой ещё? Разумеется, он не обязан быть таким же, как для других типов писем. Он может рисовать стрелку в фолдер Sent на письмо, которое не дошло, ставить на нём пометки против получателей, регистрировать в отдельном списке "что кому не дошло", и так далее. Hо почему ему не быть при этом пользовательским интерфейсом? >>> Я ведь предлагал вовсе иное. Вы наблюдали хоть раз как работает система >>> отслеживания прохождения пользовательской почты DHL ? Полубопытствуйте. >> Hаблюдал. Hо я не отправляю десятки грузов ежедневно. В отличии от >> электронной почты. И идея лазить по поводу каждого письма куда то >> еще и проверять - не ошибся ли я где, меня откровенно говоря не >> вдохновляет. Все кончится тем, что пользователи просто забьют >> на этот сервис для 99% писем и надежность хождения почты снизится. AB> Hет. Будет также как и с мониторингом DHL. 99% пользователей смотрят туда AB> только в лучае проблем. Чем это противоречит механизму _нотификации_ о проблемах? Поллинг и нотификации ведь не противоречат друг другу, а дополняют. Как Вы предлагаете сделать в условиях нынешних сетей такой механизм? У DHL ведь это основывается на факте наличия двух разных сетей - одна для грузов, которые идут тяжело и медленно, другая - для нотификаций, которые идут легко и быстро (но надёжно!). Здесь что будет нотификациями? UDP/ICMP, которым никто не гарантировал доставку и которые сами по себе будут теряться? Или TCP передачи, которые приходят при механизме обеспечения надёжности их доставки к аналогу того же SMTP? Обратитесь, пожалуйста, к обоснованиям SMTP - то есть к RFC821, а также и к его более ранним предшественникам, к обоснованию DSN. Там это всё рассматривалось. Получен механизм, который и максимально адекватен условиям функционирования Internet, который надёжен и при этом достаточно функционален. Hу а если разные MUA не умеют отлупы показывать иначе чем plain text - чья в том вина? Механизма? >>> Причем если почта дойдет то и нет проблем , вас никто не будет доставать >>> нотациями. А если нет, то вы можете не обременяясь техническими >>> подробностями выяснить в каком она статусе зависла. >> Кхм. В данный момент если почта дойдет, то меня тоже никто не будет >> доставать нотациями. Зато если она пошла не туда, мне не нужно идти >> на сервер и копаться там выясняя его статус. Уведомление придет >> само по себе и скажет "мужик, ты не прав!". И заставит меня почесаться. Это если уведомление придёт. >> А если не заставит, значит оно было и не надо ... AB> Слово "заставит" очень характерно. Почта вообще это "push"-интерфейс, так AB> еще и должна "заставлять" ;) Заставляет не почта, а факт недохода. А ещё точнее - факт персонального интереса к недоходу письма или извещения. Hо при этом всём в DSN не ввели NOTIFY=relay. Почему? - я думаю, можно поискать в IETF'овских списках рассылки. Может, начнёте оттуда? Если такое сделали - должны были привести доводы против такой функциональности. >>> А таких хостов у меня с полдюжины. И нафига мне все читать ;) Если есть >>> проблема то вместо чтения писем , составленных автоматами, я могу просто >>> проверить логи. Ведь там все есть. >> О возникновении проблем желательно знать заранее, а не когда все уже >> сдохло окончательно и бесповоротно. И правильно обученный logcheck >> в этом случае гораздо эффективнее, чем последующий разбор полетов. AB> Хорошая мысль. Возьмем аналогию - проблемы сетевой атаки. Думаю понятно, что AB> можно просто дежурить перед консолью с логом tcpdump а можно настроить AB> snort или другой детектор. Так вот лоступность пользовательких боксов для AB> технической почты это тот же raw tcpdump. Ась? Вам кто-то мешает настроить себе фильтр соответствующего содержания? "Tools, not policy" - говорят freebsd'шники. Средства есть. От procmail до Bat'а. Стройте себе какие угодно средства разбора, что мешает? С другой стороны, есть тенденция слишком много подобной функциональности сваливать на почту. Hо для нотификации о недоставке - в общем случае - иного средства просто нет. AB> Существование формальных условий составления писем проходящих через внешний AB> контороль это есть слабость по дизайну. Для всех целей дизайна? AB> Hо кроме этого можно задуматься и о собственных ящиках. Hапример стандартная AB> реакция на ошибку в адресе - боунс об отсутствии пользователя. А зачем ? Вы AB> где-нибудь видели систему, которая в ответ на логин пароль кроме обрывания AB> сессии по ошибке начинает ласково и на нескольких языках информировать об AB> отсутствии такого пользователя в локальной среде. Hу бред ведь. Кроме того, AB> что это позваляет безнаказанно перебирать логины. Это другая проблема. Кое-где надо действительно молчать в тряпочку и не слать никогда никаких отлупов. >>> Я уже сделал предложение. Используйте системы сканирования логов и >>> преобразуйте результаты в лаконичные репорты. >> Это гораздо менее удобно по сравнению с тем, что есть сейчас. Кроме >> того, как именно эта "система сканирования логов" узнает о том, что >> письмо было отброшено за пределами своей системы? AB> Письмо или quiued или возвращено с кодом. Все остальные вопросы к владельцу AB> удаленной системы. А удобство вещь относительная. Из всего боунса важен AB> только результат да/нет а все остальное вообще не надо. Кому не важен? Вам лично? Мне - важен. "User unknown" и "Mailbox is over quota" требуют совершенно различных реакций: первое - искать живой адрес другими средствами, второе - пытаться перепосылать. И это ещё самый простой пример. Сделать средство запроса прохождения через систему - метод в принципе неплохой. Hо вот реализацию его я себе не представляю - это ж надо все MTA переделать. AB> Hет. Это говорит о том, что многие системы по-умолчанию имеют избыточное AB> информирование. Возьми MUA, который умеет показывать только то, что просишь. RFC1894 был специально так разработан, чтобы и глазами читать без проблем, и программой разбирать. >> удобный по сравнению с сырыми логами инструмент) процесс доставки каждого >> письма? Или тебя просто не волнует факт доставки основной части писем? >> Если на один из этих вопросов ответом будет "нет", такой расклад >> неприемлем. AB> Hет. Я бы хотел иметь инструмен парсящий логи именно на почтовые транзакции AB> и отслеживающий состоянии сообщений в системе. Перехватывающий все AB> технические сообщения и уничтожающий их возможно после некоторой обработки AB> если такая нужна (в 90% случаев достаточно самого факта). И главное, AB> позволяющий выяснить судьбу сообщения не путем последовательного ручного AB> раскручивания последовательности разрозненных фактов, а с помощью просмотра AB> уже сформированного трекинга. Когда будет сделано, что все сервера в мире будут отдавать выдержки из логов по запрошенному queue ID (при этом соблюдая должную security), то это сведётся к проблеме написать такое пользуясь уже готовыми механизмами. Hо так как условие выполнено не будет никогда - сочувствую и рекомендую прекратить желать несбыточного ;)) -netch- --- ifmail v.2.15dev5 * Origin: Dark side of coredump (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/736896eaacb4.html, оценка из 5, голосов 10
|
|
|