Письмо, отправленное мне, адресовано на MAIL@MAIL.COM. Как это сделать?


103

Мне недавно прислали мошенническое электронное письмо, и я, для хихиканья, открыл его, чтобы прочитать. Очень простой и не слишком много усилий

Я заметил нечто особенное; это письмо не было адресовано мне. Сначала я подозревал CC или BCC, но нигде не было моего адреса на почте. Я предоставил картинку ниже. Как это сделать?

введите описание изображения здесь


8
Разместите полные заголовки сообщений ... также у вас может быть дополнительный SMTP-адрес на почтовом сервере, на который он был отправлен Администраторы почтового сервера должны быть в состоянии помочь вам проконсультировать вас по этому вопросу, но отредактируйте свой ответ и опубликуйте полный заголовок сообщения также.
Сок Pimp IT

55
Вы, вероятно, были в поле слепой копии электронной почты.
Мокубай

61
Вы не увидите список BCC, это часть «B» . ;)
Ƭᴇcʜιᴇ007

14
@tuskiomi Нет, не в Outlook. Gmail показывает bcc: me, возможно, другие тоже ... Но если вы посмотрите на полные заголовки сообщений, вы должны увидеть свою электронную почту там
wysiwyg

20
@tuskiomi - Нет, вы никогда не увидите никого из перечисленных в BCC, даже себя. Более того, если это спам, может даже не быть настоящего списка BCC; spamware может управлять списком получателей любым способом, и в конечном итоге важно то, как выглядит диалог spamware с почтовым сервером, а не как содержимое почты. Единственный способ увидеть свой адрес электронной почты, если вы посмотрите на интернет-заголовки.
Джефф Цейтлин

Ответы:


152

Электронное почтовое сообщение состоит из двух частей. Мы можем называть их конвертом и сообщением полезной нагрузки или просто сообщением .

Конверт содержит данные маршрутизации: в первую очередь это адрес отправителя и один или несколько адресов получателей.

Сообщение имеет содержание сообщения: строку темы, текст сообщения, вложения и т. Д. Он также содержит некоторую техническую информацию, такую ​​как Received:заголовки trace ( ), данные DKIM и т. Д .; а также отображаемые адреса отправителя и получателя (то, что вы видите в полях From, Toи Ccв вашем почтовом клиенте).

Вот суть этого: два не должны соглашаться!

Почтовый сервер проверит данные конверта, чтобы определить, как отправить сообщение. С другой стороны, за некоторыми исключениями, само сообщение будет рассматриваться как просто данные. В частности, хорошо себя почтовый сервер не смотреть на To:и Cc:полях самого сообщения , чтобы определить список получателей, и не смотреть на From:поле , чтобы определить адрес отправителя.

Когда вы создаете и отправляете электронную почту, ваш почтовый клиент берет то, что вы ввели в поля «Кому», «Копия» и «Скрытая копия», и преобразует это в информацию о маршрутизации конверта. Это в основном делается путем удаления любых полных имен (оставляя только адреса электронной почты), но может также включать такие вещи, как перезапись адресов, расширение псевдонимов и так далее. В результате получается список адресов электронной почты, которые выдается почтовому серверу, с которым ваш почтовый клиент обращается, как список получателей. Списки «Кому» и «Копия» хранятся в электронной почте, но скрытая копия не передается на сервер, что делает его невидимым для получателей сообщения. Адрес отправителя работает очень похоже.

Когда сообщение достигает конечного пункта назначения, данные конверта либо выбрасываются, либо сохраняются в подробных заголовках сообщения. Это одна из причин, по которой Spittin 'IT попросила указать полные заголовки сообщений в комментарии к вашему вопросу.

Кроме того, с электронной почтой в Интернете можно напрямую общаться с почтовым сервером и, таким образом, внедрить сообщение, которое имеет несоответствие между данными конверта и данными сообщения, что не удалось бы обычному почтовому клиенту с хорошим поведением пусть ты сочиняешь. Кроме того, почтовые серверы выполняют различные степени проверок адреса отправителя, который они указаны в данных конверта; некоторые почти не проверяют его, кроме того, чтобы убедиться, что это синтаксически действительный адрес электронной почты. Заголовок From данных сообщения подвергается еще меньшей проверке.

Поскольку клиент получающей электронной почты отображает то, что находится в заголовках From, To и Cc, а не данные адреса из конверта, можно поместить туда все, что вы захотите, и клиент получающей электронной почты не будет иметь никакого выбора, кроме как доверять этому. является достаточно точным. Для законной почты это обычно достаточно точно; для спама это почти никогда не бывает.

В мире материальных, физических объектов , заселенных нас простых людей, отправитель конверта и получатель конверта соответствует обратный адрес и получателя адрес, соответственно, что вы пишете на внешней стороне конверта; и From:и To:/ Cc:заголовки соответствуют все , что вы кладете в ваш адрес и адрес получателя, соответственно, в письме , которое вы положили в конверт.


8
Я бы хотел, чтобы люди проводили здесь больше реальных аналогий, чтобы другие понимали, что такое физический эквивалент. «Отправитель» электронного письма похож на человека, вручающего почтальону конверт; адрес «от» - это тот, с которого он предназначен. Как будто вы можете быть секретарем, отправляющим кого-то от имени и т. Д.
Мердад

