Повідомлення електронної пошти зазвичай складається із двох частин:
заголовка(header), що містить службову інформацію, що управляє доставкою та обробкою повідомлення;
тіла(body), що містить безпосередньо повідомлення користувача: текст і прикріплені дані (графічні, звукові файли і т.п.).
Заголовок повідомлення
Поштове повідомлення – це простий текст у форматі ASCII. Тому заголовок повідомлення є послідовністю текстових рядків виду:
Стандартом поштових повідомлень передбачено велику кількість полів. Частина є обов'язковими, тобто. без них неможливо здійснити правильну доставку повідомлень, а частина – необов'язкова. Нижче перераховані поля, які найчастіше використовуються.
Message-ID- Унікальний ідентифікатор повідомлення. Унікальність значення цього поля гарантується програмним забезпеченням вузла відправника, тому воно генерується автоматично.
Date– поле "Дата". Містить дату надсилання повідомлення. Значення поля встановлюється автоматично поштовим клієнтом під час надсилання повідомлення.
від- поле "Від". Містить адресу, яку відправник повідомлення вказує як вихідну адресу.
Sender– поле "Відправник". Містить адресу, з якої було реально надіслано повідомлення. Це поле може бути відсутнім у заголовку, якщо поле "From" містить адресу реального відправника.
To– поле "Кому". Містить адресу основного одержувача повідомлення.
Cc– поле "Копія". Містить адреси додаткових отримувачів повідомлення.
Bcc– поле "Прихована копія". Містить адреси додаткових отримувачів повідомлення. Одержувачі, перелічені в полях "To" та "Cc", не знатимуть, що абоненти зі списку "Bcc" отримали копію повідомлення.
Reply-to– поле "Відповісти". Містить адресу, за якою одержувач повинен надсилати відповідь. Це поле є необов'язковим: у разі його відсутності відповіді надсилаються на адресу, вказану в полі "From".
Subject– поле "Тема повідомлення". У цьому полі зазвичай вказується короткий опис (тема) повідомлення.
Тіло повідомлення
Спочатку передбачалося, що повідомлення можуть містити тільки текст у форматі ASCII. А оскільки можливість передачі нетекстової інформації не передбачалася, протоколи передачі електронної пошти можуть некоректно обробляти такі повідомлення. У зв'язку з цим свого часу розробили спеціальний стандарт, визначальний принципи перетворення нетекстових даних до текстовому виду. Цей стандарт отримав назву MIME(Multipurpose Internet Mail Extension, багатоцільове розширення пошти Інтернет).
MIME передбачає, що у тілі повідомлення можуть передаватися такі види інформації:
текст – простий текст у форматі ASCII, а також текст у форматі RTF чи HTML;
графічні зображення – файли у форматі JPEG та GIF;
аудіо та відео дані;
дані у форматах різних програм, наприклад, документи Microsoft Office, а також дані довільного формату (у тому числі різні файли, що виконуються).
В одному поштовому повідомленні можуть бути надані дані різних типів. Такі повідомлення є структурою із загальним заголовком і кількома блоками всередині тіла, кожен з яких містить інформацію свого типу.
Це широко використовується при надсиланні повідомлень з вкладеннями(attachments) - додатковими "прикріпленими" файлами, які можуть містити різнорідну інформацію. Наприклад, до текстового повідомлення можна прикріпити графічний файл з фотографією відправника.
Крім того, це може бути корисним, коли текст повідомлення необхідно передати у різних форматах. Наприклад, відправлене повідомлення у форматі HTML, що містить будь-яке оформлення, може некоректно сприйматися клієнтською програмою одержувача. Щоб уникнути подібних проблем, поштовий клієнт відправника може сформувати альтернативне подання повідомлення у вигляді простого тексту.
Для забезпечення коректної передачі повідомлень з нетекстовими даними в MIME передбачено два алгоритми перекодування, що здійснюють перетворення таких даних до тестового вигляду:
алгоритм "Quoted-printable", призначений для заміни байтів, що не є ASCII-символами, на групу з трьох байт, що є лише стандартними символами;
алгоритм "Base64", який здійснює перетворення трьох довільних байт у чотири ASCII-символи.
Для коректної інтерпретації даних стандартом MIME в заголовок повідомлення вводяться додаткові спеціальні поля.
Content-type– поле "Тип вмісту". Відповідає за коректне визначення типу даних, які містяться у повідомленні заголовка повідомлення. Значення поля вказує на конкретний тип даних, або інформує, що тіло містить кілька різнотипних блоків.
Content-Transfer-Encoding– поле "Тип кодування вмісту". Визначає спосіб перетворення (перекодування) вихідних даних текстовий вигляд.
Відповідно до стандартів обміну електронними повідомленнями, листи підтримують деякі заголовки, кожен із яких має бути з нового рядка. За замовчуванням, у розсилнику вже прописані необхідні з них: MIME-Version, Content-Type, From, Reply-To, Subject, To. Записані в полі заголовків нові RFC email, будуть додані до наявних вищезазначених.
Врахуйте, що всі поштові агенти сприймають ці стандарти по-різному. Хоч і вказані в офіційних протоколах, вони можуть бути інгоровані або неправильно інтерпретовані, тому перед email розсилкою їх варто тестувати.
Популярні RFC заголовки листа
* - означає наприклад. Cc: (Carbon Copy) * Cc: [email protected]Цей заголовок є розширенням поля "To:", він вказує на додаткові одержувачі листа. Відмінностей між "To:" та "Cc:" по суті немає, якщо не вважати, що деякі поштові програми розглядають їх по-різному, генеруючи відповідь на повідомлення.Bcc: (Blind Carbon Copy) * Bcc: [email protected]
Якщо ви бачите цей заголовок в отриманому повідомленні, значить, щось не так. Цей заголовок використовується так само, як і "Cc:" (див. нижче), але не з'являється у списку заголовків. Основна ідея цього заголовка полягає у можливості надсилати копії листа людям, які не хочуть отримувати відповіді або з'являтися у заголовках. Сліпі копії дуже популярні серед спамерів, оскільки багато недосвідчених користувачів виявляються спантеличеними, отримавши лист, який начебто не був їм адресований.List-Unsubscribe: * List-Unsubscribe:
За описаним функціоналом поле має автоматично відписувати користувача, якщо він натиснув на кнопку "СПАМ", але часто під це поле виводиться окрема кнопка "Відписатися". Заголовок сприймається не всіма поштовими програмами, т.к. це чудова можливість перевірити email адреси на використовуваність.Priority: (X-MSMail-Priority: Importance:)* Priority: 1
Заголовок, що визначає пріоритет повідомлення. Іноді вказується, як X-Priority:, X-MSMail-Priority:, Importance:, приймає значення "Higt", "Normal", "Urgent", "Non-urgent" або для X-Priority "1", "3", "5". Більшість програм його ігнорують. Часто використовується спамерами з метою привернути увагу до повідомлення встановивши 1.Comments: * Comments: Люблю книги
Цей заголовок не стандартний, може містити будь-яку інформацію. Подібні заголовки додаються деякими поштовими програмами (зокрема популярною програмою Pegasus) для ідентифікації відправника, але часто прописується і вручну спамерами, так що ставитися до нього слід з обережністю.Organization: * Organization: ВАТ Костоправ
Абсолютно вільний заголовок, який зазвичай містить назву організації, через яку відправник повідомлення отримує доступ до мережі. Відправник, як правило, контролює цей заголовок, тому там цілком може бути щось на зразок "Королівська спільнота постановки одного над іншим".Precedence: * Precedence: bulk
Значення: "bulk", "junk", "list". Вказує приналежність листа до масової розсилки. Синоніми X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.List-Owner: * List-Owner:
Email адреса організатора масового розсилання.X-Mailer: * X-Mailer: ePochta Mailer Disposition-Notification-To: * Disposition-Notification-To: [email protected]
На вказані реквізити буде надіслано повідомлення про прочитання. Найчастіше ігнорується поштовиками з метою боротьби зі спамом. Синоніми: X-Confirm-Reading-To:, Return-Receipt-To:X-*** * X-List:, X-Mailer:, X-...
Як кажуть стандарти RFC, заголовки, що починаються на X - це власні заголовки окремих поштових програм, що носять інформативний характер. Але деякі приймаються повсюдно, наприклад, X-Mailer. Нічого, крім додаткової інформації у коді листа...
Вищенадана інформація носить інформативний характер. Це не означає, що вказівка якогось заголовка обов'язково виконається кожною поштовою програмою. Додаткову інформацію про заголовки можна отримати за
У загальному випадку схема обміну електронними повідомленнями (електронна пошта, e-mail) виглядає так
Як бачимо, у процесі обміну електронними повідомленнями використовуються не тільки технічні та програмні засоби відправника та одержувача, а й поштовісервери, завданням яких є прийом листів, призначених для відправки від відправника, доставка їх у Поштова скринькаодержувача, тимчасове зберігання та передача з поштової скриньки одержувачу.
Як один із елементів електронної пошти, поштова скринька є звичайним каталогом файлової системи (папку), а електронні листи – файли даних, що у даному каталозі. Звичайно, вся технологія прийому та передачі електронних листів підпорядковується певним правилам, що задаються протоколами та форматами даних. На стороні клієнта (відправника та одержувача) використовується спеціальне програмне забезпечення – поштовий клієнт, в якості якого можна використовувати, наприклад, Microsoft Outlook для Windows або Mozilla Thunderbird для Linux. Навіть якщо ви працюєте зі своєю поштовою скринькою через веб-інтерфейс (підключаючись до сайту, наприклад mail.ru), ви все одно використовуєте поштове клієнтське програмне забезпечення, що виконується в середовищі сервера. Поштові сервери та поштові клієнти, незалежно від того, на якому обладнанні, і з яким програмним забезпеченням, вони працюють, реалізують як мінімум два прикладні протоколи, без яких неможливий обмін поштою. Один із них служить для передачі електронних листів – це протокол SMTP(Simple Mail Transfer Protocol, простий протокол передачі пошти), другий служить прийому POP3(Post Office Protocol Ver 3, протокол поштового офісу). Обидва протоколи на прикладному рівні реалізовані як обміну текстовими повідомленнями в кодуванні ASCII, тобто. є телнетоподібними (telnet-like) протоколами. Так історично склалося з перших спроб обміну електронними повідомленнями у 1960-х роках. Відповідно, самі електронні листи теж не можуть містити ніяких службових (не відображуваних) символів. Навіть прикріплений до електронного листа бінарний файл перетворюється перед передачею в послідовність стандартних символів і при прийомі перекодується у вихідний вигляд. Як процес обміну даними, і структура електронних листів підпорядковуються суворо певним правилам, про які йтиметься нижче.
Відправник поштового повідомлення підключається до свого поштового сервера за допомогою протоколу прикладного рівня SMTPі передає йому дані, необхідні доставки відправлення кінцевому одержувачу, і власне, саме послання. Після цього сеанс обміну завершується. На наступному етапі доставки пошти (процес Mail Delivery), поштовий сервер відправника, використовуючи дані електронної адреси одержувача, знаходить його поштовий сервер, подібним чином підключається до нього і передає лист, який міститься в поштову скриньку одержувача. Структура адреси у вигляді [email protected] визначають:
user- ім'я користувача, воно ж - ім'я каталогу, який використовується як поштова скринька.
domain.ru- доменне ім'я "domain.ru", яким визначається поштовий сервер, на якому знаходиться ця поштова скринька. Для визначення поштових серверів, які обслуговують конкретні домени, використовується служба дозволу імен DNS.
[email protected]- Поштова скринька користувача "test" у домені mail.ru
Відповідно, коли відправник неправильно вкаже першу частину адреси або така поштова скринька відсутня, лист не може бути доставлений, і відправнику надсилається повідомлення про цей факт, що містить "Mailbox does not exist" (поштова скринька не існує):
SMTP error з remote mail server after RCPT TO: :
^nbsp host mx01.mail.ru : 550 Mailbox [email protected] does not exist.
Зазвичай повідомлення про помилки доставки електронної пошти надсилаються з темою:
Mail delivery failed: returning message to sender
Якщо помилково вказано частину адреси після знака @ , то повідомлення про помилку буде супроводжуватися текстом про те, що не знайдено домену (Domain . . . not found). Залежно від різновиду серверів та їх налаштувань текст повідомлень про помилки доставки може незначно відрізнятися.
Якщо ж помилок не виникло, одержувачу залишається лише підключитися до сервера з використанням свого поштового клієнта та за протоколом прикладного рівня POP3"забрати" з поштової скриньки послання, що знаходиться там.
Протокол SMTP був розроблений ще на початку 80-х років минулого століття (основні специфікації - RFC 821, RFC 822), однак, з деякими змінами і доповненнями, широко використовується досі і, очевидно, буде використовуватися в найближчі кілька років як основний протокол передачі електронних повідомлень. Останнє оновлення в 2008 р. RFC 5321 додало розширення протоколу - ESMTP(Extended SMTP). Однак у повсякденній термінології, як і раніше, використовується назва SMTP
При стандартному налаштуванні поштовий сервер очікує вхідні з'єднання на TCP порт 25 (слухає TCP порт 25). Клієнтська поштова програма здійснює підключення на даний порт, після чого поштовий сервер передає своє привітання, наприклад:
220 fcgp03.nicmail.ru ESMTP CommuniGate Pro 5.2.3.
Інформаційні та керуючі повідомлення, що видаються сервером, складаються з номера (числового ідентифікатора), в даному випадку - 220 (сервер готовий до роботи) та тексту, що пояснює. Дані, що передаються клієнтом, не мають номера і передаються у вигляді набору символів, що відображаються (звичайного тексту).
Для початку сесії, відповідно до специфікації протоколу SMTP, клієнт повинен повідомити своє локальне ім'я хоста з використанням директиви HELO. Замість HELO може бути використана (і в більшості поштових програм, використовується) директива EHLOу відповідь на яку сервер передає список підтримуваних ним команд протоколу SMTP
EHLO MyComp.Mydomain
Як аргумент директиви EHLO передається ім'я комп'ютера.
У відповіді сервера (ідентифікатор 250 - OK, виконано успішно) будуть перераховані команди протоколу SMTP, що підтримуються:
250-fcgp03.nicmail.ru domain name should be qualified MyComp.Mydomain
250-SIZE 31457280
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN
250-ETRN
250-TURN
250-ATRN
250-8BITMIME
250-HELP
250 EHLO
Список команд SMTP залежить від різновиду та конкретних параметрів сервера. У зв'язку з проблемою СПАМу, переважна більшість поштових серверів налаштовується лише на роботу з дозволом на підключення із заздалегідь відомих IP-адрес або авторизацією користувача. Тому поштова клієнтська програма видає директиву AUTH, яка вказує яку процедуру автентифікації користувача вона використовуватиме:
AUTH LOGIN
У цьому випадку буде використовуватися автентифікація користувача по імені та паролю. Після цього сервер видає повідомлення з номером 334 (виконання процедури аутентифікації):
334 VXNlcm5hbWU6
У прикладі SMTP-сесії, на даному етапі обмін даними між клієнтом і сервером виконується також у текстовому вигляді, але в кодуванні Base64. Дане кодування широко використовується в додатках електронної пошти для кодування бінарних даних – програм, фото, відео тощо. Весь діапазон елементів даних, що кодуються, може бути представлений набором символів англійського алфавіту, цифрами і деякими знаками. Для перекодування даних, найпростіше, скористатися онлайн-перекодувальником base64.ru. Для перекодування копіюємо рядок Base64 у верхнє вікно, і в нижньому отримуємо текст Username:
Рядок символів VXNlcm5hbWU6 - це Username:у кодуванні ASCII, тобто. запит імені користувача. Клієнтська програма також надсилає його у кодуванні Base64:
QmlsbEdhdGVzQG1pY3Jvc29mdC5jb20=
Подібним чином визначається, що рядок
334 UGFzc3dvcmQ6
означає запит пароля - Password:
На що клієнтська програма передає пароль, також у кодуванні Base64:
YXNkYXRh
Якщо пароль прийнято, сервер відповідає повідомленням із номером 235:
235 [email protected] authenticated
Якщо ім'я користувача або пароль не розпізнаються, сервер відповість кодом помилки з набору повідомлень з номерами 4ХХ, 5ХХ
MAIL FROM: [email protected]
Одним із серйозних недоліків протоколу SMTP є його слабкий захист від підробки поштових відправлень. Як у директиві HELOможна вказати будь-яку адресу хоста, так і в директиві MAIL FROMможна вказати будь-яку адресу відправника, наприклад,
Font MAIL FROM: [email protected]
Якщо поштова адреса відповідає формату user@domain, сервер видасть повідомлення з номером 250 (OK, все добре):
250 [email protected] sender accepted
(А клієнтська поштова програма одержувача саме цю адресу відобразить у прийнятому листі, тобто від Білла Гейтса з домену microsoft.com)
Отримавши від сервера підтвердження, що адреса прийнята, клієнтська програма передає адресу одержувача за допомогою директиви RCPT TO:
RCPT TO: [email protected]
Якщо адреса одержувача відповідає формату user@domainсервер відповість повідомленням про готовність прийняти поштове повідомлення для доставки 250:
250 [email protected] will relay mail for an authenticated user
DATA
На що сервер відповідає повідомленням із номером 354 ("почати введення тексту листа")
354 Enter mail, end with "." on a line by itself
У найпростішому випадку, лист може бути набором клавіатури, що вводяться, що відображаються символів ASCII, наприклад
Hello, World!
Ознакою кінця повідомлення є окремий рядок, що містить символ "крапка".
На що сервер видає повідомлення про прийняття до доставки введеного повідомлення:
250 message accepted for delivery
Після цього програма поштового клієнта завершує сесію:
У відповідь поштовий сервер повідомляє про закриття з'єднання:
221 fcgp03.nicmail.ru CommuniGate Pro SMTP closing connection
На початковому етапі використання протоколу SMTP, коли передавався лише простий текст, використовувався саме такий спосіб передачі листів, проте згодом виникла потреба створювати гарне оформлення відправлень, прикріплювати файли довільного формату, використовувати національні алфавіти тощо. Таким чином, на додаток до документа RFC 821був розроблений документ RFC 822, що стандартизує основний зміст повідомлень електронної пошти та документи RFC 2045і RFC 2046, що описують формат розширень MIME(Multipurpose Internet Mail Extensions – багатоцільове розширення електронної пошти), призначений для обробки складових та нестандартних повідомлень.
Формат електронного листа.
Відповідно до сучасних стандартів, повідомлення електронної пошти складається з 2-х частин - заголовкаі тіла. Заголовок листа формується поштовим програмним забезпеченням і складається з кількох рядків кодування ASCII. Заголовок містить службову інформацію, необхідну для доставки та опрацювання електронного послання. Кожне поле заголовка складається з назви, символу двокрапки та даних поля. Деякі поля заголовка мають фіксовану структуру, наприклад поле Від:(Адреса відправника), а деякі - довільну, як наприклад, поле Subject:(Тема листа).
Основні поля повідомлення:
Від:- адреса відправника
To:- адреса одержувача
Date:- дата відправки
Cc:- копія повідомлення надсилається на вказану адресу
Bc- прихована копія
Subject:- Тема повідомлення
Message-ID:- Ідентифікатор повідомлення, наданий поштовим ПЗ.
Reply-To:- адреса відповіді повідомлення.
Priority- Пріоритет (важливість) повідомлення
X-Mailer:- Поштова програма, за допомогою якої надіслано повідомлення.
Received:- поле з адресами та часом обробки повідомлення проміжними серверами під час доставки повідомлення адресату.
Мінімальний заголовок повідомлення повинен містити поля Від:, To:(або Cc:) та Date:. При доставці повідомлення кінцевому адресату до початкового заголовка листа можуть бути додані поля, сформовані проміжними поштовими серверами. Так, наприклад, при надсиланні повідомлення від користувача [email protected]користувачеві [email protected], лист відправляється клієнтським поштовим програмним забезпеченням на поштовий сервер, який обслуговує домен mail.ru, а потім пересилається ним поштовому серверу, який обслуговує домен rambler.ru, звідки воно буде прийнято користувачем поштової скриньки. [email protected]. Пересилання може складатися з кількох кроків та супроводжується додаванням полів проміжних серверів у заголовок повідомлення.
Про формат вмісту листа повідомляють поля:
MIME-Version:- Версія розширення MIME. Означає, що в цьому повідомленні використовується розширення MIME та вказується його версія.
Content-Type:- Тип вмісту. Визначає зміст повідомлення та алгоритм його обробки поштовим програмним забезпеченням (поштовим програмним забезпеченням). Так наприклад,
Content-Type:message/RFC-822- Вказує, що далі слідує повідомлення у форматі RFC-822, тобто. найпростіше текстове повідомлення без будь-яких розширень у кодуванні ASCII.
Content-Type: text/plain; charset="windows-1251"- повідомлення з послідовності символів у кодуванні, що визначається значенням параметра charset:(в даному випадку, у кодуванні Windows з кодовою сторінкою 1251)
Content-Type: text/html- використовується текст, розмічений із використанням тегів мови HTML.
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_008D_01CC0FEF.CCB47280"- Повідомлення складається з кількох частин різного змісту. Параметр boundaryзадає рядок – роздільник між окремими частинами.
Таким чином, поле Content-Type:може визначати тип вмісту (audio, video, image), який має бути перекодований під час обробки поштового повідомлення. Тип кодування вказується полем Content-Transfer-Encoding:. Якщо вказано типи 7bit, 8bitабо binary, то перекодування не використовується. Тип Base64вказує на те, що кодування даних виконано з використанням вищезазначеного кодування Base64. Досить часто зустрічається тип quoted-printable, призначений, як і Base64, для передачі символів, що не входять до складу відображуваної частини ASCII (англійського алфавіту, цифр та деяких знаків). Кожен символ перетворюється на послідовність із знака рівності = і двох символів, що задають шістнадцяткове значення коду символу, що перетворюється. Так, наприклад, велика російська буква Я, якій відповідає шістнадцяткове значення 0xDF у старшій частині таблиці символів, буде представлена як =DF, знак оклику - =21 і т.п. Правила кодування даних описані у документі RFC-1341
Як визначити підроблений електронний лист.
Напевно, немає жодного користувача електронної пошти, який не отримував би електронні послання від різного типу шахраїв, що маскуються під організаторів всіляких (безпрограшних для них) лотерей, адміністрацію сайтів, сервіси електронних платіжних систем тощо. За допомогою підроблених листів було зламано багато сторінок користувачів соціальних мереж, облікові записи користувачів електронної пошти, електронні гаманці тощо. А буває і навпаки, дійсні листи, які викликали необґрунтовані підозри, були проігноровані і відправлені в кошик. Адже достовірність електронного послання досить просто визначити, використовуючи звичайну логіку і інформацію, яку можна витягти з полів заголовка письма.
Прийнятий лист відображається поштовим клієнтським програмним забезпеченням у вигляді, зручному для перегляду без зайвої деталізації, проте, при необхідності, можна змінити подання даних повідомлення, та отримати можливість перегляду полів заголовка. Для поштового клієнта Microsoft Outlook Express (а також поштового клієнта Windows Mail та інших), наприклад, потрібно вибрати конкретний лист, викликати контекстне меню правою кнопкою мишки та вибрати пункт Властивостіабо натиснути комбінацію клавіш Alt+ENTER. Відкриється вікно властивостей повідомлення із вкладками "Загальні" та "Докладно" (у деяких клієнтах – "Загальні" та "Довідки")
При виборі режиму представлення "Докладно" у вікні властивостей повідомлення будуть відображатися заголовки листа і, крім того, з'явиться можливість перегляду в тому вигляді, в якому воно було прийнято від поштового сервера при натисканні на кнопку Вихідне повідомлення
Вихідний вигляд є заголовок листа, порожній рядок, і тіло листа.
В інших поштових програмах або веб-інтерфейсі поштових служб також є можливість перегляду заголовка, наприклад, при читанні листа через веб-інтерфейс поштової служби mail.ru, заголовок можна переглянути, натиснувши на іконку з написом RFC, що знаходиться в рядку клавіш над листом. У веб-інтерфейсі пошти Яндекса потрібно у верхньому правому кутку екрана натиснути на іконку Властивості листа. Назви кнопок можуть бути різними, але практично завжди існує можливість перегляду заголовка або повністю вихідного виду електронного листа.
Щоб переглянути заголовок електронного листа в поштовому клієнті Microsoft Outlook 2010, потрібно відкрити лист подвійним клацанням і вибрати в меню "Файл" - "Відомості" - кнопка "Властивості". Поля заголовка відображаються у вікні "Заголовки інтернету"
Для прикладу, розглянемо заголовки листа, як відправника в якому значилося "Microsoft Corporation" і з темою "You Won (View Attachment)" , де повідомлялося про великий виграш в електронній лотереї і пропонувалося для отримання заповнити анкету в приєднаному файлі. Начебто йдеться про виграш у лотереї, що проводиться корпорацією Майкрософт. Загалом зміст явно підозрілий, але в даному випадку це неважливо. Завдання полягає в тому, щоб отримати максимум достовірної інформації про відправника електронного листа.
У процесі доставки електронного листа, при пересиланні від вузла до вузла, програмні засоби по дорозі додають службову інформацію в заголовок, при чому, відправник не може якимось чином змінити ці дані. Найраніші за часом формування поля заголовка знаходяться в нижній частині, пізніші - у верхній. Поля, що починаються із символів X-, як правило, відносяться до програмного забезпечення, що використовується для надсилання електронного листа, його перевірки спам, віруси і т.п. Особливо корисних відомостей для визначення достовірності відправника повідомлення ці поля не містять, хоча можуть бути використані як додаткове джерело інформації. Наприклад, відправником відображається корпорація Microsoft, а для відправки використовується веб-пошта пошукової системи Yahoo, чого явно бути не може.
X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950
Поля From:, To: та Reply-To: також говорять про підробленість листа.
Від: Microsoft Corporation
Ім'я відправника "Microsoft Corporation", що виводиться, а поштова адреса " [email protected]" (Реально присутні в повідомленні адреси я змінив, зберігши структуру). В адресах електронної пошти використовується формат
user@domain- Ім'я користувачазнак @ ім'я домену. Ім'я користувача (ім'я поштової скриньки) у цьому випадку - microsoft491, а ім'я домену - gmail.com, тобто. - це безкоштовна поштова скринька в домені Google. Чи не так, це дивно, коли велика організація для офіційного листування використовує публічну безкоштовну пошту? Ім'я користувача можна завести будь-яке, якщо воно вільне, і відповідає правилам поштового сервісу, а ім'я, що відображається, не має відношення до реальної поштової адреси. Дуже часто шахраї використовують формат поштової адреси як ім'я відправника, що відображається, і замість "Microsoft Corporation" може бути присутнім, наприклад " [email protected]", якому буде відповідати реальна адреса" [email protected]", який явно не має жодного відношення до корпорації Microsoft".
Чи має домен з адреси відправника якесь відношення до Microsoft або будь-якої іншої організації, можна перевірити з використанням спеціального програмного забезпечення, як безкоштовна утиліта або з використанням онлайн-сервісів Whois (на сайті 2ip.ru, наприклад), що дозволяють отримати реальні відомості про доменне ім'я.
Інформація про домен часто дає додаткові ознаки, які можуть допомогти у визначенні достовірності електронного листа. Особливо це стосується тих випадків, коли використовується адреса з ім'ям домену, дуже близька до найменування офіційних організацій. Днями по російському сегменту Інтернет пройшло шахрайське розсилання від імені, нібито Роскомнагляду, roskomnadzor.org. У таких випадках варто звернути увагу на вік домену. Як правило, доменні імена, які використовуються для шахрайства в Інтернеті, мають вік від кількох днів до кількох тижнів. Крім того, інформація про реєстратора, дані технічних та адміністративних контактів можуть дати відомості, на підставі яких можна зробити висновки про достовірність відправника. Насправді найчастіше виявляється, що реєстратор доменного імені для держустанови - приватна особа, а зазначені контакти не мають жодного відношення до цієї організації або навіть до цієї країни.
Наступне поле, на яке слід звернути увагу
Message-ID: 306099.58326.qm @ web83802.mail.sp1.yahoo.com
Це внутрішній ідентифікатор повідомлення, який надається поштовою системою, ім'я якої розташовується після символу @ . Якщо ви отримали, нібито листа від Microsoft або адміністрації Яндекса, а в імені поштової системи присутній yahoo.com, можна однозначно зробити висновок, що таке лист - підробка. Але це ще не все. Наступне (знизу догори) поле, Received:було сформовано першим у ланцюжку доставки поштовим сервером і дає нам адресу (адресу змінено мною), з якої було надіслано листа
Received: from by web83802.mail.sp1.yahoo.com via HTTP;
З великою ймовірністю можна припустити, що це, як мінімум адреса з пулу адрес Інтернет - провайдера відправника або шлюзу мережі поштової служби. Додам, що в більшості випадків у мережах провайдерів клієнтам виділяються динамічні IP-адреси і, так звані, "сірі" IP, коли вихід в Інтернет виконується з використанням технології NAT (Network Address Translation) та як IP у полі Received: буде адреса шлюзу , через який здійснюється вихід в Інтернет із внутрішньої мережі провайдера. Для отримання інформації про IP-адресу можна скористатися тим самим Win32Whois. Замість імені домену заносимо у поле DOMAINцікавить нас IP-адреса
Аналіз адреси може дати інформацію, наприклад, що лист від нібито Microsoft був відправлений з мережі польського або новозеландського провайдера, а офіційний лист Федеральної служби Росії відправлений з Канади.
Як бачимо, нічого складного. Достатньо мати навіть загальні відомості про принципи обміну електронною поштою та мати уявлення про формати листів, щоб визначити підроблене відправлення та не потрапити на гачок інтернет-шахраїв.
Будь-який e-mail у своїй основі має однакову будову. Формат поштового повідомлення У Мережі визначено в RFC-822 (Standard for ARPA Internet Text Message, опублікований в 1982 р.). Поштове повідомлення складається з трьох частин: конверта (envelope), заголовків (headers) та тіла повідомлення (body). Користувачеві доступні лише заголовки (headers) та тіло (body) повідомлення. Конверт використовується програмами доставки (для передачі повідомлення від сервера на сервер). RFC-822 регламентує зміст заголовка повідомлення. Заголовок завжди знаходиться перед тілом повідомлення, відокремлений від нього порожнім рядком і складається з полів (ім'я та зміст). Ім'я поля відокремлено від змісту символом ":".Мінімально необхідними є такі поля Date:«, » Від:«, » Cc:"і/або" To:", наприклад:
Від: [email protected]
Від: [email protected]
Від: [email protected]
де " Date:«, » Від:«, » Cc:"і" To:є іменами заголовка, а через пробіл навпроти кожного імені заголовка вказано відповідний зміст. Визначимо значення кожного вказаного імені заголовка:
Поле "Date:" виставляється комп'ютером відправника, на якому може бути неправильно встановлена дата та час
Date:— призначення даного заголовка очевидне: він вказує дату та час відправлення листа (з прикладів "Fri, 6 Dec 2002 23:26:50 +0300 (MSK/MSD)" видно, що листа було відправлено 6 грудня 2002 року о 23:26: 50 за московським часом). Якщо цей заголовок не було створено на комп'ютері відправника, то, можливо, його додасть поштовий сервер або інший комп'ютер, через який пройде лист. Його в жодному разі не можна приймати за незаперечну істину, і справа навіть не в можливості підробки - у світі жахливо велика кількість комп'ютерів з годинами, що неправильно йдуть;Від:- Вказує адресу відправника (у прикладі ми бачимо, що лист був відправлений з адреси [email protected]);
To:— адреса(а) одержувача(ів) (одержувачем у нашому прикладі є [email protected]). Зазначимо, що поле " To:не повинно містити адресу одержувача, а також може містити адреси кількох одержувачів;
Cc:(Carbon Copy) — адресація копій, цей заголовок є розширенням поля To, він вказує додаткових одержувачів листа (одержувач To бачить список всіх Cc). Відмінностей між заголовками "To" і "Cc", по суті, немає, якщо не вважати, що деякі поштові програми розглядають їх по-різному, генеруючи відповідь на повідомлення. У прикладі № 1 поля Cc немає, тобто листа було відправлено єдиному одержувачу [email protected]. З прикладу № 2 видно, що цей заголовок належить адресату [email protected], якому надіслано копію листа (він не бачить поле To). Приклад № 3 показує, що листа було надіслано одержувачу листа [email protected], а також копію листа було надіслано на скриньку [email protected].
Але це лише основні поля заголовка. Зазвичай заголовок містить значно більше полів, ніж зазначено вище. Давайте з ними ознайомимося...
Поле "Received:" - штамп проходження листа через поштовий сервер
Received:- "штамп" проходження листа через поштовий сервер. Заголовки "Received:" надають докладну інформацію про життя повідомлення та не дадуть обдурити одержувача повідомлення, звідки саме надійшов лист. Якщо, наприклад, машина turmeric.com, IP-адреса якої 104.128.23.115, надсилає повідомлення машині mail.bieberdorf.edu, але намагається її обдурити, сказавши HELO galangal.org, заголовок "Received:" вийде наступним: Received: from manaraga. org (turmeric.com) by mail.bieberdorf.edu...(залишок рядка опущений для ясності). Тут підробка одразу виводиться на чисту воду. Цей рядок каже: "машина turmeric.com, чия адреса 104.128.23.115, назвалася galangal.org". Ми розглянули лише один приклад, що наочно представляє потрібність і корисність даного заголовка листа, у зв'язку з тим, що метою цієї статті не є докладне вивчення кожного заголовка, а лише ознайомлення з найчастіше зустрічаються у звичайному житті. Тим більше, що про заголовок "Received:" можна написати окрему статтю.Message-Id:— унікальний ідентифікатор листа, який надається кожному повідомленню, — найчастіше першим поштовим сервером, який зустрінеться у нього на шляху, або ж поштовим клієнтом. Зазвичай він має форму. [email protected], де "abrakadabra" набір довільних символів, а друга частина "domain.ru" - ім'я машини, що привласнила ідентифікатор. Іноді, але рідко, «abrakadabra» включає ім'я відправника. Message-Id використовується програмами доставки пошти, щоб уникнути "зациклювання" листа;
Поле "Bcc" - прихована копія
Bcc:(Blind Carbon Copy) — сліпа/прихована копія (одержувачі не підозрюють про інших одержувачів з поля Bcc). Приховані копії дуже популярні серед спамерів, оскільки багато недосвідчених користувачів виявляються спантеличеними, отримавши лист, який, начебто, не був їм адресований;Subject:- Тема листа (наявність Re: означає відповідь; Fwd: - Переадресацію). Поштовий стандарт допускає наявність лише латинських символів (US-ASCII) у полі «Subject» тому, незважаючи на те, що багато користувачів заповнюють це поле російською мовою, цього робити не рекомендується. Нормальна ситуація — коли написана російською тема листа при відправці перекодується поштовою програмою відправника в 7-бітну base64 із зазначенням мовного кодування, в якій ця тема написана (як це роблять програми Pine, Pegasus Mail), а поштова програма одержувача декодує тему листа вид, що читається. Однак це поштовий стандарт MIME, який програма UUPC не підтримує;
Reply-To:- адреса для відповідей. Незважаючи на те, що цей заголовок має безліч способів цивілізованого застосування, він також використовують спамери для відведення удару від себе. Можливо, якийсь наївний спамер і захоче збирати відповіді на свої листи і вкаже вірний заголовок "Reply-to:", але більшість вказує там або неіснуючу адресу, або адресу невинної жертви;
In-Reply-To:- Вказує, що повідомлення відноситься до типу "відповідь на відповідь";
Comments:- означає коментар. Цей заголовок не є стандартним, тому може містити будь-яку інформацію. Подібні заголовки додаються деякими поштовими програмами (зокрема популярною програмою Pegasus) для ідентифікації відправника, але часто прописується вручну спамерами, так що ставитися до нього слід з обережністю;
Status:- статус листа (нове, прочитане);
Apparently-To:— ці заголовки нетипові для нормальних повідомлень, зазвичай є ознакою масової розсилки. Останнім часом для масових розсилок використовується програмне забезпечення досить "розумне", щоб не плодити гігантські списки з цих заголовків;
Organization:— абсолютно вільний заголовок, який зазвичай містить назву організації, через яку відправник повідомлення отримує доступ до мережі. Відправник, як правило, контролює цей заголовок, тому там цілком може бути щось на зразок ЗАТ "Роги та Копита";
Priority:- Виключно вільний заголовок, що встановлює пріоритет повідомлення. Більшість програм його ігнорують. Часто використовується спамерами у формі "Priority: urgent" (або щось у цьому роді) з метою привернення уваги до повідомлення;
Errors-To:— вказує адресу для надсилання повідомлень про помилку, що автоматично генеруються, таких як "немає такого користувача". Це рідко використовується заголовок, так як більшість відправників зазвичай хочуть отримувати повідомлення про помилки на вихідну адресу, яка використовується поштовими серверами за промовчанням.
Специфікація RFC-822 сильно застаріла
Розглянуті нами вище заголовки регламентуються RFC-822, як було зазначено вище. З часу використання стандарту RFC-822 виявився ряд обмежень, що помітно урізають потреби користувача. Зокрема, можливість пересилання нетекстових даних, наприклад, аудіо та графіки - дана можливість просто не була згадана в RFC-822, що описує лише формат текстових повідомлень. І навіть у випадку текстового повідомлення стандарт RFC-822 обійшов увагою потреби користувачів, які використовують розширений набір символів, що характерно для азіатських та більшості європейських мов. Основне обмеження RFC-822 – відносно короткі рядки та 7-бітна символьна таблиця. Користувачам для надсилання нетекстових даних доводилося конвертувати тіло свого листа в 7-бітну форму за допомогою UUENCODE, BINHEX та аналогів. Стало зрозуміло, що була потрібна нова, додаткова специфікація, і вона була розроблена - MIME - Multipurpose Internet Mail Extension (RFC-1314). Про цю специфікацію ми поговоримо в окремій статті.
Заголовок повідомлення електронної пошти Інтернету надає список технічні відомості про повідомлення, наприклад, хто надіслав воно створено і які сервери електронної пошти, які його проходження через на шляху до отримувача програмне забезпечення. У більшості випадків лише адміністратор повинен переглянути заголовки Інтернету для повідомлення. Якщо ви бажаєте додати заголовок до повідомлення електронної пошти, перегляньте статтю застосування теми, колір фону або бланка для повідомлень електронної пошти.
Перегляд заголовків повідомлень Інтернету
В Outlook для Office 365, 2016, 2013 або 2010 на комп'ютері
Двічі клацніть повідомлення електронної пошти, щоб відкрити його за межами області читання.
Виберіть файл> властивості.
Відомості заголовка будуть відображені у полі Заголовки Інтернету.
Порада: виділяти відомості в цьому полі, натисніть клавіші Ctrl+C, щоб скопіювати та вставте в Блокнот або Word, щоб побачити весь верхній одночасно.
Вміст заголовків повідомлень електронної пошти
Розглянемо листування електронною поштою між двома користувачами: Сергієм Зайцевим та Ольгою Зуєвою. Адреса електронної пошти Сергія: [email protected], адреса Ольги - [email protected]. Ольга використовує Microsoft Office Outlook 2007. Заголовок Інтернету з листа Ольги Сергію виглядає так:
Microsoft Mail Internet Headers Version 2.0Received: від mail.litwareinc.com by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0);Wed, 12 Dec 2007 13:38:49 -0800From: "Kelly J. Weadock"
Коли Ольга надсилає повідомлення на адресу [email protected]Вона створює його на своєму комп'ютері, який визначається як (i101-177.nv.litwareinc.com ). Текст повідомлення передається з комп'ютера на сервер електронної пошти mail.litwareinc.com. Більше Ольга не побачить свого повідомлення – подальша обробка виконується поштовими серверами без її участі. Коли поштовий сервер Ольги отримає повідомлення, надіслане на адресу [email protected]Він зв'яжеться з поштовим сервером компанії Proseware і доставить на нього повідомлення. Воно буде зберігатись на сервері proseware.com доти, доки Сергій не перевірить свою робочу пошту.
Інтерпретація заголовки повідомлень електронної пошти
Нижче наведено опис стандартних полів заголовків електронних листів.
Microsoft Mail Internet Headers Version 2.0
Цей заголовок додається до Outlook.
Завантажено: from mail.litwareinc.com () by mail.proseware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:39:22 -0800
Ця інформація зазначено, що сталося передачі повідомлення на вівторок, 12 грудня 2017 р., о 13:39:22 (1: США) стандартному тихоокеанському часу (це на 8 годин пізніше, ніж за Грінвічем (за Грінвічем); таким чином «– 0800»).
Надіслано: від mail ( RDNS failed) by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:38:49 -0800
Ця передача відбулася у Вівторок, 12 грудня 2017 р., о 13:38:49 (1: за) стандартного тихоокеанського часу (це на 8 годин пізніше, ніж за Гринвічем (UTC); таким чином «– 0800»).
Від: "Kelly J. Weadock"
Повідомлення надіслала Ольга Зуєва з адреси електронної пошти [email protected].
To:
Отримувач повідомлення.
Cc:
Отримувачі копій повідомлення.
Примітка:Одержувачі прихованих копій (СК) у заголовку не вказуються.
Subject: Review of staff assignments
Тема електронної пошти.
Дата та час надсилання повідомлення електронної пошти по годинниках комп'ютера відправника.
MIME-Version: 1.0
Версія протоколу MIME, використана відправником.
Content-Type: multipart/mixed;
Додатковий заголовок MIME. Він призначений для MIME-сумісних поштових програм і вказує, який тип вмісту слід очікувати у повідомленні.
X-Mailer: Microsoft Office Outlook, Build 12.0.4210
Повідомлення надіслано за допомогою Microsoft Office Outlook, версія збірки 12.0.4210.
X-MimeOLE: Виробництво Microsoft MimeOLE V6.00.2800.1165
Поштова програма (програмне забезпечення MIME OLE), використана відправником.
Thread-Index: AcON3CInEwkfLOQsQGeK8VCv3M+ipA==
Цей заголовок використовується для поєднання кількох повідомлень в один потік. Наприклад, у Microsoft Outlook ці відомості можуть бути використані в поданні розмови для пошуку повідомлень у межах одного потоку розмови.
Return-Path: [email protected]
Адреса відправника повідомлення.
Message-ID:
Номер, наданий повідомленню сервером mail.litware.com з метою ідентифікації. Цей ідентифікатор завжди супроводжуватиме повідомлення.
Мітка часу, яка додається до повідомлення при першому проходженні через сервер Microsoft Exchange.
