Pull to refresh
Comments 30
я считаю что этот метод вообще не приемлем
так как письмо, которое является не_спамом вообще не пройдёт (а оно может быть очень важным...)

ИМХО, спам должен доходить до пользователя, но фильтроваться в отдельную директорию, чтобы можно было найти письмо, попавшее туда

Естественно, слепо блочить все, что залитено глупо. Но как первый рубеж DNSBL весьма не плох.
Метод сам по себе не дропает. Письмо, которое является не_спамом может пройти или не пройти, в зависимости от того, как настроен почтарь. Spamassassin, например, использует некоторые черные списки: письму начисляется несколько баллов, если IP источника обнаружен в одном из них. Пороговые значения, по достижении которых заголовок письма изменяется на «Осторожно, спам» или все письмо дропается определяет администратор почтовика.
Любой метод имеет свои ошибки. Но рассуждать надо не детскими фразами типа «метод Х вообще не приемлем» а пытаться определить ошибки первого и второго рода (flase positive, false negative) для каждого конкретного случая (метод X, настройки Y). И если метод имеет достаточно низкую FP при FN < 1, то его вполне стоит использовать. Что касается RBL все зависит от конкретного блэк-листа — среди них вполне можно найти такие, при использовании которых FP будет низкой. Разумеется и FN будет высокой но какую то часть спама этот RBL все же отсеет. А все что пройдет можно дальше фильтровать другими методами.

Что касается фильтрации в отдельную директорию то к RBL это не имеет никакого отношения, а вопрос совершенно отдельный. Замечу что у этого есть такие минусы:
— если туда будет складываться 100 писем ежедневно, то через какое то время Вы просто перестанете её просматривать, и складывание письма в эту папку будет равноценно его удалению.
— в случае если ошибку выдать на этапе SMTP сессии, то отправитель получит баунс и будет точно знать что его письмо не дошло и надо попробовать связаться другим способом (если отправитель не ламер и в состоянии прочесть баунс). Если письмо попало в папку спам, то отправитель ничего знать не будет.
Все эти DNSBL'и — чистое вымогательство. Подавляющее большинство спама рассылается с взломанных компьютеров рядовых пользователей, соответственно, блокировать «злобные спамерские сервера» смысла никакого. И вообще, владелец такого блек-листа может занести абсолютно любой IP в свой лист и требовать деньги за вынесение из листа. А заплатишь, будет требовать дальше (ты ж уже заплатил, значит можешь и будешь платить). Соответственно, с ними возможен только один разговор, как и с рекетирами — или милиция, или монтировкой по голове.
Вообще блокировка по домену или IP — это нонсенс. Масса пользователей, бывает, подписывается на рассылку, потом ее не читая отправляет в спам. И усе, — провайдер бесплатной почты блокирует отправителя, типа за спам.
Т.е. фактически порочна практика блокирования определенной точки за факт ее существования. Т.к. спамеров это *вообще* не останавливает, и, соответственно, страдают лишь честные бизнесы.
Из вымогательских DNSBL встречал только эти:
www.uceprotect.net
www.us.sorbs.net
Выносят ip за бабло и не дают никаких иллюстраций спама. Остальные black-листы довольно эффективны. Рассылка спама через взломанные аккаунты это проблема многих хостеров, и по black-листам можно реально смотреть картину зараженных серверов и выявлять нарушителей.
> Все эти DNSBL'и — чистое вымогательство
— не все. DNSBL'b, бывают очень разные. Если несколько из них используются для шантажа, это не значит что все остальные точно такие же.
> Вообще блокировка по домену или IP — это нонсенс
— не нонсенс, есть IP, вероятность отправки с которых хорошего письма стремится к нулю. Объясните зачем нужно принимать с них спам?
Хотелось бы статью по поводу методов поиска спамеров на сервере. К примеру, одна из текущих проблем — рассылка через dark mailer. Т.к. он коннектится напрямую к серверу получателя, в логах ничего не фиксируется.

На текущий момент придумал только способ борьбы с закачкой этого скрипта — запрет закачки специфических файлов скрипта, таких как sys/_*.mx
Это комплексная мера, и относится скорее к безопасности вообще, чем к почте.

