Комментарии 98
Вам стоит приложить скриншот переписки с техподдержкой, раз уж такая реакция у представителей.
к сожалению, электронная почта действительно изначально не защищена от подделки адреса. Существует стандарт DMARC который позволяет защититься от подделки, но работает только на письмах соответствующих стандарту RFC 5322 и только для отправителей, настроивших политику DMARC. В настоящее время достаточно много писем не соответствует этому стандарту и проверить на них DMARC невозможно. Постепенно мы «закручиваем гайки» для нестандартных писем. Сейчас на таких письмах (и в некоторых других ситуациях) показывается уведомление о возможной подделке адреса, что видно на скриншоте, поэтому пользователь предупрежден и мы не считаем данную ситуацию ошибкой.
P.S. duma.gov.ru в принципе не публикует политику DMARC, поэтому защитить письма от этого домена от подделки стандартными средствами невозможно.
Т.е. существует две разные проблемы:
1. From в электронной почте можно подделать для всех доменов не имеющих строгого DMARC (пока это большинство). Это глобальная историческая проблема электронной почты.
2. Можно обойти DMARC через письма, нарушающие стандарт электронного письма RFC 5322. Это так же известная и широко обсуждаемая проблема. Пока это действительно так, поскольку такие письма принимаются (потому что, к сожалению, много легальных отправителей шлют такие письма). Чаще всего на них срабатывает антиспам, иногда нет. Срабатывание или не срабатывание антиспама не является ошибкой безопасности, т.к. антиспам чаще всего действует ре-активно. В тех случаях, когда антиспам решает пропустить такое письмо, Mail.Ru показывает на нем предупреждение о возможной подделке адреса.
В данном случае в From записывается мусор в HTML-енкоде, не имеющем отношения к почте, и он вообще полностью некорректен.
![image](https://habrastorage.org/web/26a/244/021/26a2440210a4454d8d1ef31cd2b7f581.png)
Это проблема, которой больше 30 лет, которая активно решается несколько последних лет и будет еще несколько лет решаться, пока все письма не соответствующие стандартам не начнут реджектиться. В текущих реалиях это (реджект всех неправильных писем) приведет к волне негатива, т.к. таких писем очень много. Для начала на них будет показываться предупреждения, потом они будут отправляться в спам и далее по нарастающей.
Начинает складываться впечатление, что в этом месте (подделка отправителей) «дыра на дыре»…
Узнать бы мнение самого Яндекса :)
Для современных разработчиков SMTP too low layer :(
И читать rfc по нему им не нужно. И правда — в том же питоне достаточно тыц-тыц, и вызвать одной строчкой из того или другого модуля, и не думать ни о чём.
Допустим, запретили. Дальше:
— у пользователей начались внезапные нестыковки с интернет-магазинами
— отправитель фишинговых писем заметил, что они не приходят на тестовый ящик, и изменил ">>" на "<<".
Силы (деньги?) потрачены, обратная совместимость нарушена, негатив клиентам создан, дырка осталась. А в чем профит?
А так бы конечно да, ответ mail'а бы выложить.
Это было на mail.ru. По smtp авторизация вообще не применялась, поэтому даже в outlook express можно было в адрес о правителя вписать кого угодно (с домена mail.ru). При этом письмо не "подделывалось" а действительно отправлялось с с аккаунта, подписанного в поле from.
Вообще-то, изначально, поле From != адресу отправителя, по стандарту (я могу путать детали, читал RFC давно).
Например, секретарша записывает письмо со слов начальника. В таком случае ей следует указать в поле From адрес начальника, тогда как она отправляет письмо со своего аккаунта, не имея доступа к аккаунту начальника. А вот адрес её аккаунта следует указывать в поле Sender.
Как уже упомянули не раз выше — проблема E-Mail в том, что он создавался очень давно (если не ошибаюсь, он старше того, что мы сейчас называем интернетом). Печатные письма в те времена тоже можно было легко подделать, особенно если их печатала секретарша на печатной машинке. Просто проблемы спама, а тем более массовой подделки в те времена не существовало.
Вполне точно, я говорил про заголовки самого письма, а не про то, что каждый SMTP сервер в цепочке добавляет свой заголовок к пакету, а не к самому письму (могу путать термины, но суть такая).
Ну а в современных условиях GMail суёт в мои письма адрес моего аккаунта в Sender принудительно, если он не равен From — вот это вот не по стандарту. (Или делал так какое-то время назад. Адреса в From, естественно, верифицированы для моего аккаунта.)
Впрочем, в большинстве клиентов отображение поля Sender даже отключено и почти никто не знает что это и зачем.
UPD: Похоже это я запутался в ответах, ну да и ладно.
Я перестал пользоваться мейлру, когда в далеком 2006-м однажды утром обнаружил в папке "входящие" письма, которые я удалил 1-2 года назад. Вот просто так, взяли и появились.
Gmail тогда ещё был по приглашениям, счастливым обладателем которого я тогда и стал.
+1
Но требует квалификации.
свой сервер
К сожалению, владельцы сервисов не очень хотят защищать пользователей от отправки поддельных писем от имени этого сервиса, что и описывалось в статье по ссылке.
Отдельная проблема — почтовые сервисы. Они должны проверять письма на подделку, но не всегда это делают (по разным причинам) или делают неправильно. Например, есть забавная уязвимость в Yahoo, которая позволяет обойти проверку DMARC и SPF и подделать письмо от абсолютно правильно настроенного сервиса.
В тему писем: хотелось бы спросить z3apa3a, почему нужно использовать DMARC (за исключением защиты поддоменов). Часто получаю ответы от разных сервисов вида «Мы публикуем SPF-запись, почтовые провайдеры должны сами проверять запись и отправлять в спам письмо с „~“ и не принимать с „-“, этого достаточно». Буду благодарен за ответ.
Соответственно, SPF не защищает письма от подделки. Совсем. SPF это протокол аутентификации почтового сервера на уровне транспорта (SMTP), он вобще не смотрит в содержимое письма и в поле From: в частности. Например, домен bob.com имеет строгую SPF-политику. У атакующего есть домен alice.org, который он контролирует. Атакующий может отправить письмо
EHLO alice.org
MAIL FROM: <m@alice.org>
RCPT TO: <some@example.com>
DATA
From: <g@bob.com>
Subject: hello
hello
.
и письмо успешно пройдет SPF-аутентификацию, т.к. SPF проверяет адрес конверта (m@alice.org), но получатель увидит содержимое From:, т.е. g@bob.com.
DMARC не заменяет SPF и DKIM, он использует SPF и DKIM как протоколы аутентификации отправителя из From:. Т.е. нужен И SPF И DKIM (на самом деле хотя бы один из них — но лучше оба) И DMARC.
Соглашусь.
На самом деле должна быть проверка From при отправлении письма на соответствие относящимся к аутентифицированному отправителю адресов или их псевдонимов. У меня на поддерживаемых SMTP такое реализовано всегда.
В случае же с некорректно сформированным письмом z3apa3a уже пояснил суть проблемы. Либо жёстко проверять на соответствие стандартам (и отгребать от пользователей за неполученные письма), либо менее формально подходить к вопросу в ряде ситуаций, отдавая вопрос на отработку антиспам-алгоритмам которые могут быть настроены так или иначе.
Безусловно, From и Envelope-from могут отличаться. Именно поэтому я и упомянул о псевдонимах. Я понимаю как и что работает, поэтому эти упомянутые проверки затрагивают исключительно аутентифицированных пользователей (о чём также написано выше) и не затрагивают генерируемые тем или иным софтом сообщения. Более того, последние исключены и из многих других проверок.
Кстати, можно сделать и менее жёсткую проверку. К примеру на соответствие содержимого From локальным (поддерживаемых в рамках этой системы) доменов. Но это не спасёт от использования чужого адреса их данного набора доменов.
В любом случае, разрешать пользователю отправлять сообщения от постороннего адреса это плохая практика.
П. С. Перед тем как минусовать, лучше объяснить, почему вы ставите тот же минус.
Меня больше напрягает, что майл позволяет отправлять со своей почты опасные вложения, exe com js и прочие.
Эти вложения давно считаются опасными и блокируются гуглом и яндексом, а вот майл почему то принципиально не хотят блокировать эти вложения.
Опишу суть проблемы:
майл говорит что вся почта (и облако) проверяется на вирусы, однако все прекрасно понимают, прежде чем запустить новый вирус его проверяют, проверяют в том числе и антивирусником который проверяет почту на майл ру.
На моем почтовом сервере настроена блокировка подобных вложений, с отчетами о блокировках. По моей личной статистике 90% всех почтовых вирусов отправляются именно с майл.ру. Вот это действительно проблема.
По этим же соображениям приходится выдавать доступ к облаку майл.ру «по талонам», с предварительной ручной проверкой скачиваемых файлов (благо таких запросов в месяц не более 5).
Хочешь защитить пользователя — запрети ему получать *.exe и прочие исполняемые файлы.
и прочие обычные данные (картинки, тексты и т. д.) — вики
А раньше еще была такая дичь как открытые релеи.
http://www.antispam.ru/sh?act=msg&id=1033474961
https://en.wikipedia.org/wiki/Open_mail_relay
Да, такой вот он сейчас /sarcazm
Поэтому рассказывать про проблемы безопасности mail.ru, следующей RFC, на мой взгляд, несколько желтушно, мягко говоря.
Ну — вариант.
А стандарты — как вам сказать… Ну настроил какой-то студент в своем первом в жизни постфиксе проверку обратной зоны DNS домена отправителя (по стандартам и/или книгам начала 70-х) — и потом жалуется в хабр, что к нему почта не ходит.
Такой вот вклад в безопасность, ага.
Проблема актуальная. Воспроизведение через thunderbird работает.
— адекватных фильтров
— правил
— папок
У мейла, в свою очередь, безумно очевидные вещи в фильтрах вроде «удалить и послать сообщение о несуществующем адресе», чтоб с большей вероятностью убраться из списка рассылки.
По теме статьи: очень грустно, что некоторые люди пишут про «кто-то лишится премии», имея в виду особенность, обсуждаемую с момента распространения smtp.
Это не баг, это стандартная работа электронной почты.
Протокол позволяет что угодно писать в обратный адрес и в имя отправителя.
А проверять и доверять это уже надо на стороне получателя.
Много лет уже работает у меня рассылка по договорам от имени ответственных инженеров. И вот как раз проблемы с теми кто свой сервер настроил проверять обратный адрес и адрес реального отправителя.
Тех поддержка заявила что **** и что там его никогда не было!
Я им посоветовал воспользоваться поиском, и посмотреть как закрывать письмо, не потеряв поиск.
Меня просто послали…
Особенно вера то, что в интернете есть стандарты, и все почтовики им следуют, напрягает, когда очередной горе-админ настроит у себя серый список, не напишет в возвращаемом сообщении логику его работы, а тебе срочно на тот домен нужно важное письмо отправить. Способа нет, кроме как отказаться от отправки письма, и отправить человеку на нормальный сервис (тот же, да, mail или gmail). Хотя кто мешает написать в возвращаемом тексте «Your message is graylisted, please be back in 5 minutes to try again»?
Со стандартами вот какая история: RFC — это requests, это просьбы написать замечания. Да, их считают стандартами, но за их нарушения крайне трудно наказать, так что назовем их «рекомендациями». В частности, хотя коды 4xx говорят почтовикам попробовать через некоторое время, никто не гарантирует отправку через это время. Более того, если у меня на отправку стоит правило пробовать отправить через полчаса, затем с увеличением интервала в 3 раза, но не более 5 часов, то мой почтовик попробует: 0.5 часа, 1.5 часа, 4.5 часа, все — три раза. Это нормально, и это та логика, которую я на своем конце запрограммировал.
Если на стороне приема
Что там у mail, не знаю. У них кластер на отправку, вероятно, велик, и очередь разгребается хитрее, чем можно подумать. Какие-то сроки перепопыток гарантировать они не будут, да и незачем им (в RFC ничего такого не написано), а как mail подстроиться к каждому админу страны?
Черные списки, кстати, та еще штука — они ни за что не отвечают, просто отвечают, кого они считают редиской. Это уже вопрос к принимающему серверу, смотреть ли в них, верить ли им, и насколько верить. И крупные игроки вполне могут сказать: раз адрес сервера у нас ресолвится в *.google.com (грубо), или в *.mail.ru, то вы уж сами решайте, будете вы такие IP проверять по вашим спискам.
Я к тому, что крупные почтовые провайдеры предпринимают разумные меры к доставке почты, но они скорее нужны мелким почтовикам, что мелкие почтовики — им.
Ага. Щаз. Искореню.
У mail.ru логика топорно проста «не нравится — не пользуйся». Именно поэтому они на RFC кладут такой преогромный железобетонный.
Так чем Вы лучше их? Их система работает так, как работает (мы бы с Вами, подозреваю, не факт что построили бы лучше, с учетом масштаба), и — работает. Вы ссылаетесь на RFC, которые сделаны для доставки почты, а не для ее отбивания, не выполняете их дух (потому что доставку постоянно обеспечиваете не с первого раза), но недовольны, что кто-то еще что-то там нарушает?
Напоминает "- Смотри, чувак идет, пойдем его побьем? — Да он здоровый, еще нас поколотит! — А нас-то за что?"
Я понимаю смысл от greylisting, если он изучает переписку человека, и не задерживает почту от того же человека, с того же IP-адреса больше одного раза. Тогда и задержка для «своих» не видна, и спам вроде как бьется.
Кстати, если про черные списки, вы видели у них такое поведение: если с одного адреса много спама, то в список добавляется /24 вокруг адреса, если продолжается, то /23 и так далее, до размера route-object порой. Все алгоритмически хорошо, но это как «в вашей школе учится драчун, постоянно колотит окрестных ребят, мы посадили в тюрьму всех учеников школы, а заодно и всех детей района проживания драчуна». На все вопрос ответ один — «мы ни за что не отвечаем, хотите — пользуйтесь».
Проблемы безопасности почты Mail.ru