Всё о о Microsoft Exchange Server и электронной почте.

Предложение для улучшения ForeFront — Динамические белые списки

 

Сегодня Саша Станкевич попросил опубликовать пост для того, чтобы собрать фидбек от российского сообщества о добавлении новых функций в ForeFront или Exchange для борьбы со спамом.  Этот пост разметили еще Олег и Илья. Надеюсь что в комментариях мы соберем много отзывов, они будут отправлены в Микрософт разработчикам и нас услышат. Пока речь идет о добавлении функции грейлист в продукты Микрософт и динамических белых списков о которых Саша написал ниже. 

Сашин пост без изменений:

Как-то давно я предложил одну идею, направленную на борьбу со Spam’ом. Я рассказал о ней Паше Нагаеву, Олегу Крылову и другим ребятам, занимающимся системами обмена сообщений. Они выслушали меня, подискутировали, согласились, что идея имеет рационально зерно и… И на этом, можно сказать, всё и остановилось 🙂 .

Но меня, всё время, никак не оставляло то, что идея не имеет практической реализации. На TechEd 2008 в Барселоне я познакомился (а точнее меня познакомил Паша Нагаев) с Александром Николаевым. Александр уже давно живёт в Америке и является Product Manager’ом ForeFront’а. Так вот, как это обычно и бывает, я хотел связаться с Александром, дабы обсудить с ним мою идею, но всё время откладывал это в долгий ящик. Но случилось неожиданное – Александр посетил наши IT-посиделки и это дало мне тот самый толчок, которого мне так не хватало! Мало того – в кои-то веки я лично пишу об этом в блоге, хоть и не своём 🙂 .

Ну что ж, достаточно интриги и буду ближе к делу. Моя идея состоит в формировании белых списков, но вся прелесть в том, что эти списки динамические! В общих чертах, как я предлагаю этого достичь:

1. Например, в Outlook’е пользователь добавляет в список надёжных отправителей домен «microsoft.com»:

clip_image002

 

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 и буду рассылать спам. Эта технология не поможет.

В каждой технологии есть плюсы и минусы, но Микрософту эту мысль “скормить” нужно, т.к. она действительно может быть полезна или они воспользуются ей, как частью какой-то антиспам технологии.

Саше по любому спасибо за пост.

