Сегодня попросил опубликовать пост для того, чтобы собрать фидбек от российского сообщества о добавлении новых функций в ForeFront или Exchange для борьбы со спамом. Этот пост разметили еще и . Надеюсь что в комментариях мы соберем много отзывов, они будут отправлены в Микрософт разработчикам и нас услышат. Пока речь идет о добавлении функции грейлист в продукты Микрософт и динамических белых списков о которых Саша написал ниже.
Сашин пост без изменений:
Как-то давно я предложил одну идею, направленную на борьбу со Spam’ом. Я рассказал о ней Паше Нагаеву, и другим ребятам, занимающимся системами обмена сообщений. Они выслушали меня, подискутировали, согласились, что идея имеет рационально зерно и… И на этом, можно сказать, всё и остановилось 🙂 .
Но меня, всё время, никак не оставляло то, что идея не имеет практической реализации. На TechEd 2008 в Барселоне я познакомился (а точнее меня познакомил Паша Нагаев) с Александром Николаевым. Александр уже давно живёт в Америке и является Product Manager’ом ForeFront’а. Так вот, как это обычно и бывает, я хотел связаться с Александром, дабы обсудить с ним мою идею, но всё время откладывал это в долгий ящик. Но случилось неожиданное – Александр посетил наши IT-посиделки и это дало мне тот самый толчок, которого мне так не хватало! Мало того – в кои-то веки я лично пишу об этом в блоге, хоть и не своём 🙂 .
Ну что ж, достаточно интриги и буду ближе к делу. Моя идея состоит в формировании белых списков, но вся прелесть в том, что эти списки динамические! В общих чертах, как я предлагаю этого достичь:
1. Например, в Outlook’е пользователь добавляет в список надёжных отправителей домен «microsoft.com»:
2. Принимающий сервер запрашивает SPF-запись данного домена: v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ip4:131.107.115.212 ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64 ip4:205.248.106.30 ip4:205.248.106.32 ~all
3. В белый список заносятся все адреса из данной SPF-записи.
Причём, за сроком жизни данных адресов в белом списке будет отвечать логика DNS’а. То есть, когда срок жизни данной записи истечёт, она будет повторно запрошена, а из белого списка будут удалены или добавлены те адреса, которые были удалены или добавлены в SPF-запись.
Таким образом, мы избавляемся от рутинной работы по слежению за адресами отправляющих серверов тех отправителей, которым мы доверяем – они сами формируют наш белый список!
Выигрыш от данного механизма я вижу в следующем:
1. При использовании GreyListing’а мы можем совместить мощь данной технологии по отшибу Spam’а и убрать её главный минус – задержки в доставке.
2. Какой бы ни была технология определения Spam’а, она никогда не сможет на 100% определить является письмо легитимным или нет. Таким образом, мы можем потерять письмо от доверенного отправителя. Но если сервер такого отправителя будет у нас в белом списке, то такой потери не произойдёт.
3. Ну и наконец, дать ещё больший стимул для использования Sender-ID, то есть тех самых SPF-записей 🙂 .
В общем говоря, я связался с Александром по данному вопросу, вчера мы его обсудили голосом и моя идея ему приглянулась 🙂 . Но дабы сделать решение о её реализации ему необходимо собрать обратную связь от сообщества о её потенциальном применении. С этой целью я и пишу данный (крайне редкий) пост – как вы думаете, на сколько лично вам был бы полезен или даже необходим этот функционал? Если тема вызовет у вас большой интерес, можем более подробно её обсудить на одной из наших встреч «Разговоры об IT» 😉 …
P. S. Так же в разговоре Александр упомянул, что они полностью не отказались от идеи GreyListing’а 🙂 .
Вот что я думаю:
Идея с одной стороны хороша, но она основывается на технологии Sender-ID. Бонус в том, что IP адреса собираются сразу в список, а не обрабатываются динамически. Т.е проверка осуществляется на локальном компьютере, а не запросом в Интернет. Но с этим с этим возникают новые проблемы:
1. Нарушается актуальность списков. SPF может измениться и как это отслеживать?
2. При больших объемах сообщений списки будут очень большими, проверка будет очень долгой и ресурсов будет тратится на это много.
Преимущество от использования будет только в скорости обработки входящих сообщений и уменьшение задержек грейлиста. На эффективности распознавания спама это никак не скажется.
Мне кажется эта технология должна быть частью реализации грейлиста.
Опять же, зарегистрирую я на себя домен spamsender.ru, пропишу SPF и буду рассылать спам. Эта технология не поможет.
В каждой технологии есть плюсы и минусы, но Микрософту эту мысль “скормить” нужно, т.к. она действительно может быть полезна или они воспользуются ей, как частью какой-то антиспам технологии.
Саше по любому спасибо за пост.
Похожие посты:
- Комментарии по вчерашней встрече c Александром Николаевым о Microsoft Forefront Protection 2010 for Exchange Server
- Ориентировочный график выпуска программных продуктов Микрософт на 2007 год
- Поговорим о greylisting?
- TechEd IT Forum 2007. Барселона
- Sender ID и RBL, как базовые средства защиты от спама.