Filters that Fight Back

August 2003

Август 2003

We may be able to improve the accuracy of Bayesian spam filters
by having them follow links to see what's
waiting at the other end. Richard Jowsey of
death2spam now does
this in borderline cases, and reports that it works well.

Возможно, нам удастся повысить точность байесовских спам-фильтров, заставив их переходить по ссылкам, чтобы увидеть, что находится на другом конце. Ричард Джоуси из death2spam теперь делает это в спорных случаях и сообщает, что это работает хорошо.

Why only do it in borderline cases? And why only do it once?

Почему делать это только в спорных случаях? И почему только один раз?

As I mentioned in Will Filters Kill Spam?,
following all the urls in
a spam would have an amusing side-effect. If popular email clients
did this in order to filter spam, the spammer's servers
would take a serious pounding. The more I think about this,
the better an idea it seems. This isn't just amusing; it
would be hard to imagine a more perfectly targeted counterattack
on spammers.

Как я упоминал в Will Filters Kill Spam?, переход по всем url в спаме имел бы забавный побочный эффект. Если бы популярные почтовые клиенты делали это ради фильтрации спама, серверы спамера получали бы серьёзную трёпку. Чем больше я об этом думаю, тем лучше эта идея кажется. Это не просто забавно; трудно представить более точно нацеленную контратаку на спамеров.

So I'd like to suggest an additional feature to those
working on spam filters: a "punish" mode which,
if turned on, would spider every url
in a suspected spam n times, where n could be set by the user. [1]

Поэтому я хотел бы предложить тем, кто работает над спам-фильтрами, дополнительную возможность: режим «наказания», который, если включён, обходил бы каждый url в подозреваемом спаме n раз, где n мог бы задаваться пользователем. [1]

As many people have noted, one of the problems with the
current email system is that it's too passive. It does
whatever you tell it. So far all the suggestions for fixing
the problem seem to involve new protocols. This one
wouldn't.

Как отмечали многие, одна из проблем нынешней системы электронной почты в том, что она слишком пассивна. Она делает всё, что ей велят. Пока что все предложения по решению проблемы, похоже, подразумевают новые протоколы. Это — нет.

If widely used, auto-retrieving spam filters would make
the email system rebound. The huge volume of the
spam, which has so far worked in the spammer's favor,
would now work against him, like a branch snapping back in
his face. Auto-retrieving spam filters would drive the
spammer's
costs up,
and his sales down: his bandwidth usage
would go through the roof, and his servers would grind to a
halt under the load, which would make them unavailable
to the people who would have responded to the spam.

При широком использовании автоматически подгружающие спам-фильтры заставили бы почтовую систему отскакивать. Огромный объём спама, который до сих пор работал в пользу спамера, теперь работал бы против него — как ветка, хлестнувшая его по лицу. Автоматически подгружающие спам-фильтры подняли бы расходы спамера и обрушили его продажи: его потребление трафика взлетело бы до небес, а серверы остановились бы под нагрузкой, из-за чего стали бы недоступны для тех, кто откликнулся бы на спам.

Pump out a million emails an hour, get a
million hits an hour on your servers.

Рассылаешь миллион писем в час — получаешь миллион обращений в час на свои серверы.

We would want to ensure that this is only done to
suspected spams. As a rule, any url sent to millions of
people is likely to be a spam url, so submitting every http
request in every email would work fine nearly all the time.
But there are a few cases where this isn't true: the urls
at the bottom of mails sent from free email services like
Yahoo Mail and Hotmail, for example.

Нам нужно было бы гарантировать, что это делается только с подозреваемыми спамами. Как правило, любой url, разосланный миллионам людей, скорее всего является спам-url, поэтому отправка каждого http-запроса в каждом письме работала бы прекрасно почти всегда. Но есть несколько случаев, когда это не так: например, url внизу писем, отправленных бесплатными почтовыми сервисами вроде Yahoo Mail и Hotmail.

To protect such sites, and to prevent abuse, auto-retrieval
should be combined with blacklists of spamvertised sites.
Only sites on a blacklist would get crawled, and
sites would be blacklisted
only after being inspected by humans. The lifetime of a spam
must be several hours at least, so
it should be easy to update such a list in time to
interfere with a spam promoting a new site. [2]

Чтобы защитить такие сайты и предотвратить злоупотребления, авто-подгрузку следует сочетать с чёрными списками сайтов, рекламируемых в спаме. Обходились бы только сайты из чёрного списка, а сайты попадали бы в чёрный список лишь после проверки людьми. Срок жизни спама — как минимум несколько часов, поэтому такой список должно быть легко обновить вовремя, чтобы помешать спаму, продвигающему новый сайт. [2]

