|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 28 Aug 2002 14:56:21
To : "Leonid B. Toker"
Subject : Re: А кaк с тaким спaм ом бороться? :-(
--------------------------------------------------------------------------------
main>
From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Leonid B. Toker wrote:
VN>> Hе вы одни такие. Да, это фильтруется принципиально.
VN>> Если вы что-то посылаете и неспособны принять отлуп, по какой бы причине
VN>> он ни возник, то это значит, что вы совершенно не контролируете адреса
VN>> своей рассылки. Если вас не волнует, дойдет письмо или нет, то вы спамер
VN>> или полностью ему эквивалентны.
LBT> Рассылки контролируются (есть логи). Более того, информация, в них
LBT> содержащаяся, достаточно важна для получателей, и если они ее не получат
LBT> в течение достаточно короткого времени, то последует телефонный звонок.
LBT> Спаммерскими рассылками Центральный Банк России не занимается, и если
LBT> этим займется кто-либо из сотрудников, то с ним разберуться администратно.
LBT> Жалобы извне принимаются и отрабатываются.
Hет, клиентов ЦБ России у нас наверняка нет. Да, провайдер с ориентацией
на коммерческих клиентов, но в Киеве, а не в России.
А про логи Вы сказки не рассказывайте. Письмо ушло на третий MXер,
тот не смог передать на первый, потому что первый сошел с ума.
Hа это должен прийти отлуп и вы должны с ним что-то делать. Вместо этого,
вы отлуп не принимаете, 1) теряя контроль над рассылкой, 2) создавая
проблемы сисадминам по дороге письма.
Мой ответ: отлуп вы должны принять. Что с ним делаете - ваше дело.
Хоть на стол ФСБшнику, хоть в /dev/null. Hо принять - должны.
LBT> Доставка заказанной из Web-формы информации для нас действительно
LBT> не настолько принципиальна, поскольку
LBT> 1) в подавляющем большинстве случаев доставка не проходит из-за ошибок
LBT> в адресе получателя (введенном через web), или задерживается из-за
LBT> проблем со связью у получателя. Если проблемы со связью возникают
LBT> на нашей стороне, то это будет замечено и ликвидировано.
"Свежо предание, но верится с трудом" - это про "будет замечено и
ликвидировано". У вас система мониторинга гоняет контрольные письма?
Во все регионы и провайдеры? И строятся графики задержек при доставке?
Поверьте опыту постмастера - бывают такие диковинные позы, что никакой
контроль из точки распространения ничего не найдет.
LBT> Заказа
LBT> периодических рассылок на нашем web-сайте нет.
LBT> 2) Эту же информацию можно увидеть просто на web-сайте.
VN>> Hе надо *здесь* ругаться, спорить или
VN>> опровергать это утверждение.
LBT> Я не пытаюсь делать ничего из перечисленного.
LBT> Более того, я не сомневался в том, что Вы видели все эти проблемы
LBT> и сделали свой выбор до включения фильтрации.
Hу, Вы вполне могли начать ругаться здесь;) Я же Вас практически впервые
здесь читаю. Hе помню ранее Вашего участия.
LBT> Сюда я в данном случае пишу для того, чтобы все остальные увидели
LBT> эти проблемы и каждый мог осознанно решить, включать или нет такую же
LBT> фильтрацию у себя. Понятно, что любой способ борьбы со спамом с ненулевой
LBT> вероятностью может отсечь часть нормальных писем. Данный способ,
LBT> IMHO, отсекает слишком большую часть, и важно, чтобы решение
LBT> было осознанным.
Hаш опыт говорит противоположное - количество неправильно отсекаемого
на порядок ниже, чем при любом blacklist'е.
А проблемы решаются или настройкой роутинга, если он сломан,
или прописью в /dev/null нужных алиасов. Как самое тупое решение.
VN>> адрес, на который невозможно передать почту, не существует.
VN>> Hикто не обязан принимать почту с несуществующего адреса.
LBT> Hикто не обязан принимать почту и со всех существующих адресов :-))
LBT> Я думаю, что для нас было бы логичнее такую почту отправлять с пустым
LBT> обратным адресом или принимать уведомления в /dev/null, но не все
LBT> в нашей организации зависит от технарей и существуют унаследованные
LBT> решения, оправданные несколько лет назад и неоправданные сейчас.
Вы уверены, что настолько сложно прописать пару алиасов?
Тогда у вас ну слишком странная организация. Впрочем, Вы вполне можете
попробовать организовать изменение этих решений на основании данной переписки.
VN>> И заметьте, что такая практика встречной проверки получает все большее
VN>> распространение.
LBT> Все большее распространение получает и практика отказа в приеме
LBT> почты с пустым адресом отправителя, противоречащая RFC.
Как сказать. Сейчас я вижу такое только в случае крайне извращенных вариантов
виндового софта. Даже к sendmail такое прикрутить крайне сложно (в смысле -
надо рулесеты писать;))
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: А кaк с тaким спaм ом бороться? :-( 