|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 26 Aug 2002 00:33:12
To : Serge N Pokhodyaev
Subject : Re: А кaк с тaким спaм ом бороться? :-(
--------------------------------------------------------------------------------
>>> Serge N. Pokhodyaev wrote:
VN>> Есть относительно неплохой метод - немедленная встречная проверка
VN>> адреса отправителя. Hо оно не без изъянов.
SNP> Это которое в exim называется "Sender verification with callback"?
Да, скорее всего. В любом случае, я говорю про встречный коннект по smtp
с mail from:<> и rcpt to:<предъявленный адрес>
SNP> Какие именно там изъяны?
Мы делали такое же на milter. Проблемы:
1. За отсутствием качественных доступных разборщиков rfc822 синтаксиса
(ну, то есть, у меня уже есть, но был доведен до ума позже) - все адреса
иного вида чем ^[A-Za-z0-9._-]+\@[A-Za-z0-9._-]+$ игнорируются.
Hа качество проверки спамеров это не влияет - они не используют такие
символы и не будут - из-за тупых реализаций rfc822 во всяких exchange.
Особо пришлось отменить проверку адресов, содержащих '!'. Это вызвано массовой
генерацией обратных адресов вида system!domain!user@uucphost с UUCP серверов,
работающих с UUPC/Ache клиентами. (У нас это составляет достаточную часть
адресов, чтобы озаботиться.)
2. Масса хостов отвечает отказом на mail from:<>, иногда и на rcpt to
при таком mail from. Hа отказ принимать mail from:<>, сейчас вынуждены разрешать
прием - по статусу нельзя использовать rfc-ignorant в любом виде.
Hа rcpt to - случай клинический, отделить невозможно, терпим.
3. Проблема с алгоритмикой проверки - в частности, таймаутами резолвинга,
коннекта и прочего. Текущая реализация (milter server, мультитредовый клиент)
содержит общий кэш состояний по адресу и домену и имеет достаточно громоздкую
логику учета этих состояний (например, невозможность коннекта на любой MXер
приводит к откладыванию на полчаса приема с такого домена с кодом 4xx).
В случае exim'а, при отсутствии кэша результатов проверки, будет на порядок
хуже.
4. Проверка не работает на yahoo и еще на нескольких freemail'ах из-за того,
что на этапе rcpt to они всегда подтверждают наличие получателя.
Впрочем, случай массовых рассылок обычно является исключением - потому что
yahoo при выставленной ручной блокировке аккаунта отказывает по rcpt to,
это существенно помогает.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
