Alexey Lobanov -> Roman Sozinov @ Wed, 11 Oct 2006 16:34:48 +0400: AL> Одна из идей: любая фильтрация на основе содержимого *текста* письма AL> (она же "цензура по содержанию") недопустима.
Это экстремизм. Все остальное спамер с легкостью подделывает. Ну, разве что кроме хоста-отправителя, но фильтровать по хосту-отправителю без ума (а экстремисты крайне редко с умом это делают) - это еще более убедительные грабли. Типичный случай - при таймауте соединения к DNS-серверу отбить письмо с 5xx вместо 4xx. Экстремисты вообще очень не любят кодов 4xx. Вообще же для экстремистов лучший рецепт - всю не понравившуюся по любому критерию почту принимать в /dev/null. AL> И, разумеется, фильтрация должна происходить на этапе входящей SMTP AL> сессии, а не после неё. Как у вас и сделано. Только в этом случае AL> легитимный отправитель сразу получит осмысленную диагностику ("ваш AL> сервер отсутствует в реверсном DNS...") и пойдёт либо к своему AL> почтмейстеру, либо к факсу. А жертвы joe-job не получат ложных AL> уведомлений. Во-первых. Это если письмо отфутболивается. Что не бессмысленно, да, но см. "во-вторых" и далее. Если же оно помечается как спам на основе содержимого, но проходит - цензура по содержимому вполне валидна. При условии, что получатель в курсе, что такое спам, и куда его девают. И имеет к этому "куда" доступ. Это, разумеется, не исключает отфутболивания письма на уровне SMTP-сессии на основе вышепоскипанных экстремистских критериев. Во-вторых. Что очень важно. Типичный юзер, судя по рассказам админов, не умеет не то что прочесть сообщение об ошибке - ему не хватает ни IQ, ни дрессировки позвать админа при получении оного сообщения. Он его удаляет не глядя, а потом возмущается "почта не ходит". Причем, поскольку сообщение об ошибке уже удалено, выяснить, каким именно образом она не ходит в этот раз, не представляется возможным. В-третьих. Возникают большие проблемы с резервными MX. Потому как для отфутболивания на уровне SMTP все MX'ы должны реагировать одинаково. Иначе основной будет отфутболивать резервному, а тому, бедолаге, что делать? -- Artem Chuprina RFC2822: <ran{}ran.pp.ru> Jabber: [EMAIL PROTECTED] HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают. Victor Wagner в <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]