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