21
@ Mehrdad Нет; адрес отправителя конверта (SMTP) подобен адресу возврата на внешней стороне конверта (куда он отправляется, если не может быть доставлен), тогда как адрес в Fromзаголовке - это то, что вы пишете на клочке бумаги, который вставляете. внутри конверта и о котором почтальон даже не знает.
CVn

Когда я писал это, я думал о заголовке Sender: и это был просто пример. Просто скажу, что было бы неплохо добавить такой пример в свой ответ.
Мердад

91
Количество полужирным здесь действительно нет необходимости в лучшем случае . И это только мое мнение .
JakeGould

3
@SupremeGrandRuler Потому что информация о получателе (в отличие от возможного отправителя или пути возврата) не содержится в электронном письме. Представьте, что был включен полный список получателей, включая адреса, которые MUA получил из поля Bcc (помните: SMTP (протокол конверта) не знает о Bcc, он знает только о получателях)… Это было бы проблемой конфиденциальности (и огромная трата пространства) не только в больших списках рассылки (работающих по тому же принципу, что и Bcc).
Йонас Шефер

23

д-р внизу.

Протокол 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 почти всегда требует имени пользователя и пароля, прежде чем вы сможете получить доступ к почтовому ящику (теоретически вы можете обойти это, но я не знаю ни одного законного почтовые сервисы, которые делают).


3
Следует отметить, что удаление Bcc, как правило, не обрабатывается почтовыми серверами (предоставленная вами запись SMTP указывает на обратное, поскольку HELO звучит как почтовый сервер, а не как MUA). Чтобы предоставить копию с заголовком скрытой копии лицу, указанному в этом заголовке, MUA требует дополнительной работы, отправив два отдельных электронных письма.
Йонас Шефер

@JonasWielicki Это хороший момент. Я добавил изменения на этот счет.
phyrfox

5
Если вы добавите линию ОЦК в доставленную почту, она больше не будет слепой :)
eckes

1
На самом деле требование клиента отправлять несколько сообщений в случае BCC неверно. Это совершенно нормально, чтобы отправить только одно сообщение. SMTP-клиент может перечислить несколько RCPT TOинструкций. Единственное требование заключается в том, чтобы SMTP-сервер-получатель был либо официальным сервером для обоих получателей, либо был бы готов ретранслировать данные для любого другого, которым он не является.
Патрик

6

SMTP и электронная почта - это очень старые интернет-сервисы того времени, когда безопасность и аутентификация воспринимались гораздо менее серьезно (другой пример - DNS). Структура протокола не прилагает усилий для проверки подлинности адреса отправителя и проверяет адрес получателя только в том случае, если он обеспечивает доставку почты.

Электронная почта передается по протоколу SMTP. Протокол SMTP относительно тупой; он предоставляет возможность передавать открытый текст на адрес электронной почты и даже немного больше. Структура этого открытого текста определена в RFC 5322 . Общая идея заключается в том, что в тексте электронной почты есть метаданные, называемые заголовком, и фактическое текстовое тело сообщения. Этот заголовок электронного письма генерируется отправителем (ни одному из них нельзя доверять) и содержит поля типа «to:», «from:», «subject:» и т. Д.

Протокол SMTP не проверяет (и не должен) проверять, соответствуют ли заголовки электронной почты любой из очень немногих вещей, определенных в протоколе SMTP, которые, по сути, являются вашим адресом электронной почты и адресом электронной почты отправителя, который никогда не проверяется каким-либо образом.

Почти все в сообщении электронной почты может быть поддельным.

Единственное, что даже отдаленно заслуживает доверия в отношении содержимого электронной почты сегодня, - это подписи DKIM, которые доказывают, что электронная почта была обработана через сервер электронной почты, санкционированный владельцем домена. Углубившись вглубь, вы обнаружите, что это мошенническое письмо не имеет подписи DKIM.


Я бы добавил окончательный Received:заголовок, добавленный вашей собственной системой к надежным частям.
Хаген фон

3

Адрес Toв заголовке письма предназначен для информационных целей и отображается почтовым клиентом. Реальный адрес получателя указывается RCPT TOв SMTP. То же самое, если вы пишете письмо, кладете в конверт, пишете адрес-1 на конверте. Тогда иди к курьеру, дай другой адрес-2. Курьер кладет ваш конверт в больший конверт с адресом-2, и посылка отправляется туда. Ваш секретарь (программное обеспечение почтового клиента) помещает внешний конверт в корзину и показывает вам внутренний конверт с адресом-1. Вы можете увидеть это в RAW-сообщении электронной почты.


2

Это немного другой вид, основанный на изучении заголовков. Другие ответы обрабатывают детали SMTP лучше, чем я.

Если вы можете получить полные заголовки вашего сообщения, а затем найти их по вашему адресу, вы можете найти его в поле с именем Envelope-to, Delivered-toили X-Apparently-to. Первый используется моим почтовым провайдером, второй - Gmail; Я видел третий использованный также. Это разные поля, но для наших целей они, как правило, означают одно и то же: почтовый ящик, в который фактически доставляется сообщение. Я проверил, отправив из Outlook (настольная версия) с получателем BCCed.

Мой почтовый провайдер также использует это Delivered-Toполе, но для имени почтового ящика на своем сервере. Это не мой адрес электронной почты, хотя выглядит так (подумайте ChrisH-$ACCOUNTNAME@$SERVER.mail.com).

Outlook (в сочетании с сервером обмена), с другой стороны, не включает в заголовки ни одно поле с адресом электронной почты получателя, если вы указаны в качестве BCC.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.