Идеальный и гарантированно работающий вариант — вынести почтовик на отдельный сервер\VDS (настроив авторизацию и антиспам), а на основном запретить рассылку почты от nobody и коннекты на 25 порт на любые IP, кроме IP почтовика.
Достаточно просто закрыть 25 порт во внешний мир для всех пользователей, кроме того из под которого работает сервис отправки почты и будет вам счастье.
Особенно актуально для shared-хостинг-сервера или VDS-ноды, да.

Что будете делать с php-mail и отправкой из консоли? А вот вынос почты на отдельный сервер это решает. И в добавок дает кучу плюсов:

1) Безопасность. Взломали\заDDoSили почтовик — нет угрозы клиентам.
2) Защиту от блокировки за спам. Кто-то наспамил с сервера? Не страшно, в бан уезжает только почтовик, а не весь сервер — меняем IP и вышло счастье.
3) Возможность четко контролировать и учитывать количество отправленной почты.
4) Разгрузка основного сервера от задачи агрегации почты.
5) Один почтовик на 2-10-200 серверов (нет нужды следить, обновлять и настраивать все 200).
На нормальных хостингах пхп скрипты выполняются от правильного овнера, а не от nobody. По поводу мылосервера, например в postfix'e почту ты ему передаешь через sendmail который запускает suid'ный postdrop(почитать про архитектуру постфикса), ну и сам postfix работает из под своего пользователя в системе и из под него же отправляет почту. таким образом решается проблема с локальными пользователями.

А там свои тараканы. У гугля единая база «спамовых» серверов на всех пользователей (коих десятки тысяч). А теперь представьте — десяток тысяч подписался на рассылку, сотня (всего 1% !) забыла и отметила рассылку как спам. И ВСЕ! — рассылку, возможно, вполне полезную, из спама никто уже никак не достанет. И не только рассылку, но и весь домен. У Гугля в принципе нет процедуры вынесения из блек-листа.
Бросайте уже эти рассылки, они из эпохи Веб1.0. Сейчас юзают RSS
в rss нет обратной связи, а рассылки рулят, тематические
в своё время очень сильно настрадался из-за этих блэк листов. попав в него, каким-то загадочным образом без объяснения причин… :(

беда ещё заключалась в том, что некоторые «хостеры» достаточно редко обновляют блэк-листы. и приходится писать хостеру, чтобы он тебя «вычеркнул». так что до сих пор даже случаются случаи что почта «не ходит» — и это спустя 2-3-года.
<< Вы, конечно же, первым делом спрашиваете от кого было письмо, затем смотрите в логи и гордо сообщаете пользователю: “Ваш отправитель попал в черный список, ничего поделать не могу, проблема на их стороне”. С Вас взятки гладки, поскольку это ведь не Вы, а отправитель попал в черный список, но тем не менее вопрос недоставки честных писем остается не решенным. >> (http://woland.pl.ua/3-pochemu-ya-ne-ispolzuyu-dnsbl-v-pomoshh-nachinayushhemu-postmasteru/)

в общем, спам как приходил, так и приходит, а нужная почта страдает.

фиговый метод защиты от спама. простой и тупой(и не факт что эффективный) для админа, но приносящий головную боль всем остальным. тем более проблемы возрастают в кватрате если человек не знает что такое DNS/IP и слово домен для него это что-то абстрактное.
Свои черные списки надо вести и ни от кого не зависеть :)
мне кажется свои не получится, у них будет очень маленькая актуальность.
Вот опубликовали бы свои списки майл.ру и яндекс, было бы проще :)
Я свой веду — почти 30 тыщ адресов :) пополняется каждый день на тыщу-две…
Большая часть пользователей-администраторов просто не понимает что такое чёрные списки и как их использовать. Тот же sorbs представляет и параноидальные, и объективные списки, но почему-то горе-админы этого не хотят понять.

RBL это технология, _гораздо_ более распространенная, чем Greylisting.
К сожалению многие люди не могут понять, что RBL это именно технология, а не конкретные люди, и отождествляют все RBL с каким нибуть одним, негодным RBL утверждая что все RBL одинаково плохие. Таких людей легком можно увидеть в комментариях выше.
Статья прекрасная без лишних деталей но: где Вы видели такой IP 111.222.333.444?
Разве там не 4 байтовый числа (0-255)?
Only those users with full accounts are able to leave comments. Log in, please.