Главная Exchange/UC, Storages Динамические белые списки
  • Динамические белые списки

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

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

    white_list_1

    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’а 🙂 .

    Александр Станкевич

Комментарии

  1. Может я невнимательно прочитал, но что будет если у данного домена нет SPF?

  2. Илья, разумеется, что ничего не будет 🙂 ! Поэтому, я и упомянул, что это будет ещё одним стимулом для их использования 😉 …

  3. Т.е если SPF есть, почта принимается в любом случае,т.к IP серверов данного домена в динамическом белом списке. Если SPF нет, добро пожаловать по всем остальным антиспам-фильтрам?

  4. Если SPF есть и мы указали, что этому домену доверяем, то только с тех серворов, которые указаны в SFP-записи домена мы гарантированно принимаем почту.
    Если SPF’а нет, то будут применяться остальные технологии…

  5. Главный профит какой?? Ускорение получения почты от доменов партнеров компании, с которых большой поток входящей почты и точто есть SPF.

  6. Илья, я же на Русском, вроде, писал 😉 . Там целых три пункта. Ну первые два пусть будут главными.
    Не обязательно партнёров – это может быть и Mail.ru с которого у нас так любят отправлять почту. В общем, не любой партнёр может настроить на своей стороне исходящий коннектор, чтоб почта не попадала под спам-фильтры 😉 .

  7. Ой прости, я просто курс читаю и одним глазом по диагонали прочитал)

    Я думаю технология если не “must be”, то “usefull” однозначно.

  8. а кто будет заниматься первоначальным составлением белого списка? пользователь? как с его аутлука информация о белых отправителях попадёт в спам-фильтр?

    какбэ не описан механизм плавного перехода от пункта 1 к пункту 2.

  9. Станислав, ну это имхо не важно, может забить пользователь, может админ в своем ящике. Тут даже совместно лучше. Более полный список реально нужных доменов будет. Каждый забил свои, получили полную картинку.

    Тут другая проблема появляется, один человек забивший домен, сразу делает его легитимным для всех.

    А вопрос технической реализации мне кажется вообще не проблема.

  10. Во-первых – я описал лишь саму идею механизма, а не все его шестерёнки 😉 .
    Во-вторых – пример с Outlook’ом – всего лишь пример. Первоначально это задача администратора.
    В-третьих – это всего лишь скелет, а мясо на него нарастить можно как угодно. Например, вплоть до сервисов, сообщающих репутацию не IP-адресов, а доменных имён 😉 .

  11. Идея нерабочая с:

    1. Технологической
    2. Организационной

    сторон.

    Но прикольная.

  12. >Идея нерабочая

    Не факт.

  13. Осталось дело за малым. научить админов добавлять SPF записи. А по хорошему ещ и A/MX/PTR/HELO.. Да что б по RFC!

  14. Денис, а вот тут как раз и задача решения для почтарей тех админов у кого руки из правильного места дать зеленый свет. Ну естественно не для всех, а только тех которые интересны нам.

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

  16. > Не факт.

    Хорошо. Не факт. А почему ты пишешь не зелёным?

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

  18. > на самом деле, фильтр действующий по этому принципу есть в составе ORF.
    >
    Во-первых – принцип совершенно иной 😉 .
    Во-вторых – речь о реализации в ForeFront’е 😉 .

  19. Предлагаю переместиться в блог Паши Нагаева. Я там отписал ответ. Прыгать по трём блогам в поисках ответа мало улыбает =)

  20. Да смысла нет куда то скакать, идея понятна. А реализацию на блогах понта обсуждать нет.

  21. Илья, во-первых – как я написал, нужен именно Feedback по необходимости данного функционала.
    Во-вторых – как показывает практика, суть идеи понятна единицам 🙁 !

  22. Мне кажется Feedback можно оставлять после проверки технологии. А так ее целесообразность должна обсуждаться разработчиками и архитекторами Exchange, ибо у остальных явно не хватит компетенции судить и подобном.

  23. >Я там отписал ответ.
    Можно, во-первых, привести ссылку, а во-вторых ИМХО странная позиция: “люди переходите за моим ответом, а то мне лениво” 😉

  24. Илья, в том-то и дело – Александр Николаев сказал, что без Feedback’а Community о полезности и потенциальном использовании функции он не сможет принять решение о её реализации.

  25. Нормальный (читай – обычный) пользователь ничего добавлять не будет. И это правильно – не их это работа.
    Лучше сделать галочку – если сервер попадает в SPF – пропустить письмо без проверки (или уменьшить спам-вес письма)

  26. Иван, а комп он включать будет? Или это тоже не его работа?

  27. И что ж вы все прицепились к этим несчастным пользователям 😉 ?
    А если пропускать все письма доменов, имеющих SPF-запись – это не защита 😉 !

  28. Иван, ит-отдел должен взаимодействовать с сотрудниками компании, а не жить котом в черном мешке. Уметь грамотно выражаться и четко пятью словами объяснить, что потратив 5 минут на добавление нужных ему и используемых доменов (или адресов) в белый список, он впоследствии сэкономит в сотни раз больше времени и сможет раньше валить с работы.

  29. Илья, я ещё могу согласиться, что производить сию операцию пользователями – немного лишнее. Но я совершенно не согласен, что почтовый администратор вообще не должен участвовать в жизни прохождения почты! Во всяком случае, пока не вымерли криворукие админы…

  30. А кто об этом говорит? Ну просто ИМХО указание доменов или адресов должно ложиться на пользователей, ты предлагаешь мониторить админу популярные домены и самому добавлять?

  31. Ну, мониторить не мониторить, но по мере надобности добавлять домены в доверенные.
    Первоначальный же список доверенных можно составить при поддерже тех же пользователей (путём опроса) или ещё лучше – при поддержке руководства.

  32. Да, вариантов попадания и составления такого первоначального списка может быть несколько.

  33. В трех блогах параллельно Итак, мои мысли по этому вопросу.
    Что является конечной целью 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, против которой я всеми частями тела. Просто это мое такое мнение Может и неправильное.

  34. SPF – нормальная технология, но к сожалению мёртвая. Многие крупные конторы ее принципиально игнорируют. Например, писал я как то в Softline. Ребята, поставте SPF, вы постоянно в СПАМ попадаете. На что был ответ, SPF ставить не будем, у нас не централизованная система рассылки сообщений. И именно это главная палка в колёсах SPF. В конторах с кучей распределённых офисов, многие из которых не имеют даже статического IP, накладно организовывать централизованную почтовую систему. Гораздо проще слать откуда попало и не парится с ограниченным разрешением Relay на центральном MTA. Хотя, при желании, можно автоматизировать идентификацию своих на центральном MTA, но видимо этого желания у многих нет. Про OWA в мелких офисах умалчиваю, потому что он бесполезен, когда есть роботы рассылающие клиентам различные уведомления и предложения.