> Все эти DNSBL'и — чистое вымогательство
— не все. DNSBL'b, бывают очень разные. Если несколько из них используются для шантажа, это не значит что все остальные точно такие же.
> Вообще блокировка по домену или IP — это нонсенс
— не нонсенс, есть IP, вероятность отправки с которых хорошего письма стремится к нулю. Объясните зачем нужно принимать с них спам?
Любой метод имеет свои ошибки. Но рассуждать надо не детскими фразами типа «метод Х вообще не приемлем» а пытаться определить ошибки первого и второго рода (flase positive, false negative) для каждого конкретного случая (метод X, настройки Y). И если метод имеет достаточно низкую FP при FN < 1, то его вполне стоит использовать. Что касается RBL все зависит от конкретного блэк-листа — среди них вполне можно найти такие, при использовании которых FP будет низкой. Разумеется и FN будет высокой но какую то часть спама этот RBL все же отсеет. А все что пройдет можно дальше фильтровать другими методами.
Что касается фильтрации в отдельную директорию то к RBL это не имеет никакого отношения, а вопрос совершенно отдельный. Замечу что у этого есть такие минусы:
— если туда будет складываться 100 писем ежедневно, то через какое то время Вы просто перестанете её просматривать, и складывание письма в эту папку будет равноценно его удалению.
— в случае если ошибку выдать на этапе SMTP сессии, то отправитель получит баунс и будет точно знать что его письмо не дошло и надо попробовать связаться другим способом (если отправитель не ламер и в состоянии прочесть баунс). Если письмо попало в папку спам, то отправитель ничего знать не будет.
Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME.
The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.
Я не зря выше написал «адекватные RBL». Если вы берете первый попавшийся RBL не узнав о нем ничего, то ложным срабатываниям удивляться не стоит.
У того же спамхауса есть несколько разных RBL с разным уровнем ложных срабатываний:
SBL — сюда заносятся сети используемые спамеров, или сети провайдеров, помогающим спамеров. Например в SBL попадали сети РТКомм и Ди-Нет (msm.ru), когда они размещали в своих сетях сервера спамеров и отказывались прекращать их хостинг. Этот RBL использовать в общем случае не стоит, потому что когда банится целая сетка, велика вероятность что пострадают невиновные клиенты этих ISP.
PBL — сюда тоже попадают целые сетки, но не предназначенные для размещения почтовые серверов — пулы динамических клиентских IP адресов. Несмотря на то, что заносятся целые сетки ложных срабатываний относительно мало. Например вероятность того, что вам нужно будет принять письмо из сетки 59.50.0.0/15 (адреса *.dynamic.163data.com.cn) крайне низка а спама оттуда идет много. Так что PBL вполне можно использовать, возможно не как единственный критерий, а в комплексе с чем то еще.
XBL — в него попадают отдельные IP затрояненных машин. Ложных срабатываний очень мало. Проблемы с использованием XBL я встречал только такого вида — на сервере один и тот же IP используется для почтового сервера и для NAT-а затрояненных виндовых рабочих станций. Т. е. с одной стороны оттуда сыплется спам, с другой стороны с почтового сервера на этом же IP может прийти нужное письмо. Но бывает это редко и в целом я рекомендую XBL для использования.
ZEN — включает в себя XBL, PBL, SBL — не рекомендую использовать по той причине что содержит SBL.
для богатых это поставить нужно число серверов, которые в состоянии обработать все входящие соединения, а затем отсеивать спамеров по признакам более надежным, чем отправка на первичный MX — начиная от RBL и проверки helo, заканчивая фильтрацией по содержимому письма.
если использовать адекватные RBL и правила для проверки helo то это отсеет примерно то же количество спамботов, что и fake mx, но без негативного эффекта в виде задержки при приеме почты с хороших серверов.
У spf есть как минимум одна серьезная проблема — редиректы писем. Например:
есть домен @foo.ru у которого в spf записи написано что письма из этого домена могут отправляться только с IP 10.10.10.10
пользователь sender@foo.ru отправляет письмо но some@mail.ru
с ящика some@mail.ru стоит редирект на some@firma.ru
почтовый сервер firma.ru видит письмо из домена @foo.ru но не с адреса 10.10.10.10 и не принимает такое письмо.
отправитель получает баунс.
у мыла.ру в spf указано ip4:subnet/shortmask потому что входящие сервера (указанные в mx-записи) и исходящие (указанные в spf) имеют разные IP адреса. Для домена, где все живет на одном сервере можно указать mx
Фейковый mx — это способ снизить нагрузку на сервера для бедных, если нет ресурсов обрабатывать все входящие соединения от многочисленных спамботов и рассказывать им что они в блэклисте. А количество спама это IMHO уменьшает только если не используется никаких других мер защиты от спама. Более того при исправно работающем приоритетном MX-е на запасной ходят преимущественно спамботы (но иногда туда почему то идут и хорошие сервера, типа mail.ru). А письма от нормальных почтовых серверов будут доставляться с задержкой, как и при использовании грейлистинга (который защищает от спама эффективнее fake mx).
У меня 135 RSS-ок и поскольку многие из них обновляются редко суммарный поток сообщений не очень большой. Самый активный RSS-поток — Хабр (762 в месяц) и от него я периодически думаю отписаться дабы меньше времени тратить на чтение RSS.
Не вижу поводов для радости. Монополизация рынка ни к чему хорошему не приведёт. Когда они окончательно вытеснят конкурентов их качество начнёт падать.
Они заботятся только о своих пользователях, но наплевательски отностяся к чужим. Если с адреса user@gmail.com рассылкается спам на другие почтовые сервера, то ни его не трогают. Жалобы которые я им пробовал писать на abuse@ они игнорируют.
Там хоть люди отвечают, значит не все потеряно. Есть много хостеров, которые на abuse@ не отвечают в принципе. Скорее всего им идёт такой большой поток жалоб, что они их просто не читают.
> 7 дней Ядерные реакторы воспламеняются или плавятся, так как перестают работать их системы водяного охлаждения.
IMHO АЭС может проработать минимум несколько месяцев после исчезновения людей, на автоматике. Пока не сломается какая нибудь часть, которая будет требовать ручной замены.
Надеюсь попытки борцов за copyright поглотить все, это агония умирающего монстра...
К тому же не надо забывать на Китай. Их много и плевать они хотели на американские медакорпорации готовые обложить копирайтом все.
На gmail спам тоже приходит, более того провести однозначную границу между спамом и не спамом просто невозможно.
Письмо с коммерческим предложением является не спамом если до этого я говорил с менеджером по телефону и просил скинуть его на почту.
И точно такое же письмо является спамом если я его не просил.
Разумеется это не серебряная пуля и тем более сам он ничего не делает, но тем кто ещё не знает о таком варианте (но работает над нагруженным проектом работающим на N серверах) нужно как минимум знать о нем.
1. Мы храним в memcached не готовые страницы (они разные и кэшировать их бессмысленно), а различные данные, которые в маленьких проектах можно на каждый запрос собирать из базы и других источников. Но в больших это становится накладно.
Разумеется нужно помнить об инвалиданции (или обновлении) кэша при изменении данных, поэтому для ненагруженных проектов это только лишнее усложнение кода.
2. В memcached хранятся данные которые вообще никогда не пишутся на диск (в базу), например число неудачных попыток ввести пароль для замедления подбора паролей. С учётом того, что некоторые пытаются подбирать пароли со скорость 100 (и больше) запросов в секунду, на sql это создаёт заметную нагрузку. А после перезагрузки мемкешеда подибральщик все равно снова упрётся в лимит и в потере этих счётчиков при перезагрузке memcached ничего страшного нет. Если поискать то в больших проектах таких данных (которые не иногда жалко терять) набирается достаточно, чтобы намmemcached сэкономить несколько SQL-серверов.
Поскольку это не было написано выше, упомяну, что для кэширования в больших проектов удобно использовать memcached.
И не только для кэширования, но и как хранилище данных, которые не жалко потерять при перезагрузке.
— не все. DNSBL'b, бывают очень разные. Если несколько из них используются для шантажа, это не значит что все остальные точно такие же.
> Вообще блокировка по домену или IP — это нонсенс
— не нонсенс, есть IP, вероятность отправки с которых хорошего письма стремится к нулю. Объясните зачем нужно принимать с них спам?
Что касается фильтрации в отдельную директорию то к RBL это не имеет никакого отношения, а вопрос совершенно отдельный. Замечу что у этого есть такие минусы:
— если туда будет складываться 100 писем ежедневно, то через какое то время Вы просто перестанете её просматривать, и складывание письма в эту папку будет равноценно его удалению.
— в случае если ошибку выдать на этапе SMTP сессии, то отправитель получит баунс и будет точно знать что его письмо не дошло и надо попробовать связаться другим способом (если отправитель не ламер и в состоянии прочесть баунс). Если письмо попало в папку спам, то отправитель ничего знать не будет.
2.4 CNAME records
Don't use CNAMEs in combination with RRs which point to other names like MX, CNAME, PTR and NS. (PTR is an exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME.
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.
У того же спамхауса есть несколько разных RBL с разным уровнем ложных срабатываний:
SBL — сюда заносятся сети используемые спамеров, или сети провайдеров, помогающим спамеров. Например в SBL попадали сети РТКомм и Ди-Нет (msm.ru), когда они размещали в своих сетях сервера спамеров и отказывались прекращать их хостинг. Этот RBL использовать в общем случае не стоит, потому что когда банится целая сетка, велика вероятность что пострадают невиновные клиенты этих ISP.
PBL — сюда тоже попадают целые сетки, но не предназначенные для размещения почтовые серверов — пулы динамических клиентских IP адресов. Несмотря на то, что заносятся целые сетки ложных срабатываний относительно мало. Например вероятность того, что вам нужно будет принять письмо из сетки 59.50.0.0/15 (адреса *.dynamic.163data.com.cn) крайне низка а спама оттуда идет много. Так что PBL вполне можно использовать, возможно не как единственный критерий, а в комплексе с чем то еще.
XBL — в него попадают отдельные IP затрояненных машин. Ложных срабатываний очень мало. Проблемы с использованием XBL я встречал только такого вида — на сервере один и тот же IP используется для почтового сервера и для NAT-а затрояненных виндовых рабочих станций. Т. е. с одной стороны оттуда сыплется спам, с другой стороны с почтового сервера на этом же IP может прийти нужное письмо. Но бывает это редко и в целом я рекомендую XBL для использования.
ZEN — включает в себя XBL, PBL, SBL — не рекомендую использовать по той причине что содержит SBL.
если использовать адекватные RBL и правила для проверки helo то это отсеет примерно то же количество спамботов, что и fake mx, но без негативного эффекта в виде задержки при приеме почты с хороших серверов.
есть домен @foo.ru у которого в spf записи написано что письма из этого домена могут отправляться только с IP 10.10.10.10
пользователь sender@foo.ru отправляет письмо но some@mail.ru
с ящика some@mail.ru стоит редирект на some@firma.ru
почтовый сервер firma.ru видит письмо из домена @foo.ru но не с адреса 10.10.10.10 и не принимает такое письмо.
отправитель получает баунс.
Так что -all в SPF использовать нежелательно.
Писать в mx записи непосредственно IP или CNAME неправильно.
Например так делать нельзя:
example.com. IN MX 10 192.168.1.1
и так тоже не надо:
example.com. IN MX 10 mail
mail IN CNAME superserver
IMHO АЭС может проработать минимум несколько месяцев после исчезновения людей, на автоматике. Пока не сломается какая нибудь часть, которая будет требовать ручной замены.
К тому же не надо забывать на Китай. Их много и плевать они хотели на американские медакорпорации готовые обложить копирайтом все.
Письмо с коммерческим предложением является не спамом если до этого я говорил с менеджером по телефону и просил скинуть его на почту.
И точно такое же письмо является спамом если я его не просил.
1. Мы храним в memcached не готовые страницы (они разные и кэшировать их бессмысленно), а различные данные, которые в маленьких проектах можно на каждый запрос собирать из базы и других источников. Но в больших это становится накладно.
Разумеется нужно помнить об инвалиданции (или обновлении) кэша при изменении данных, поэтому для ненагруженных проектов это только лишнее усложнение кода.
2. В memcached хранятся данные которые вообще никогда не пишутся на диск (в базу), например число неудачных попыток ввести пароль для замедления подбора паролей. С учётом того, что некоторые пытаются подбирать пароли со скорость 100 (и больше) запросов в секунду, на sql это создаёт заметную нагрузку. А после перезагрузки мемкешеда подибральщик все равно снова упрётся в лимит и в потере этих счётчиков при перезагрузке memcached ничего страшного нет. Если поискать то в больших проектах таких данных (которые не иногда жалко терять) набирается достаточно, чтобы намmemcached сэкономить несколько SQL-серверов.
И не только для кэширования, но и как хранилище данных, которые не жалко потерять при перезагрузке.