Alexey Lobanov -> debian-russian@lists.debian.org @ Wed, 11 Oct 2006 18:07:37 +0400:
>> AL> Одна из идей: любая фильтрация на основе содержимого *текста* письма >> AL> (она же "цензура по содержанию") недопустима. >> Это экстремизм. AL> Так точно. Либеральный экстремизм. Мне лучше пропустить спам, чем убить AL> деловое письмо. В частности, контора занимается медицинскими AL> исследованиями, и мне совершенно не хочется проверять, как фильтр AL> отреагирует на регулярное упоминание в тексте известных препаратов фирмы AL> пфайзер :-) Так байесовская база обучаться умеет. Если этим не пренебрегать, то оно сочтет для данного места эти слова вполне нормальными. >> Все остальное спамер с легкостью подделывает. Ну, >> разве что кроме хоста-отправителя, но фильтровать по хосту-отправителю >> без ума (а экстремисты крайне редко с умом это делают) - это еще более >> убедительные грабли. Типичный случай - при таймауте соединения к >> DNS-серверу отбить письмо с 5xx вместо 4xx. Экстремисты вообще очень не >> любят кодов 4xx. AL> И определённая логика в этом есть. По 4xx письмо зависает между AL> серверами на неопределённое время, и судьба его неизвестна ни AL> отправителю, ни получателю. По 5xx отправитель хотя бы сразу узнаёт о AL> проблеме и (опять оптимистическое предположение...) может предпринять AL> активные действия по доставке информации другими средствами. Это пока у тебя никто ни на какие рассылки не подписан. А вот когда у тебя из-за перебоя в твоем канале менеджер не получит письмо от пфайзера, потому как оно рассылается по большому списку, и никто там никаких отлупов вообще не обрабатывает... >> AL> И, разумеется, фильтрация должна происходить на этапе входящей SMTP >> AL> сессии, а не после неё. Как у вас и сделано. Только в этом случае >> AL> легитимный отправитель сразу получит осмысленную диагностику ("ваш >> AL> сервер отсутствует в реверсном DNS...") и пойдёт либо к своему >> AL> почтмейстеру, либо к факсу. А жертвы joe-job не получат ложных >> AL> уведомлений. >> >> Во-первых. Это если письмо отфутболивается. Что не бессмысленно, да, >> но см. "во-вторых" и далее. Если же оно помечается как спам на основе >> содержимого, но проходит - цензура по содержимому вполне валидна. AL> Э... а смысл? Пометить и пропустить? Почему нельзя такое письмо AL> пропустить просто так, не помечая? Можно. Но я, скажем, свою папочку spam просматриваю по сабжам регулярно, но по диагонали. И не тогда, когда туда почта приехала, а тогда, когда у меня на это время есть. Сильно экономится время. После такого просмотра оно там еще неделю болтается. На случай, если я что-то проглядел. На заявление "я тебе письмо посылал" или в случае подозрения, что должно было приехать письмо из рассылки, я применю к оной папочке более целенаправленный поиск, и с шансами там оное письмо найду. >> При >> условии, что получатель в курсе, что такое спам, и куда его девают. И >> имеет к этому "куда" доступ. Это, разумеется, не исключает >> отфутболивания письма на уровне SMTP-сессии на основе вышепоскипанных >> экстремистских критериев. >> >> Во-вторых. Что очень важно. Типичный юзер, судя по рассказам админов, >> не умеет не то что прочесть сообщение об ошибке - ему не хватает ни IQ, >> ни дрессировки позвать админа при получении оного сообщения. Он его >> удаляет не глядя, а потом возмущается "почта не ходит". Причем, >> поскольку сообщение об ошибке уже удалено, выяснить, каким именно >> образом она не ходит в этот раз, не представляется возможным. AL> Дык, это чисто организационная проблема на стороне отправителя. И не нам AL> её решать. Максимум - давать осмысленную диагностику в 5xx, не "access AL> denied", а развёрнутую. Вплоть до "please contact [EMAIL PROTECTED]". С рассылками так бороться не получится. >> В-третьих. Возникают большие проблемы с резервными MX. Потому как для >> отфутболивания на уровне SMTP все MX'ы должны реагировать одинаково. AL> Да. И я согласен, что держать запасной MX на провайдерском релее - очень AL> плохое решение. По многим причинам. Например, этот самый провайдерский AL> релей имеет хорошие шансы регулярно влетать в spamcop и прочие bl по AL> причине "scattermail", принимая спам и червей для несуществующих ящиков AL> у клиента. AL> Если все MX-и контролируются владельцем домена, то проблемы нет. Если AL> почту принимает только провайдер на "виртуальный домен", то проблемы AL> тоже нет. У меня все MX'ы контролируются владельцем домена. Но у них существенно разные вычислительные мощности. На основном я могу устроить тщательную проверку, на резервном - только базовую. -- Artem Chuprina RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED] Обновление Windows изменило интуитивно ясный интерфейс Вашего компьютера. Загрузите обновление интуиции с сайта Microsoft. (С)энта -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]