Правила и исключения

- Никогда не фильтруйте сообщения, являющиеся ответами на ваши письма.
- Используйте несколько адресов. В идеале для каждой новой подписки следует создавать новый адрес — если он вдруг попадет в спамерские базы, сменить его будет нетрудно.
- Избегайте отправки запросов в ответ на письма из дискуссионных списков (почтовых конференций).
- Никогда не отправляйте запросы в ответ на запрос другой C/R-системы или сообщение сервера об ошибке доставки.
- Корректно обрабатывайте отправку множества сообщений (если с одного адреса за короткий промежуток времени пришло несколько писем, в ответ нужно отправить только один запрос).
- Отслеживайте возникновение порочных кругов.
- При отправке запроса используйте в качестве обратного адреса тот, на который пришло исходное письмо. (Важно в случае использования многих защищенных адресов.)
- Регулярно просматривайте заголовки заблокированной почты.
- Старайтесь делать так, чтобы реагировать на запрос было как можно проще (в том числе для людей с ослабленным зрением и другими ограничениями).
- Избегайте отправки запросов в ответ на письма с вирусами.
- Комбинируйте C/R с другими антиспам-системами.
- Не заставляйте отправителя посылать письма повторно.

Большинство этих (и других, не перечисленных здесь) требований продиктованы элементарной логикой и пониманием принципов работы электронной почты, однако нечасто удается встретить C/R-программу, удовлетворяющую хотя бы самым главным из них. В то же время это не значит, что написать правильную систему такого рода невозможно: никаких принципиальных технических препятствий здесь нет. Гораздо труднее убедить пользователя правильно с нею обращаться.

Светлое будущее нам не светит?

Приведу один пример: с самого начала использования C/R стало ясно, что ответы на письма нужно пропускать без дополнительных запросов. Простейшее решение — в качестве обратного использовать специальный адрес (приватный), на котором отключить всю фильтрацию. Мне казалось это очевидным, но, участвуя в обсуждениях C/R, я заметил, что даже мысль об использовании двух разных адресов порой вгоняет пользователей в ступор. Что уж говорить обо всех остальных тонкостях?

И вот что мы имеем в итоге: действия не вполне технически грамотных пользователей и программистов дискредитируют идею, из-за чего в ближайшем будущем использование даже идеально настроенных C/R-разработок может восприниматься как «превышение допустимой самообороны» и нарушение сетевого этикета. И это весьма печально — поскольку сейчас C/R действительно позволяет полностью избавиться от спама, не теряя нужной почты и не нарушая принципов свободы обмена информацией.

Я вижу лишь один правдоподобный сценарий: на рынок антиспам-решений должен прийти сильный и грамотный разработчик, способный не только создать C/R-систему, лишенную распространенных недостатков, но и раскрутить ее до уровня стандарта де-факто³. Если таким или каким-то другим путем появится стандарт на C/R, это позволит значительно снизить количество плохих разработок и приучит пользователя к корректному восприятию и работе с такими средствами защиты от спама.

Впрочем, стоит ли вообще держаться за идею C/R, раз уж с ней столько трудностей? Может ли эта технология, при правильном использовании, окончательно решить Великую Проблему?

Сейчас трудно сказать, что предпримут спамеры в случае широкого распространения подобных систем, но никаких обоснованных опасений по этому поводу мне не встречалось. Единственный способ обхода, известный на данный момент, — ручная обработка запросов, — помимо прямых затрат потребует также организации безопасного и анонимного канала обратной связи (сейчас спамерские письма отправляются с несуществующих адресов, и на это есть свои причины), что в совокупности приведет к существенному удорожанию рассылок и выведению спама за грань рентабельности. Другая возможная уязвимость — использование вирусов и прочих методов внедрения на компьютеры пользователей и серверы почтовых служб для сбора приватных адресов, если практика их использования будет распространенной. Она тоже не кажется слишком опасной — все-таки трудно представить себе постановку таких процессов «на поток», в отличие от сбора адресов с веб-страниц.

Конечно, за отсутствие других, более действенных способов атаки на C/R, никто поручиться не может. Но не стоит забывать, что стойкость современных криптографических алгоритмов — тоже недоказанный факт, однако это не мешает их использовать во многих критичных областях: просто альтернативы нет. И может статься, что с Challenge-Response мы окажемся в этой же ситуации отсутствия альтернатив.

2 За исключением разве что проблемы с подстановкой реального адреса в качестве обратного при рассылке спама. Впрочем, этот недостаток относится не только к C/R, но и к любым другим фильтрам — они обязаны высылать уведомления о том, что письмо было принято за спам, что не слишком отличается от запросов.
3 Возможно, именно на это намекал Гейтс, выступая в Давосе?