[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SPAM фильтрация



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 postmaster@mydomain".

С рассылками так бороться не получится.

 >> В-третьих.  Возникают большие проблемы с резервными 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: ran@jabber.ran.pp.ru

Обновление Windows изменило интуитивно ясный интерфейс Вашего компьютера.
Загрузите обновление интуиции с сайта Microsoft.
	(С)энта



Reply to: