|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 27 Aug 2002 22:52:39
To : "Leonid B. Toker"
Subject : Re: А кaк с тaким спaм ом бороться? :-(
--------------------------------------------------------------------------------
>>> Leonid B. Toker wrote:
VN>> Да, скорее всего. В любом случае, я говорю про встречный коннект по smtp
VN>> с mail from:<> и rcpt to:<предъявленный адрес>
LBT> У нас (cbr.ru), например, есть адреса (от которых делаются некоторые
LBT> автоматические рассылки полезной информации и от которых идет письмо
LBT> с заказанной через наш web-сайт информацией), для которых запрещен
LBT> прием почты. Таким образом, Ваши пользователи при включенной проверке
LBT> эту информацию не получат. (Я не знаю, может быть Вашим пользователям
LBT> она и не нужна, но, вероятно, есть и другие такие отправители).
Hе вы одни такие. Да, это фильтруется принципиально.
Если вы что-то посылаете и неспособны принять отлуп, по какой бы причине
он ни возник, то это значит, что вы совершенно не контролируете адреса
своей рассылки. Если вас не волнует, дойдет письмо или нет, то вы спамер
или полностью ему эквивалентны. Hе надо *здесь* ругаться, спорить или
опровергать это утверждение. Мы достаточно долго обдумывали такую ситуацию
и пришли именно к такому выводу. Более того, он формулируется иначе
(это и ответ на Ваше последующее
LBT> Hасколько я помню, нет RFC, который говорит об обязательности
LBT> приема почты на все отправляющие адреса. Если я ошибаюсь,
LBT> то поправьте меня.
) - адрес, на который невозможно передать почту, не существует.
Hикто не обязан принимать почту с несуществующего адреса.
Добавление с практики: когда была введена эта проверка, не было ни одной
жалобы пользователей на такой фильтр, включая некоторые крупные порталы.
Все случаи жалоб - кривые настройки релеев или иные ситуации технических
ошибок, или случаи попадания наших хостов в blacklists.
LBT> Мне встречались хосты, не разрешающие приема почты на адреса своих
LBT> MAILER-DAEMON'ов (пример сейчас не вспомню). Вы не будете принимать
LBT> уведомления от таких хостов?
Да, не будем, и будем спать по этому поводу совершенно спокойно.
И заметьте, что такая практика встречной проверки получает все большее
распространение.
LBT> А что Вы будете делать, если какая-либо организация разнесла свои MX-ы
LBT> и сервера, отправляющие почту вовне? IMHO, тоже не запрещено?
LBT> Или поставила почту на кластер, в результате чего соединение при отправке
LBT> почты идет от IP-адреса узла кластера, а не от того IP-адреса, который
LBT> указан в MX? А если при этом входящие соединения на адрес узла
LBT> кластера не принимаются?
Это не имеет значения (более того, у нас такой разнос тоже действует
и дает два разных почтовых субконтура). Встречная проверка делается не на
IP отправителя, а на MX'ер домена в envelope-from. Я указал на это,
хоть и вскользь.
VN>> 1. За отсутствием качественных доступных разборщиков rfc822 синтаксиса
VN>> (ну, то есть, у меня уже есть, но был доведен до ума позже) - все адреса
VN>> иного вида чем ^[A-Za-z0-9._-]+\@[A-Za-z0-9._-]+$ игнорируются.
LBT> Игнорируются в смысле письма отвергаются?
Игнорируются - такой адрес считается проверенно существующим.
LBT> Тогда надо как минимум добавить
LBT> '/' и '=' в локальной части адреса - для инкапсулированных X.400 адресов
LBT> и для адресов из HP OpenMail (или как он там сейчас называется),
LBT> если на нем Internet-gateway не настроен для работы со справочником.
Hеважно. Адрес иного вида чем подпадающий под
^[A-Za-z0-9._-]+\@[A-Za-z0-9._-]+$ на сейчас с вероятностью >99.9%
не будет учитываться спамером. Адреса с '/' и '=' в это входят.
Когда это изменится - тактика будет утончена. В первую очередь начиная
с полноценного разбора синтаксиса RFC822.
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
