Надісланий мені електронний лист адресується на адресу MAIL@MAIL.COM. Як це робиться?

Мене нещодавно надіслали електронною поштою про шахрайство, і для хихикань я відкрив її для читання. Дуже просто, і не багато зусиль кинуто в.

Я помітив щось своєрідне; цей електронний лист не був адресований мені. Спочатку я підозрював CC, або BCC, але ніде в моїй пошті немає моєї адреси. Я подав малюнок нижче. Як це робиться?

Інтернет-повідомлення електронної пошти складається з двох частин. Ми можемо позначати їх як конверт і повідомлення про корисне навантаження або просто повідомлення .

У конверті є дані про маршрутизацію: насамперед, це адреса відправника та одна чи більше адрес одержувача.

У повідомленні є вміст повідомлення: рядок теми, тіло повідомлення, вкладення тощо. Він також містить деяку технічну інформацію, таку як Received:заголовки trace ( ), дані DKIM тощо; а також відображаються адреси відправника і одержувача (то , що ви бачите в From, Toі Ccполе в поштовому клієнті).

Ось суть цього: двоє не повинні погоджуватися!

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

Коли ви пишете та надсилаєте повідомлення електронною поштою, ваш клієнт електронної пошти приймає те, що ви ввели у поля До, Копія та Копія, та переводить це у інформацію про маршрутизацію конверту. В основному це робиться шляхом видалення будь-яких повних імен (залишаючи лише адреси електронної пошти), але також може включати такі речі, як переписування адрес, розширення псевдоніму тощо. Результатом є список адрес електронної пошти, які надаються поштовому серверу, з яким розмовляє поштовий клієнт, як список одержувачів. Списки Кому і Копії зберігаються в електронній пошті, однак Код не передається на сервер, що робить його непомітним для одержувачів повідомлень. Адреса відправника працює дуже аналогічно.

Коли повідомлення досягає кінцевого пункту призначення, дані конверту або викидають, або зберігають у детальних заголовках повідомлень. Це одна з причин, чому Spittin 'IT в коментарі до вашого запитання попросив повні заголовки повідомлень.

Крім того, за допомогою електронної пошти в Інтернеті можна спілкуватися безпосередньо з поштовим сервером і, таким чином, вводити повідомлення, яке має невідповідність між конвертними даними та даними повідомлення, які звичайний, добре поводиться клієнт електронної пошти не став би нехай складе. Крім того, поштові сервери роблять різний ступінь перевірки адреси відправника, яку вони надають у даних конвертів; деякі ледве перевіряють це, крім того, щоб переконатися, що це синтаксично дійсна адреса електронної пошти. Дані заголовка повідомлення піддаються ще меншій увазі.

Оскільки клієнт електронної пошти, що приймає, відображає те, що знаходиться у заголовках "Від" до "та" Копія ", а не дані адреси з конверта, можна помістити туди все, що завгодно, і клієнт, що отримує електронну пошту, не матиме жодного звернення, але вірити, що він є досить точним. Для законної пошти зазвичай вона є достатньо точною; для спаму, це майже ніколи не є.

У світі матеріальних, фізичних об'єктів , заселених нас простих людей, відправник конверта і одержувач конверта відповідає зворотну адресу і одержувача адреса, відповідно, що ви пишете на зовнішній стороні конверта; і заголовки From:та To:/ / Cc:відповідають тому, що ви вказали як свої та адреса одержувача відповідно до листа, який ви помістили в конверт.

tl; dr внизу.

Протокол SMTP не має поняття одержувачів CC або BCC; це конвенція, яку проводять поштові клієнти. Сервер SMTP, як правило, піклується про інформацію та дані про маршрутизацію. Це важлива відмінність, оскільки без цієї можливості БКК не могла б існувати. В якості законного зв'язку 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 конверт електронної пошти може не включати одержувачів, які фактично отримали повідомлення, а також можуть містити одержувачів, які не відображаються у заголовках повідомлень.

Як згадував @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, щоб перевірити, чи є такий електронний лист автентичним, але все ще є багато старих поштових серверів, які не хвилюються, просто тому, що це спокуса не виправляти речі, які не порушені.

Також зверніть увагу, як я вказав заголовок дати. Це може бути будь-яке довільне (але добре відформатоване) значення; багато клієнтів із задоволенням відображають будь-який законний діапазон дат від далекого минулого до далекого майбутнього. Я особисто надсилав собі електронний лист років тому, який залишатиметься у верхній частині моєї поштової скриньки довгий час після моєї тривалості життя, а також електронний лист, який передував моєму обліковому запису електронної пошти та моєму власному народженню.

тл; д-р

Отже, підсумовуючи повідомлення, відправник підробив електронний лист, поштовий сервер, що походить, прийняв / повторно відправив його, ваш сервер електронної пошти прийняв його і зберігав у вашій скриньці, а ваш клієнт вірно відображав дані, які були у вашій папці "Вхідні", все, не обходячи його. будь-яка безпека. Безпека "надсилання" часто набагато менш обмежена, ніж захист "отримання" в цій перспективі, оскільки POP3 майже завжди вимагає імені користувача та пароля, перш ніж ви зможете отримати доступ до поштової скриньки (теоретично ви могли це обійти, але я не знаю жодного законного поштові послуги, які роблять).

SMTP та електронна пошта - це дуже давні Інтернет-сервіси з епохи, коли безпеку та автентифікацію сприймали набагато менш серйозно (ще один приклад - DNS). Конструкція протоколу не докладає зусиль для перевірки достовірності адреси відправника, а лише перевіряє адресу одержувача, наскільки це забезпечує доставку пошти.

Електронна пошта передається через протокол SMTP. Протокол SMTP є відносно німим; він надає можливість для передачі простого тексту на електронну адресу та дуже мало іншого. Структура цього простого тексту визначається RFC 5322 . Загальна ідея полягає в тому, що в тексті електронної пошти є метадані, які називаються заголовком, і власне текстове тіло повідомлення. Цей заголовок електронної пошти генерується відправником (жодному з них не можна довіряти) і містить поля типу "до:", "від:", "тема:" тощо.

Протокол 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.