Mail.ru подмена поля from, как это возможно и кто виноват?
Всем привет.
На днях(4 августа) получил письмо на почту(mail.ru). Отправитель - help@sberbank.ru. Посмотрел - у них есть такой адрес и он используется. В письме не персонифицированно(уважаемый клиент...) уведомили о блокировке карты в связи с высокой активностью. Для разблокировки попросили прислать фото карты с двух сторон и главную страницу паспорта.
Подумав решил что это похоже на бред, т.к. сбер обычно звонит и вряд ли станет просить такую инфу. Позвонил в сбер, описал ситуацию(видимо это была "первая линия") перевели на "специалиста". Пока описывал ситуацию специалисту и по его просьбе проверял по буквам адрес, нажал ответить и увидел совсем другой адрес в фоме ответа. Сказал адрес специалисту, он поблагодарил за бдительность, посоветовал проверится на вирусы и ничего не отправлять.
Вредоносное ПО я исключаю - т.к. аналогичная ситуация на домашнем и рабочем ПК и на телефоне.
На следующий день создал тикет в mail.ru, где меня так же поблаголарили и ничего не объяснили. Скорее всего просто закрыли тикет.
Хочется понять на чьей стороне уязвимость и как до этой стороны достучаться. Думается что mail.ru, но я очень плох в ИБ - могу ошибаться. И не зря ли я так волнуюсь, оправданны ли мои мысли что это не мелкая проблема и требуют быстой реакции.
Спасибо!
Update:
Из ответов видно что это не уязвимость и я зря паниковал. Еще раз всем спасибо!
sasha_plh: они не позволяют отправлять такие письма. Т.е у себя с локального почтового сервера можно слать что угодно, и куда угодно. А получателю по большей части всё равно что там в заголовках, главное чтоб они валидные были.
Про локально я примерно так себе и представлял, вроде даже помню, что когда то это было частым сценарием. В том то и беспокойство мое, что на ящик mail.ru пришло письмо с подмененным отправителем и mail.ru его пропустил.
1) В заголовках письма будет явно видно что это не сбер...
2) Это уязвимость связана с тем, что ОБЫЧНО не проверяется адрес отправителя (технически это сложная операция банально)
D' Normalization: в вопросе топик-стартер использует термин "уязвимость" - раз в протоколе есть методы обхода этого риска, то из "особенностей" это переходит в дыры-уязвимости явно )
mace-ftl: ТС ДУМАЛ что это уязвимость, так как не знаком с протоколом. Это ниразу не уязвимость - это фича.
Antony: в теории можно всё что угодно. На практике этого нигде нету, так как:
Попытки затруднить пользователям подстановку в поле обратного пути в конверте и заголовке From корректного чужого адрес взамен адреса реального отправителя заведомо ошибочны — это затрудняет работу легитимных приложений, в которых почта передается одним пользователем по просьбе другого или отклики на ошибки (доставку) должны передаваться по специальному адресу (системы, которые обеспечивают пользователю удобные способы замены этих полей для каждого сообщения отдельно, должны будут пытаться создать основные и постоянные адреса почтовых ящиков для пользователей в соответствии с полями Sender в генерируемых сообщениях).