Мне недавно прислали мошенническое электронное письмо, и я, для хихиканья, открыл его, чтобы прочитать. Очень простой и не слишком много усилий
Я заметил нечто особенное; это письмо не было адресовано мне. Сначала я подозревал CC или BCC, но нигде не было моего адреса на почте. Я предоставил картинку ниже. Как это сделать?
Электронное почтовое сообщение состоит из двух частей. Мы можем обозначить их как конверт и сообщение с полезной нагрузкой или просто сообщение.
Конверт содержит данные маршрутизации: в первую очередь это адрес отправителя и один или несколько адресов получателей.
Сообщение содержит содержание сообщения: строку темы, текст сообщения, вложения и т.д. Он также содержит некоторую техническую информацию, такую как заголовки trace (Received: :), данные DKIM и т. Д .; а также отображаемые адреса отправителя и получателя (что вы видите в полях From , To и Cc в вашем почтовом клиенте).
Вот суть этого: два не должны соглашаться!
Почтовый сервер проверит данные конверта, чтобы определить, как отправить сообщение. С другой стороны, за некоторыми исключениями, само сообщение будет рассматриваться как просто данные. В частности, почтовый сервер с хорошим поведением не просматривает поля To: и Cc: самого сообщения для определения списка получателей, а также не просматривает поле From: для определения адреса отправителя.
Когда вы создаете и отправляете электронную почту, ваш почтовый клиент берет то, что вы ввели в поля «Кому», «Копия» и «Скрытая копия», и преобразует это в информацию о маршруте конверта. Это в основном делается путем удаления любых полных имен (оставляя только адреса электронной почты), но может также включать такие вещи, как перезапись адресов, расширение псевдонимов и так далее. В результате получается список адресов электронной почты, которые передаются почтовому серверу, с которым ваш почтовый клиент обращается в качестве списка получателей. Списки «Кому» и «Копия» хранятся в электронном письме, но скрытая копия не передается на сервер, что делает его невидимым для получателей сообщения. Адрес отправителя работает очень похоже.
Когда сообщение достигает конечного пункта назначения, данные конверта либо выбрасываются, либо сохраняются в подробных заголовках сообщения. Это одна из причин, по которой Spittin 'IT попросила указать полные заголовки сообщений в комментарии к вашему вопросу.
Кроме того, с электронной почтой в Интернете можно напрямую общаться с почтовым сервером и, таким образом, внедрить сообщение, которое имеет несоответствие между данными конверта и данными сообщения, что не будет нормальным почтовым клиентом с хорошим поведением. пусть ты сочиняешь. Кроме того, почтовые серверы выполняют различные степени проверок адреса отправителя, который они указываются в данных конверта; некоторые почти не проверяют его, кроме того, чтобы убедиться, что это синтаксически действительный адрес электронной почты. Заголовок From данных сообщения подвергается еще меньшей проверке.
Поскольку принимающий почтовый клиент отображает то, что находится в заголовках From, To и Cc, а не адресные данные из конверта, можно поместить туда все, что вы захотите, и у принимающего почтового клиента не останется никаких ресурсов, кроме как полагать, что он является достаточно точным. Для законной почты это обычно достаточно точно; для спама это почти никогда не бывает.
В мире материальных, физических объектов, населяющих нас, простых людей, отправитель конверта и получатель конверта соответствуют адресу возврата и адресу получателя, соответственно, которые вы пишете на внешней стороне конверта; и заголовки From: и To:/Cc: соответствуют тому, что вы указали в качестве адреса вашего и получателя соответственно в письме, которое вы положили в конверт.
д-р внизу.
Протокол SMTP не имеет понятия о получателях CC или BCC; это соглашение проводится почтовыми клиентами. SMTP-сервер обычно заботится только о маршрутизации информации и данных. Это важное различие, потому что без этой возможности BCC не может существовать. В качестве законного сообщения BCC рассмотрим следующую клиентскую стенограмму:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Теперь в этом случае Анониму было отправлено сообщение об этой встрече. Однако эта версия почты не была направлена Джейн Доу; она ничего не знает о том, что Аноним был уведомлен. Напротив, Джейн Доу будет отправлено сообщение с другим телом и заголовком:
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Здесь, поскольку Anonymous находился в BCC, сообщение, отправленное Джейн Доу, не включало список получателей BCC. Из-за соглашения BCC конверт электронной почты может не включать получателей, которые фактически получили сообщение, и может также включать получателей, которые не отображаются в заголовках сообщений.
Как упомянул @JonasWielicki, который я также хотел включить, это то, что MUA (почтовый пользовательский агент) обычно отвечает за отправку нескольких электронных писем, необходимых для реализации BCC. Серверы электронной почты ничего не знают о BCC, поэтому MUA должен внедрить BCC, отправляя несколько электронных писем с различными маршрутами электронной почты, указанными в заголовках конвертов. По этой причине отправка сообщений BCC обычно занимает больше времени, чем обычные электронные письма, поскольку различные тела сообщений должны создаваться и отправляться индивидуально.
Это также помогает с некоторыми правилами соответствия электронной почты. Например, почтовый сервер может иметь правила, настроенные для автоматической BCC архивного почтового сервера (все отправленные на него электронные письма также архивируются), и в этом случае почтовый сервер может даже не быть реальным получателем.
HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Здесь получателем является другая сторона, которая полностью не раскрыта ни одному из получателей или даже отправителю. Это особенность протокола, обычно используемая для ретрансляции или архивирования сообщений.
Что спам-сообщение сделало, так это воспользовалось этим поведением. Это стандартная лазейка, которая технически должна работать с любым совместимым почтовым сервером. Конечно, многие обновленные серверы используют "расширения", такие как DKIM, для проверки подлинности такой электронной почты, но есть еще много старых почтовых серверов, которым все равно, просто потому, что соблазнительно не исправить вещи, которые не сломаны.
Также обратите внимание, как я указал заголовок Date. Это может быть любое произвольное (но хорошо отформатированное) значение; многие клиенты с радостью отобразят любой допустимый диапазон дат от далекого прошлого до далекого будущего. Я лично отправил себе электронное письмо много лет назад, которое останется в верхней части моего почтового ящика после моей продолжительности жизни, а также электронное письмо, предшествующее моей учетной записи электронной почты и моему рождению.
Итак, в итоге, отправитель подделал электронное письмо, исходящий почтовый сервер принял / ретранслировал его, ваш почтовый сервер принял его и сохранил в папке "Входящие", а ваш клиент достоверно отобразил данные, находящиеся в папке "Входящие", без обхода любая безопасность. "Отправка" безопасности часто гораздо менее ограничена, чем "получение" безопасности в этом ракурсе, поскольку POP3 почти всегда требует имени пользователя и пароля, прежде чем вы сможете получить доступ к почтовому ящику (теоретически вы можете обойти это, но я не знаю никаких законных почтовые сервисы, которые делают).
SMTP и электронная почта - это очень старые интернет-сервисы того времени, когда безопасность и аутентификация воспринимались гораздо менее серьезно (другой пример - DNS). Структура протокола не прилагает усилий для проверки подлинности адреса отправителя и проверяет адрес получателя только в том случае, если он обеспечивает доставку почты.
Электронная почта передается по протоколу SMTP. Протокол SMTP относительно тупой; он предоставляет возможность передавать открытый текст на адрес электронной почты и даже немного больше. Структура этого открытого текста определена в RFC 5322. Общая идея заключается в том, что в тексте электронной почты есть метаданные, называемые заголовком, и фактическое текстовое тело сообщения. Этот заголовок электронного письма генерируется отправителем (ни одному из них нельзя доверять) и содержит поля типа «to:», «from:», «subject:» и т.д.
Протокол SMTP не проверяет (и не должен) проверять, соответствуют ли заголовки электронной почты очень немногим вещам, определенным в протоколе SMTP, которые, по сути, являются вашим адресом электронной почты и адресом электронной почты отправителя, который никогда не проверяется каким-либо образом.
Почти все в сообщении электронной почты может быть поддельным.
Единственное, что даже отдаленно заслуживает доверия в отношении содержимого электронной почты сегодня, - это подписи DKIM, которые доказывают, что электронная почта была обработана через сервер электронной почты, санкционированный владельцем домена. Углубившись вглубь, вы обнаружите, что это мошенническое письмо не имеет подписи DKIM.
Адрес To в заголовке письма предназначен для информационных целей и отображается почтовым клиентом. Реальный адрес получателя указывается с помощью RCPT TO в SMTP. То же самое, если вы пишете письмо, кладете в конверт, пишете адрес-1 на конверте. Тогда иди к курьеру, дай другой адрес-2. Курьер кладет ваш конверт в больший конверт с адресом-2, и посылка отправится туда. Ваш секретарь (программа-клиент электронной почты) помещает внешний конверт в корзину и показывает вам внутренний конверт с адресом-1. Вы можете увидеть это в RAW-сообщении электронной почты.
Это немного другой вид, основанный на изучении заголовков. Другие ответы обрабатывают детали SMTP лучше, чем я.
Если вы можете получить полные заголовки вашего сообщения, а затем найти их по своему адресу, вы можете найти его в поле под названием Envelope-to , Delivered-to или X-Apparently-to . Первый используется моим почтовым провайдером, второй - Gmail; Я видел третий использованный также. Это разные поля, но для наших целей они, как правило, означают одно и то же: почтовый ящик, в который фактически доставляется сообщение. Я проверил, отправив из Outlook (настольная версия) с получателем BCCed.
Мой почтовый провайдер также использует поле Delivered-To но для имени почтового ящика на своем сервере. Это не мой адрес электронной почты, хотя он выглядит как один (подумайте ChrisH-$ACCOUNTNAME@$SERVER.mail.com).
Outlook (в сочетании с сервером обмена), с другой стороны, не включает в заголовки одно поле с адресом электронной почты получателя, если вы указаны как BCC.