Комментарии 30
НЛО прилетело и опубликовало эту надпись здесь
Естественно, слепо блочить все, что залитено глупо. Но как первый рубеж DNSBL весьма не плох.
Метод сам по себе не дропает. Письмо, которое является не_спамом может пройти или не пройти, в зависимости от того, как настроен почтарь. Spamassassin, например, использует некоторые черные списки: письму начисляется несколько баллов, если IP источника обнаружен в одном из них. Пороговые значения, по достижении которых заголовок письма изменяется на «Осторожно, спам» или все письмо дропается определяет администратор почтовика.
Любой метод имеет свои ошибки. Но рассуждать надо не детскими фразами типа «метод Х вообще не приемлем» а пытаться определить ошибки первого и второго рода (flase positive, false negative) для каждого конкретного случая (метод X, настройки Y). И если метод имеет достаточно низкую FP при FN < 1, то его вполне стоит использовать. Что касается RBL все зависит от конкретного блэк-листа — среди них вполне можно найти такие, при использовании которых FP будет низкой. Разумеется и FN будет высокой но какую то часть спама этот RBL все же отсеет. А все что пройдет можно дальше фильтровать другими методами.
Что касается фильтрации в отдельную директорию то к RBL это не имеет никакого отношения, а вопрос совершенно отдельный. Замечу что у этого есть такие минусы:
— если туда будет складываться 100 писем ежедневно, то через какое то время Вы просто перестанете её просматривать, и складывание письма в эту папку будет равноценно его удалению.
— в случае если ошибку выдать на этапе SMTP сессии, то отправитель получит баунс и будет точно знать что его письмо не дошло и надо попробовать связаться другим способом (если отправитель не ламер и в состоянии прочесть баунс). Если письмо попало в папку спам, то отправитель ничего знать не будет.
Что касается фильтрации в отдельную директорию то к RBL это не имеет никакого отношения, а вопрос совершенно отдельный. Замечу что у этого есть такие минусы:
— если туда будет складываться 100 писем ежедневно, то через какое то время Вы просто перестанете её просматривать, и складывание письма в эту папку будет равноценно его удалению.
— в случае если ошибку выдать на этапе SMTP сессии, то отправитель получит баунс и будет точно знать что его письмо не дошло и надо попробовать связаться другим способом (если отправитель не ламер и в состоянии прочесть баунс). Если письмо попало в папку спам, то отправитель ничего знать не будет.
НЛО прилетело и опубликовало эту надпись здесь
Из вымогательских DNSBL встречал только эти:
www.uceprotect.net
www.us.sorbs.net
Выносят ip за бабло и не дают никаких иллюстраций спама. Остальные black-листы довольно эффективны. Рассылка спама через взломанные аккаунты это проблема многих хостеров, и по black-листам можно реально смотреть картину зараженных серверов и выявлять нарушителей.
www.uceprotect.net
www.us.sorbs.net
Выносят ip за бабло и не дают никаких иллюстраций спама. Остальные black-листы довольно эффективны. Рассылка спама через взломанные аккаунты это проблема многих хостеров, и по black-листам можно реально смотреть картину зараженных серверов и выявлять нарушителей.
> Все эти DNSBL'и — чистое вымогательство
— не все. DNSBL'b, бывают очень разные. Если несколько из них используются для шантажа, это не значит что все остальные точно такие же.
> Вообще блокировка по домену или IP — это нонсенс
— не нонсенс, есть IP, вероятность отправки с которых хорошего письма стремится к нулю. Объясните зачем нужно принимать с них спам?
— не все. DNSBL'b, бывают очень разные. Если несколько из них используются для шантажа, это не значит что все остальные точно такие же.
> Вообще блокировка по домену или IP — это нонсенс
— не нонсенс, есть IP, вероятность отправки с которых хорошего письма стремится к нулю. Объясните зачем нужно принимать с них спам?
Хотелось бы статью по поводу методов поиска спамеров на сервере. К примеру, одна из текущих проблем — рассылка через dark mailer. Т.к. он коннектится напрямую к серверу получателя, в логах ничего не фиксируется.
На текущий момент придумал только способ борьбы с закачкой этого скрипта — запрет закачки специфических файлов скрипта, таких как sys/_*.mx
На текущий момент придумал только способ борьбы с закачкой этого скрипта — запрет закачки специфических файлов скрипта, таких как sys/_*.mx
Это комплексная мера, и относится скорее к безопасности вообще, чем к почте.
Идеальный и гарантированно работающий вариант — вынести почтовик на отдельный сервер\VDS (настроив авторизацию и антиспам), а на основном запретить рассылку почты от nobody и коннекты на 25 порт на любые IP, кроме IP почтовика.
Идеальный и гарантированно работающий вариант — вынести почтовик на отдельный сервер\VDS (настроив авторизацию и антиспам), а на основном запретить рассылку почты от nobody и коннекты на 25 порт на любые IP, кроме IP почтовика.
Достаточно просто закрыть 25 порт во внешний мир для всех пользователей, кроме того из под которого работает сервис отправки почты и будет вам счастье.
Особенно актуально для shared-хостинг-сервера или VDS-ноды, да.
Что будете делать с php-mail и отправкой из консоли? А вот вынос почты на отдельный сервер это решает. И в добавок дает кучу плюсов:
1) Безопасность. Взломали\заDDoSили почтовик — нет угрозы клиентам.
2) Защиту от блокировки за спам. Кто-то наспамил с сервера? Не страшно, в бан уезжает только почтовик, а не весь сервер — меняем IP и вышло счастье.
3) Возможность четко контролировать и учитывать количество отправленной почты.
4) Разгрузка основного сервера от задачи агрегации почты.
5) Один почтовик на 2-10-200 серверов (нет нужды следить, обновлять и настраивать все 200).
Что будете делать с php-mail и отправкой из консоли? А вот вынос почты на отдельный сервер это решает. И в добавок дает кучу плюсов:
1) Безопасность. Взломали\заDDoSили почтовик — нет угрозы клиентам.
2) Защиту от блокировки за спам. Кто-то наспамил с сервера? Не страшно, в бан уезжает только почтовик, а не весь сервер — меняем IP и вышло счастье.
3) Возможность четко контролировать и учитывать количество отправленной почты.
4) Разгрузка основного сервера от задачи агрегации почты.
5) Один почтовик на 2-10-200 серверов (нет нужды следить, обновлять и настраивать все 200).
На нормальных хостингах пхп скрипты выполняются от правильного овнера, а не от nobody. По поводу мылосервера, например в postfix'e почту ты ему передаешь через sendmail который запускает suid'ный postdrop(почитать про архитектуру постфикса), ну и сам postfix работает из под своего пользователя в системе и из под него же отправляет почту. таким образом решается проблема с локальными пользователями.
корпоративная почта gmail Вам в помощь.
в своё время очень сильно настрадался из-за этих блэк листов. попав в него, каким-то загадочным образом без объяснения причин… :(
беда ещё заключалась в том, что некоторые «хостеры» достаточно редко обновляют блэк-листы. и приходится писать хостеру, чтобы он тебя «вычеркнул». так что до сих пор даже случаются случаи что почта «не ходит» — и это спустя 2-3-года.
<< Вы, конечно же, первым делом спрашиваете от кого было письмо, затем смотрите в логи и гордо сообщаете пользователю: “Ваш отправитель попал в черный список, ничего поделать не могу, проблема на их стороне”. С Вас взятки гладки, поскольку это ведь не Вы, а отправитель попал в черный список, но тем не менее вопрос недоставки честных писем остается не решенным. >> (http://woland.pl.ua/3-pochemu-ya-ne-ispolzuyu-dnsbl-v-pomoshh-nachinayushhemu-postmasteru/)
в общем, спам как приходил, так и приходит, а нужная почта страдает.
фиговый метод защиты от спама. простой и тупой(и не факт что эффективный) для админа, но приносящий головную боль всем остальным. тем более проблемы возрастают в кватрате если человек не знает что такое DNS/IP и слово домен для него это что-то абстрактное.
беда ещё заключалась в том, что некоторые «хостеры» достаточно редко обновляют блэк-листы. и приходится писать хостеру, чтобы он тебя «вычеркнул». так что до сих пор даже случаются случаи что почта «не ходит» — и это спустя 2-3-года.
<< Вы, конечно же, первым делом спрашиваете от кого было письмо, затем смотрите в логи и гордо сообщаете пользователю: “Ваш отправитель попал в черный список, ничего поделать не могу, проблема на их стороне”. С Вас взятки гладки, поскольку это ведь не Вы, а отправитель попал в черный список, но тем не менее вопрос недоставки честных писем остается не решенным. >> (http://woland.pl.ua/3-pochemu-ya-ne-ispolzuyu-dnsbl-v-pomoshh-nachinayushhemu-postmasteru/)
в общем, спам как приходил, так и приходит, а нужная почта страдает.
фиговый метод защиты от спама. простой и тупой(и не факт что эффективный) для админа, но приносящий головную боль всем остальным. тем более проблемы возрастают в кватрате если человек не знает что такое DNS/IP и слово домен для него это что-то абстрактное.
SPF рулит :) ну и серые списки
Большая часть пользователей-администраторов просто не понимает что такое чёрные списки и как их использовать. Тот же sorbs представляет и параноидальные, и объективные списки, но почему-то горе-админы этого не хотят понять.
RBL это технология, _гораздо_ более распространенная, чем Greylisting.
Статья прекрасная без лишних деталей но: где Вы видели такой IP 111.222.333.444?
Разве там не 4 байтовый числа (0-255)?
Разве там не 4 байтовый числа (0-255)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почтовая кухня #3: DNSBL — Что такое DNS blacklist и с чем их едят