Сегодня получил жалобу на то, что моя почтовая система перестала принимать письма от одного из постоянных отправителей. Дословно было примерно так:
«Ваша система не принимает почту от нашего сервера с 19 марта 2015, мы ничего не меняли и все у нас с почтовым сервером хорошо.«
Такие письма — обычное дело, скорее всего IP адрес отправителя попал в DNSBL или цисковский SenderBase.com, но именно с таким случаем я раньше не сталкивался. Продолжить чтение
У моей жены есть блог, где она время от времени пишет свои мысли. Блог расположен на VDS, работает на WordPress и имеет свой собственный домен. На всякий случай, все письма на админа домена форвардятся провайдером на мой основной адрес. Уж не знаю, зачем это нужно, мало ли кому захочется связаться с автором блога.
Так вот, в один прекрасный день, я смотрю, у меня в Junk примерно 300 сообщений. Выглядят они вот так.
Уж какой в этом сакральный смысл я не знаю, одно или два сообщения содержали опасные аттачи и были вырезаны антивирусом. Тело текста plain. Рассылка похоже шла из вирусной сети, все хосты разные. На рабочий емейл такое не прошло бы, т.к. у отправляющих хостов нет реверсной записи и скорее всего они в DNS Black lists, но поскольку шло через провайдера, то принималось все.
Пост написан для того, чтобы показать какой еще бывает спам 🙂 Если у Вас есть мысл зачем рассылают подобный спам или Вы получали такой спам, напишите плиз.
Вчера всплыла еще раз проблема, связанная с функцией Junk E-mail в Outlook. Один из моих пользователей пожаловался на то, что письма от некоей компании стали попадать в папку Junk e-mail. С одной стороны это не проблема, нужно добавить отправителя в белый список в Outlook и всё. С другой стороны многие пользователи даже не подозревают о существовании Junk e-mail. Блокируемые письма содержат брони авиабилетов и из-за «пропущенного» письма может сорваться командировка. Согласитесь, так быть не должно и в этой ситуации решение должен принимать администратор.
Как обычно перед нами встает вопрос:«А что же делать? Как лучше поступить?»
Существует ряд решений этой проблемы:
Вот об этом третьем способе я и хочу поговорить. В принципе задача сводится к следующему:«Нужно каким-то образом помечать сообщения, чтобы спам фильтр в Outlook их не помещал в Junk e-mail»
Как-то очень давно я читал статью , где четко сказано, что спам фильтры Exchange и Outlook ни как не связаны, это два разных фильтра, с разной логикой и разными обновлениями. Если у кого есть хорошие пруфлинки на эту тему, дайте, плиз, почитать. У Outlook можно добавить отправителя в белый список, вот вроде бы и все настройки.
Но с выходом Forefront Protection 2010 появилась следующая проблема, помечаемые спам сообщения не попадали в Junk-email в Outlook. Выяснилось, что проблема в поле
X-MS-Exchange-Organization-SCL: -1
То есть FPE2010, в случае всевозможных белых списков, устанавливает значение в -1 и Outlook не помещает такие сообщения в Junk e-mail. И нашел я замечательные слова: «Reserved by Microsoft® Exchange Server 2003 for messages submitted internally. A value of -1 should not be overwritten because it is this value that is used to eliminate false positives for internally-submitted e-mail»
а потом еще и такие, посвежее:
«FPE marks messages that it believes to be legitimate with an SCL rating of -1. As a result, on Exchange Server 2007, the end user blocked senders feature may not be enforced for these messages. If this occurs, as a workaround, you can set the extended option CFAllowBlockedSenders to ‘true’. This changes the SCL rating from -1 to 0 and allows Exchange Server 2007 to enforce the end user blocked senders feature»
Это как раз решение для моего случая. Мне нужно создать транспортное правило, которое будет в зависимости от условий — совпадение подстроки в адресе отправителя или по подстроке в теме сообщения менять SCL сообщения на -1 и оно никогда не попадет в Junk e-mail.
Например, если Олег Крылов пришлет мне письмо, с темой письма: «Galka needed!», то оно попадет ко мне сразу в Inbox и я не пропущу его в Junk e-mail.
Ну вот, но одну проблему стало меньше 🙂
Всем хороших выходных.
Вот такой вот неожиданный заголовок для поста сегодня. Дело в том, что мы всегда говорим о том, как уберечься от попадания в списки спамеров. Мне же как раз нужно наоборот, попасть в список спамеров для тестирования эффективности антиспам систем. Загонять существующий трафик через них я не хочу. Поэтому у меня есть свободный домен и адрес st@exchangefaq.ru на который я ХОЧУ ПОЛУЧАТЬ МНОГО СПАМА.
Внимание вопрос, как это сделать? Как скормить спамерам мой адрес? Пока набрал адресов из спам ящика и послал им письмо, а вдруг там коллектор спама. Разместил адрес на странице www.exchangefaq.ru, жду когда поисковики проиндексируют и потом их обработает коллектор спама. Что еще? Куда еще подобавлять адрес?
Спамить по блогам не хочется, нужна помойка, обрабатываемая коллекторами спама.
В общем если у вас есть мысли, как добавить мой адрес st@exchangefaq.ru в спам листы — плиз, напишите как это сделать.
p.s. форвард спама не совсем подходит, нужен спам именно со спам серверов, чтобы тестирование антиспам фильтра было честным.
Сегодня попросил опубликовать пост для того, чтобы собрать фидбек от российского сообщества о добавлении новых функций в 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 и буду рассылать спам. Эта технология не поможет.
В каждой технологии есть плюсы и минусы, но Микрософту эту мысль “скормить” нужно, т.к. она действительно может быть полезна или они воспользуются ей, как частью какой-то антиспам технологии.
Саше по любому спасибо за пост.
Вчера произошло неординарное событие. Мы как обычно, в среду, планировали провести встречу и поговорить о RBAC в Microsoft Exchange Server 2010, но тема встречи внезапно изменилась.
Мне были нужны материалы для подготовки к Платформе и я обратился к Александру Николаеву, Product Manager по ForeFront for Exchange. Мы с ним познакомились на TechEd в Барселоне и время от времени обмениваемся новостями. Александр любезно согласился немного рассказать о будущей версии Forefront Protection 2010 for Exchange Server. Поскольку договорились об этом за полтора часа до встречи, то времени на подготовку красивых слайдов не было, но зато была очень интересная беседа. Хочется сделать несколько комментариев, а полную запись встречи Вы можете прослушать ниже по ссылкам.
Итак:
1. в новом Forefront Protection 2010 не будет и Microsoft не смотрит в сторону использования этой технологии в своих продуктов, т.к. нет просьб от ИТ сообщества о необходимости этого функционала. Интересную и очень очевидную мысль сказал Олег Крылов:”Greylist — это технология для малого, ну может среднего бизнеса, но никак не энтерпрайз уровня”. Я призадумался и …, а Олег то прав. Продукты Микрософт рассчитаны на как раз уровень крупного предприятия, поэтому greylist это не решение для энтерпрайза, ведь один из существенных недостатков технологии greylist — длительные временные задержки при доставке сообщений, что недопустимо в большой компании.
2. Микрософт отказывается от технологии SmartScreen и в Forefront Protection 2010 будут использованы технологии по борьбе со спамом от компании CLOUDMARK. Использоваться будут лишь некоторые механизмы, которые Микрософт считает наиболее эффективными.
3. В сентябре Virus Bulletin проводил антиспамовых фильтров. Forefront Protection 2010 for Exchange Server отловил 99.77% спама. Это очень хороший результат, ведь это еще не релиз. Диаграмма сравнения с другими продуктами выглядит так.
4. В Forefront Protection 2010 for Exchange будет применена для борьбы со спамом в NDR. О механизмах работы можно прочитать по . Это очень здорово, т.к. из-за этой проблемы администраторы отключают NDR в своей организации или запрещают прием NDR извне.
5. Forefront Protection 2010 for Exchange Server будет работать и на Microsoft Exchange Server 2007.
6. Движки Sophos, CA, и AhnLab больше использоваться не будут.
На встрече было еще много чего интересного, запись можно прослушать ниже. Я надеюсь, что это была не последняя встреча и Александр нам расскажет более подробно о механизмах работы Forefront Protection 2010 for Exchange Server.
Если у вас есть вопросы по спам технологиям, по Forefront, то оставляйте комментарии к этому посту, пишите мне на pnagaev на Яндексе или напрямую Александру на alexni на exchange.microsoft.com.
Про новый Forefront Protection 2010 for Exchange Server можно прочитать по .
Скачать можно по ссылке [download#42]
Или прослушать в онлайне. [podcast]http://www.exchangerus.ru/Files/audio/IT-Talks-N66_ForeFront2010-ANikolaevMSFT-ExchangeRUS.mp3[/podcast]
Сегодня среда, а значит вечером будет очередная встреча «Разговоры об ИТ» № 64.
К сожалению я на этой неделе был сильно занят, планы были наполеоновские, но времени на подготовку не хватило. Поэтому сегодня будет экспромт.
Несколько последних дней я размышлял на тему выбора дизайна системы электронной почты и обнаружил, что дизайнов может быть превеликое множество, камасутра отдыхает. Очень сильно планы “портит” виртуализация, т.к. закрутить сложность системы можно очень сильно. Главная проблема здесь – выбрать наиболее подходящее решение по стоимости и сложности системы. Зачем, например, делать кластер на 3х пользователей и вообще использовать при этом Exchange.
Поэтому давайте поговорим, именно поговорим, о плюсах и минусах дизайна почтовых систем для предприятия. Я начну рассматривать простые системы, где есть только один компьютер и один пользователь. Что выбрать и зачем. Потом добавим пользователей, добавим требований, разнесем по офисам и будем крутить – вертеть.
Цель этой беседы – собрать побольше материала, т.к. я хочу наделать стандартных шаблонов дизайна Exchange для определенных организаций, описать их плюсы и минусы. Поэтому мне нужно ваше мнение и ваши мысли.
По поводу записи встречи – посмотрим что получится из этого.
Для участия необходимо зайти по ссылке
Вход на «Разговоры об ИТ»
(начнет работать за 30 мин до встречи)
Для участия нужна гарнитура(наушники+микрофон), Интернет и клиент Live Meeting 2007(15Mb). Желательно использовать USB гарнитуру.
p.s. за Интернет я заплатил, тормоза не ожидаются. 🙂 Если у вас есть желание рассказать что-то свое, то я всегда только welcome!
Как-то я уже писал про эту проблему, но сегодня история получила продолжение. Сотрудник нашей компании отправил сообщение на один из серверов и получил сообщение об ошибке. Оно представлено ниже.
From: System Administrator
Sent: Wednesday, December 10, 2008 3:11 PM
To: Berkova, Elena
Subject: Undeliverable: RE:
Your message did not reach some or all of the intended recipients.
Subject: RE:
Sent: 10/12/2008 12:10
The following recipient(s) could not be reached:
iff@onedomain.com on 10/12/2008 15:11
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<myserver.mydomain.ru.ru #5.7.1 smtp;550 5.7.1 <iff@onedomain.com>… Rejecting due to security policy — Unable to validate Sender address <elena.berkova@mydomain.ru>, Please see: http://www.server.ru/policy.html#invalidsender>
Поскольку это мой пользователь и мне нужно “ехать” (помните доклад на Платформе? :-)), то нужно было произвести анализ ситуации и понять что делать. Сразу видно, что сервер получателя пытается проверить адрес отправителя и не может это сделать. Скорее всего используется метод Callback verification, cсылка указанная в сообщении конечно же не работала.
Проблема заключалась в том, что на моем сервере используется два врага этого метода – DNSBL и Greylisting. В обоих случаях соединение получающего сервера отбивается во время проверки отправителя на моем сервере. Что делать? Решения два:
Второе решение более простое. Поскольку я знаю, как работают мои фильтры, то добавить исключение для IP получателя было просто и почта заработала.
Выводы:
p.s. все это ерунда, технологии – это всего лишь инструмент для зарабатывания денег, не этим должен жить человек, не для этого его создавала природа.