Похожие посты:

  • Михаил

    грейлистинг давай )

  • Stanky

    Паша, ты невнимательный читатель 😉 ! Там же чёрным по белому написано, что все обновления записей обрабатываются согласно логики работы DNS’а.

    Про эффективность распознования спама я вообще ни чего не говорил 😉 .

    Паша, и опять ты невнимательный читатель! То что у тебя есть SPF — не означает, что я тебе доверяю 😉 . Я не указывал твой домен spamsender.ru в качестве доверенного!

  • http://www.exchangerus.ru Pavel Nagaev

    Саш, тогда нужно более подробно расписывать шаги.

    «все обновления записей обрабатываются согласно логики работы DNS’а.» что это значит?

    Ты можешь расписать по более детальным шагам, как это будет работать?

    1. Пользователь добавил домен microsoft.com в белый список или отправляет письмо в microsoft.com. Эти действия говорят о том, что microsoft.com доверенный домен, мы с ним работаем и с него спама быть не может. Все письма должны быть пропущены.

    2. Exchange при отправке письма на microsoft.com получает в DNS  SPF запись с IP адресами доверенных серверов microsoft и добавляет эти IP адреса  в белый список, устанавливая им время жизни.

    3. Время от времени запускается процедура по обслуживанию этих списков удаляющая истекшие IP адреса.

    Теперь при приеме любого сообщения из Интернет Exchange должен проверить IP адрес SMTP сервера и сравнить со своим списком. Если адрес там есть, то пропускать минуя все фильтры по борьбе со спамом.

    Так?

  • Stanky

    Так, за исключнием второго пункта — уж если на то пошло, то запрос SPF’а должен происходить при получении письма, а не при его отправке 😉 . Но на само деле, совершенно не обязательно ждать SMTP-событий. Список можно сразу наполнить при добавлении домена в доверенные.
    А вообще, я пытался описать именно идею механизма без влезания в детали 😉 .

  • Stanislav Buldakov

    на самом деле, фильтр действующий по этому принципу есть в составе ORF. называется Auto Sender Whitelist. работает по следующему принципу — складывает в базу все адреса, на которые пользователь писал письма, и принимает от этих адресов без ограничений в течение срока жизни записи в базе. говорят, штука хорошая, но сам я её не использовал.

  • Stanky

    Во-первых — принцип совершенно иной 😉 .
    Во-вторых — речь о реализации в ForeFront’е 😉 .

  • Stanislav Buldakov

    чем же иной? с помощью пользователей создаём временный список белых пользователей (или mx-серверов). то что в forefront это не реализовано — так там много чего не реализовано =)

  • Stanislav Buldakov

    да, и то что реализовано в ORF — самый простой способ добиться заполнения белого списка. я, как системный администратор, считаю бесперспективным заполнение списка вручную. пользователь, если на него взвалить эту обязанность, так же вряд ли будет этим доволен.

  • Stanky

    Согласен, да и Олег об этом говорил. Но тут есть другой момент — где гарантия, что ваш пользователь не ответит на письмо спамера 😉 ? Или, что адрес отправителя не будет подделан?

  • Stanislav Buldakov

    никакой спам-фильтр не гарантирует 100% вероятность верного срабатывания. на поей памяти я не припомню ни одного случая. чтобы пользователь решил попереписыцваться со спамерами. кроме этого, список то динамический. то есть запись исчезнет через некоторое время из базы если не писать на него новые письма.

  • Stanislav Buldakov

    в любом случае, это всё технические тонкости. я за появление подобного фильтра в форфронте =)

  • Oleg Krylov

    В трех блогах параллельно 🙂 Итак, мои мысли по этому вопросу.
    Что является конечной целью Microsoft вне зависимости от маркетинговых позиций? Как производитель ПО, МС преследует одну четкую цель — увеличение объема продаж. Да, мы можем сколь угодно долго обсуждать православность тех или иных методов борьбы со спамом, но в конечном итоге конечный пользователь голосует рублем.
    Лично я считаю, что коли уж МС выпускает один продукт для всех, в него можно включить различные модули. В том числе и GrayList, и Сашину фичу в качестве одного из механизмов работы. При всем при этом, Forefront из коробки должен быть рассчитан на небольшую компанию с приходящим, малограмотным админом. Т.к. большие компании имеют в штате хороших спецов или приглашают СИ, они могут себе позволить сколь угодно широкий спектр кастомизации, отключение\включение и настройка модулей — их удел. Из коробки должны работать модули обеспечивающие наибольший процент фильтрации. Админ маленькой организации должен его ставить по принципу: «Setup ->I Agree ->Next ->Next… ->Finish». Посему можно провести исследование о полезности тех или иных фич в продуктах конкурентов, запросить фидбек от пользователей, которые не стесняясь будут ссылаться на тот же ORF, GFI, Symantec не вдаваясь в подробности. Типа: «Мне нравится Auto WhiteList в ORF». И все. А потом реализовать подобие этих функций в качестве модулей.
    «Привет. Меня зовут Иван-Мега-Кул-Админ. У меня конторка на 50 тел, скорость доставки почты для меня не business-critical, и мне всегда нравился GrayList в ORF. Хочу включить GrayList и выключить SPF-фильтрацию.» — Ради Бога! Вот тогда объем продаж возможно возрастет за счет сегмента SMB.
    Но я не призываю пихать туда все подряд, типа Sender Callback Verification, против которой я всеми частями тела. Просто это мое такое мнение 🙂 Может и неправильное.

  • http://www.exchangerus.ru Pavel Nagaev

    И так, выводы. Было бы хорошо, если бы Микрософт реализовала у себя два механизма

    Auto Sender Whitelist и  Greylist. Как это будет технически решат их инженеры,  нам лишь нужны эти функции. Оки? Что-нибудь еще?

  • Artem Gusev [Guard]

    По существу вопроса — полностью согласен с резюме Павла.
    Только вот прислушается ли к этому мнению MS?

  • Artem Gusev [Guard]

    Кстати, а есть ли в функционале Forefront (Exchange Hosted Services)  возможность глобального рапорта о спаме/не спаме, по аналогии с сервисом Symantec Premium Antispam?

  • http://www.exchangerus.ru Pavel Nagaev

    Артем, опишите, пожалуйста,  подробнее, какая информация должна быть в этом отчете?

  • Artem Gusev [Guard]

    Собственно, в SPA это выглядит так — о спаме можно сообщить отправив сообщение из почтовой системы на адрес « ‘MSsubmit@submit-3.brightmail.com'» с темой «Symantec submission».
    Нежелательное почтовое сообщение должно быть прикреплено к данному сообщению в виде вложения….

  • Artem Gusev [Guard]

    Собственно, в SPA это выглядит так — о спаме можно сообщить отправив сообщение из почтовой системы на адрес «

    Normal
    0

    false
    false
    false

    MicrosoftInternetExplorer4

    /* Font Definitions */
    @font-face
    {font-family:Tahoma;
    panose-1:2 11 6 4 3 5 4 4 2 4;
    mso-font-alt:» MS Sans Serif»;
    mso-font-charset:204;
    mso-generic-font-family:swiss;
    mso-font-pitch:variable;
    mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
    /* Style Definitions */
    p.MsoNormal, li.MsoNormal, div.MsoNormal
    {mso-style-parent:»»;
    margin:0in;
    margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:12.0pt;
    font-family:»Times New Roman»;
    mso-fareast-font-family:»Times New Roman»;}
    span.EmailStyle15
    {mso-style-type:personal;
    mso-style-noshow:yes;
    mso-ansi-font-size:10.0pt;
    mso-bidi-font-size:10.0pt;
    font-family:Arial;
    mso-ascii-font-family:Arial;
    mso-hansi-font-family:Arial;
    mso-bidi-font-family:Arial;
    color:navy;}
    @page Section1
    {size:8.5in 11.0in;
    margin:56.7pt 42.5pt 56.7pt 85.05pt;
    mso-header-margin:.5in;
    mso-footer-margin:.5in;
    mso-paper-source:0;}
    div.Section1
    {page:Section1;}
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:»Обычная таблица»;
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-parent:»»;
    mso-padding-alt:0in 5.4pt 0in 5.4pt;
    mso-para-margin:0in;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:10.0pt;
    font-family:»Times New Roman»;
    mso-ansi-language:#0400;
    mso-fareast-language:#0400;
    mso-bidi-language:#0400;}
    ‘MSsubmit@submit-3.brightmail.com'» с темой «Symantec submission». Нежелательное почтовое сообщение должно быть прикреплено к данному сообщению в виде вложения….

  • Oleg Krylov

    В Exchange Hosted Services эта фича точно есть, обсуждалось. А вот про возможность глобального репорта в Symantec, недавно спрашивал Илья Сазонов (sie). Так что РЕСПЕКТИЩЕ, Артём 🙂

  • http://www.exchangerus.ru Pavel Nagaev

    Auto Sender Whitelist
    Greylist
    Глобальный репорт от пользователей о спаме

  • Ugolkov Andrey

    На сайте ORF есть замечательный раздел в саппорте, называется Feature Requests: http://www.vamsoft.com/features/default.asp
    Там помимо кучи предложений по чисто внутренним доработкам ORF есть очень интересные предложения, как например,  развитие Auto Sender Whitelist — End-User Whitelist/Blacklist или очевидная идея которой пока вообще вроде ни у кого нет — Validate Sender Address using Recipient Validation. В том числе я там как-то натолкнулся на идею напоминающую обсуждаемую тут от Александра, но сейчас ее из списка убрали, видимо посчитав реализованной именно Auto Sender’ом. И все эти идеи и их обсуждение в полной доступности на сайте.

  • http://www.exchangerus.ru Pavel Nagaev

    Validate Sender Address using Recipient Validation очень плохая идея, т.к. в случае грейлиста, RBL  и некоторых других, отправитель не может быть проверен. Я уже писал где-то об этом.

  • Ugolkov Andrey

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

  • http://www.exchangerus.ru Pavel Nagaev