Сегодня получил жалобу на то, что моя почтовая система перестала принимать письма от одного из постоянных отправителей. Дословно было примерно так:
«Ваша система не принимает почту от нашего сервера с 19 марта 2015, мы ничего не меняли и все у нас с почтовым сервером хорошо.«
Такие письма — обычное дело, скорее всего IP адрес отправителя попал в DNSBL или цисковский SenderBase.com, но именно с таким случаем я раньше не сталкивался. Продолжить чтение
На этой встрече я хочу рассказать о подделке отправителя в поле FROM: в сообщениях электронной почты. Обычно администраторы закрывают прием почты из Интернет со своего домена и на этом успокаиваются, но не все так просто. Это решает только половину проблемы, фактически защищен только уровень SMTP сессии, но возможность подделки заголовков внутри письма остается. А ведь именно их видит пользователь и если подделано хорошо, то степень доверия к письму возрастает и пользователь может выполнить просьбу в теле письма, например отправить факс с паролем по указанному номеру.
На нашей встрече я покажу такое поддельное письмо. Вчера, как будто специально, мне прислали письмо с подделанным отправителем, мы рассмотрим заголовки P1 и P2, я покажу, как просто они подделываются и поговорим о защите от этого дела.
А также вы сможете проверить защиту своих почтовых систем, проверим реакцию других сервисов, типа Outlook.com, gmail.com, yandex.ru. И если на прошлой встрече мы больше болтали языком, то на этой будет пару скриншотов писем и консоль, где мы будем набирать:
nslookup -q=mx ваш-домен.ру
telnet ваш-почтовый-сервер 25
и все в таком духе……… 🙂
В конце встречи поговорим на тему, а является ли это вообще проблемой и стоит ли вообще от этого защищаться, я вот уверен, что MS не считает это проблемой 🙂
С большим вниманием я послушаю вас, мало того, что встреча получится, если у нас будет диалог, поэтому готовьте гарнитуры, а не просто наушники 
Для встреч будем использовать Lync из офиса 365, вы можете подключаться стандартным клиентом Lync или через браузер. Во втором случае вам будет предложено установить небольшой модуль на компьютер. А также возможно подключение с планшетов и телефонов. Ссылка уже доступна и я настоятельно рекомендую проверить возможность подключения заранее.
Для участия нужна гарнитура(наушники+микрофон) и Интернет.
p.s. Официальная продолжительность встречи 1 час, желающие могут оставаться сколько пожелают. На данных встречах не осуществляется поддержка пользователей по технологиям Microsoft.
Первый раз я случайно услышал о том, что Message-ID может содержать персональные данные отправителя, где то лет пять назад в Сиэтле от одного из менеджеров, участвующих в разработке Exchange Server. Сами понимаете, вечеринка, пиво, все немного расслабились и он поведал, что хотя существует RFC-822, где описаны принципы формирования MessageID, Exchange Server немного отходит от стандарта, вносит модификацию в заголовок и зная алгоритм, получатель может узнать IP адрес, имя компьютера, MAC адрес, тип процессора, объем жесткого диска,памяти и даже имя доменной учетной записи отправителя. Продолжить чтение
У моей жены есть блог, где она время от времени пишет свои мысли. Блог расположен на VDS, работает на WordPress и имеет свой собственный домен. На всякий случай, все письма на админа домена форвардятся провайдером на мой основной адрес. Уж не знаю, зачем это нужно, мало ли кому захочется связаться с автором блога.
Так вот, в один прекрасный день, я смотрю, у меня в Junk примерно 300 сообщений. Выглядят они вот так.
Уж какой в этом сакральный смысл я не знаю, одно или два сообщения содержали опасные аттачи и были вырезаны антивирусом. Тело текста plain. Рассылка похоже шла из вирусной сети, все хосты разные. На рабочий емейл такое не прошло бы, т.к. у отправляющих хостов нет реверсной записи и скорее всего они в DNS Black lists, но поскольку шло через провайдера, то принималось все.
Пост написан для того, чтобы показать какой еще бывает спам 🙂 Если у Вас есть мысл зачем рассылают подобный спам или Вы получали такой спам, напишите плиз.
Сегодня моя любимая жена пожаловалась на то, что у нее не доходят письма с mail.ru до одной ее подруги на aol.com.
AOL всегда отличался радикальными и жесткими мерами, по отношению к отправителям сообщений из Интернет, поэтому я как увидел адрес получателя, то аж крикнул: "Это же АОЛ!". Они довольно жестко обращаются с отправителями 🙂
В нашем случае NDR выглядел так:
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
SMTP error from remote mailer after initial connection:
host mailin-04.mx.aol.com [64.12.138.161]: 554 5.7.1 :
(RLY:B1)
По ссылке AOL предоставил расширенное описание ошибки
RLY Blocks 554 RLY:B1
This error message is a dynamic block on our system. Dynamic blocks are placed on an IP address when the IP's statistics break our threshold. These are automated blocks that are removed by the system within 24 hours once the complaints are again below the threshold.
Что же произошло на самом деле? Все очень просто. По каким-то причинам отправляющий SMTP сервер mail.ru попал в блок лист серверов AOL.com. Все бы ничего, если бы можно было просто удалить сервер из этого блок листа. В нашем же случае хост может быть удален в течении 24 часов, да форму заполнять на удаление не очень просто. А что вот делать моей жене? Ждать 24 часа? Пришлось отправить с другого адреса, а что делать, если бы это была бизнес почта. Тоже ждать 24 часа?
В общем я никогда не был фанатом AOL и похоже не буду.
Как-то давным давно я рассказывал о том, что иногда возникает ситуация, когда ваш почтовый сервер не может доставить сообщение по каким-либо причинам. При расследовании выясняется, что сервер не хочет принимать почту именно от вашего сервера. Что же делать? Ведь письмо должно быть доставлено, да и получатель по телефону утверждает, что его сервер работает и он получают сообщения с других серверов.
Сегодня попросил опубликовать пост для того, чтобы собрать фидбек от российского сообщества о добавлении новых функций в 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 и буду рассылать спам. Эта технология не поможет.
В каждой технологии есть плюсы и минусы, но Микрософту эту мысль “скормить” нужно, т.к. она действительно может быть полезна или они воспользуются ей, как частью какой-то антиспам технологии.
Саше по любому спасибо за пост.
Читал я тут на днях Интернет, много думал … и вычитал, что дескать MailSecurity у GFI полная ерунда. И вспомнилась мне одна давняя история про этот MailSecurity, после которой наша компания купила сей продукт, правда потом от него отказались. Но аргумент для покупки был отличный. Дело было так… Продолжить чтение