High-volume auto-retrieval would only be practical for users
on high-bandwidth
connections, but there are enough of those to cause spammers
serious trouble. Indeed, this solution neatly
mirrors the problem. The problem with spam is that in
order to reach a few gullible people the spammer sends
mail to everyone. The non-gullible recipients
are merely collateral damage. But the non-gullible majority
won't stop getting spam until they can stop (or threaten to
stop) the gullible
from responding to it. Auto-retrieving spam filters offer
them a way to do this.

Высокообъёмная авто-подгрузка была бы практична только для пользователей с высокоскоростными соединениями, но таких достаточно, чтобы создать спамерам серьёзные неприятности. Более того, это решение аккуратно зеркалит проблему. Проблема со спамом в том, что ради нескольких доверчивых людей спамер шлёт письма всем. Недоверчивые получатели — лишь сопутствующий ущерб. Но недоверчивое большинство не перестанет получать спам, пока не сможет остановить (или пригрозить остановить) отклик доверчивых на него. Автоматически подгружающие спам-фильтры дают им такую возможность.

Would that kill spam? Not quite. The biggest spammers
could probably protect their servers against auto-retrieving
filters. However, the easiest and cheapest way for them
to do it would be to include working unsubscribe links in
their mails. And this would be a necessity for smaller fry,
and for "legitimate" sites that hired spammers to promote
them. So if auto-retrieving filters became widespread,
they'd become auto-unsubscribing filters.

Убило бы это спам? Не совсем. Крупнейшие спамеры, вероятно, смогли бы защитить свои серверы от авто-подгружающих фильтров. Однако самым простым и дешёвым способом сделать это было бы включить в письма работающие ссылки отписки. А для мелкой рыбёшки и для «легитимных» сайтов, нанявших спамеров для продвижения, это стало бы необходимостью. Так что если бы авто-подгружающие фильтры получили распространение, они превратились бы в авто-отписывающие фильтры.

In this scenario, spam would, like OS crashes, viruses, and
popups, become one of those plagues that only afflict people
who don't bother to use the right software.

В этом сценарии спам, подобно сбоям ОС, вирусам и всплывающим окнам, стал бы одной из тех напастей, что поражают лишь тех, кто не удосуживается использовать правильное ПО.

Notes

Примечания

[1] Auto-retrieving filters will have to follow redirects,
and should in some cases (e.g. a page that just says
"click here") follow more than one level of links.
Make sure too that
the http requests are indistinguishable from those of
popular Web browsers, including the order and referrer.

[1] Авто-подгружающие фильтры должны будут следовать за редиректами, а в некоторых случаях (например, страница, которая просто говорит «нажмите здесь») следовать более чем по одному уровню ссылок. Убедитесь также, что http-запросы неотличимы от запросов популярных веб-браузеров, включая порядок и referrer.

If the response
doesn't come back within x amount of time, default to
some fairly high spam probability.

Если ответ не приходит в течение x времени, по умолчанию присваивайте довольно высокую вероятность спама.

Instead of making n constant, it might be a good idea to
make it a function of the number of spams that have been
seen mentioning the site. This would add a further level of
protection against abuse and accidents.

Вместо того чтобы делать n постоянным, возможно, было бы хорошей идеей сделать его функцией от числа спамов, в которых упоминался этот сайт. Это добавило бы ещё один уровень защиты от злоупотреблений и случайностей.

[2] The original version of this article used the term
"whitelist" instead of "blacklist". Though they were
to work like blacklists, I preferred to call them whitelists
because it might make them less vulnerable to legal attack.
This just seems to have confused readers, though.

[2] В исходной версии этой статьи использовался термин «белый список» вместо «чёрный список». Хотя они должны были работать как чёрные списки, я предпочёл называть их белыми списками, потому что это могло сделать их менее уязвимыми для юридических атак. Однако это, похоже, лишь запутало читателей.

There should probably be multiple blacklists. A single point
of failure would be vulnerable both to attack and abuse.

Вероятно, должно быть несколько чёрных списков. Единая точка отказа была бы уязвима как для атаки, так и для злоупотребления.

Thanks to Brian Burton, Bill Yerazunis, Dan Giffin,
Eric Raymond, and Richard Jowsey for reading drafts of this.

Благодарности Брайану Бёртону, Биллу Еразунису, Дэну Гиффину, Эрику Рэймонду и Ричарду Джоуси за прочтение черновиков.