Протокол SMTP та поштові протоколи

Архітектура системи електронної пошти

Електронна пошта є однією з найстаріших та найстабільніших розподілених систем Інтернету, що працює з 1971 року. На відміну від миттєвих месенджерів з прямим з'єднанням, email побудовано на принципі асинхронної доставки через ланцюжок посередників — поштових серверів, що пересилають повідомлення між відправником і одержувачем.

Компоненти email-інфраструктури

Система електронної пошти складається з кількох функціональних компонентів, кожен з яких відповідає за окремий етап життєвого циклу повідомлення:

MUA (Mail User Agent) — Поштовий клієнт

Програма або вебінтерфейс, за допомогою яких користувач створює, відправляє та читає електронну пошту. MUA взаємодіє з поштовими серверами через протоколи SMTP (для відправки) та POP3/IMAP (для отримання).

Приклади: Mozilla Thunderbird, Microsoft Outlook, Apple Mail, Gmail Web, ProtonMail.

MSA (Mail Submission Agent) — Агент прийому пошти

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

MTA (Mail Transfer Agent) — Поштовий сервер-ретранслятор

Основний компонент, що передає листи між доменами через протокол SMTP. MTA приймає повідомлення від MSA або інших MTA, визначає MX-запис (DNS) для домену одержувача і пересилає лист до відповідного поштового сервера.

Приклади: Postfix (найпопулярніший на Linux), Exim, Microsoft Exchange Server.

MDA (Mail Delivery Agent) — Агент локальної доставки

Компонент, що приймає повідомлення від MTA і зберігає його у поштовій скриньці користувача на сервері (зазвичай у форматі Maildir — кожен лист як окремий файл).

Приклади: Dovecot LDA, Procmail, Maildrop.

Mailbox — Поштова скринька

Місце зберігання повідомлень на сервері. Користувач отримує доступ до неї через протоколи POP3 або IMAP.

Шлях повідомлення від відправника до одержувача

Розглянемо повний життєвий цикл email від alice@example.com до bob@university.edu:

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
autonumber

actor "Alice" as Alice #DBEAFE
participant "MUA\n(Thunderbird)" as MUA #E2E8F0
participant "MSA\nexample.com:587" as MSA #FEF3C7
participant "MTA\nexample.com" as MTA_Sender #DCFCE7
participant "DNS" as DNS #E0E7FF
participant "MTA\nuniversity.edu:25" as MTA_Receiver #DCFCE7
participant "MDA" as MDA #FEF3C7
database "Mailbox\nbob@university.edu" as Mailbox #E2E8F0
participant "IMAP Server\n:993" as IMAP #FEF3C7
actor "Bob" as Bob #DBEAFE

Alice -> MUA : Написати лист для bob@university.edu
MUA -> MSA : SMTP submission (AUTH LOGIN, STARTTLS)
note right #FEF3C7
  Автентифікація обов'язкова.
  Порт 587, TLS-шифрування.
end note

MSA -> MTA_Sender : Передати для обробки
MTA_Sender -> DNS : MX запит для university.edu?
DNS -> MTA_Sender : MX 10 mail.university.edu

MTA_Sender -> MTA_Receiver : SMTP (порт 25, opportunistic TLS)
note right #E0E7FF
  MTA ↔ MTA без автентифікації,
  але з STARTTLS для шифрування.
end note

MTA_Receiver -> MDA : Локальна доставка
MDA -> Mailbox : Зберегти у Maildir/

Bob -> IMAP : З'єднатися (порт 993, TLS)
IMAP -> Mailbox : SELECT INBOX, FETCH нові
Mailbox -> IMAP : Повернути повідомлення
IMAP -> Bob : Відобразити лист від Alice

@enduml

Ключові етапи:

1. MUA → MSA (порт 587): Alice пише лист у Thunderbird, який надсилає його на MSA через автентифіковане SMTP-з'єднання з TLS-шифруванням.
2. MSA → MTA: MSA перевіряє автентифікацію та передає лист власному MTA для обробки.
3. DNS MX запит: MTA виконує DNS-запит для визначення поштового сервера домену university.edu (результат: mail.university.edu).
4. MTA → MTA (порт 25): MTA відправника підключається до MTA одержувача і передає лист через SMTP без автентифікації (відкрита ретрансляція між серверами).
5. MTA → MDA → Mailbox: MTA одержувача передає лист MDA, який зберігає його у поштовій скриньці Bob.
6. IMAP-доступ: Bob підключається до IMAP-сервера і завантажує новий лист через зашифроване з'єднання.

Протокол SMTP (Simple Mail Transfer Protocol)

SMTP — це текстовий протокол прикладного рівня для передачі електронних повідомлень, що працює поверх TCP на порту 25 (між MTA) або 587 (submission від клієнтів до MSA). Протокол визначено у RFC 5321 (2008, оновлення RFC 821 від 1982).

Характеристики SMTP

1. Текстовий протокол: Команди та відповіді передаються у форматі ASCII, що дозволяє тестувати протокол вручну через telnet або openssl s_client.

2. Push-модель: SMTP є push-протоколом — відправник активно передає повідомлення серверу одержувача, на відміну від pull-протоколів (POP3/IMAP), де клієнт запитує дані у сервера.

3. ESMTP (Extended SMTP): Сучасні сервери підтримують розширення, що оголошуються через команду EHLO замість застарілої HELO: STARTTLS (шифрування), AUTH (автентифікація), 8BITMIME (UTF-8), PIPELINING (пакетна передача команд).

Основні команди SMTP

EHLO (Extended Hello)

Ідентифікація клієнта та запит списку підтримуваних розширень:

C: EHLO client.example.org
S: 250-mail.example.com
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 8BITMIME

MAIL FROM

Вказує адресу відправника (envelope sender):

C: MAIL FROM:<alice@example.com>
S: 250 OK

RCPT TO

Вказує адресу одержувача (можна кілька разів для кількох одержувачів):

C: RCPT TO:<bob@university.edu>
S: 250 OK

DATA

Початок передачі вмісту повідомлення (заголовки + тіло). Закінчення позначається рядком з однією крапкою (.):

C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Test
C: From: alice@example.com
C: To: bob@university.edu
C:
C: This is the message body.
C: .
S: 250 Message accepted for delivery

QUIT

Завершення SMTP-сесії:

C: QUIT
S: 221 Bye

STARTTLS

Перехід до шифрованого з'єднання:

C: STARTTLS
S: 220 Ready to start TLS
(TLS handshake)

Коди відповідей SMTP

SMTP використовує тризначні числові коди, аналогічно до HTTP:

Правило: Коди 4xx означають transient error (MTA автоматично повторить спробу через кілька хвилин/годин). Коди 5xx означають permanent error (лист не може бути доставлено, генерується bounce message).

Формат електронних повідомлень

Електронне повідомлення складається з заголовків (headers) та тіла (body), розділених порожнім рядком. Формат визначено у RFC 5322.

Структура повідомлення

From: Alice Smith <alice@example.com>
To: bob@university.edu
Subject: Meeting tomorrow
Date: Sat, 29 Aug 2026 10:30:00 +0200
Message-ID: <abc123@example.com>
Content-Type: text/plain; charset=utf-8

Hello Bob,

Let's meet tomorrow at 10 AM.

Best regards,
Alice

Ключові заголовки

Обов'язкові:

• From: — адреса відправника (може відрізнятися від SMTP MAIL FROM)
• To: — адреса одержувача
• Subject: — тема листа
• Date: — дата створення у форматі RFC 5322 (Day, DD Mon YYYY HH:MM:SS +ZZZZ)
• Message-ID: — унікальний ідентифікатор повідомлення

Додаткові:

• Cc: (Carbon Copy) — копія для інших одержувачів (всі бачать список)
• Bcc: (Blind Carbon Copy) — прихована копія (видаляється MTA перед доставкою)
• Reply-To: — адреса для відповіді (якщо відрізняється від From:)
• Received: — ланцюжок серверів, через які пройшов лист (додається кожним MTA)
• Return-Path: — адреса для bounce messages (додається при доставці)

Приклад заголовків Received (читати знизу вгору):

Received: from mail.example.com (mail.example.com [93.184.216.34])
    by mail.university.edu (Postfix) with ESMTPS id ABC123
    for <bob@university.edu>; Sat, 29 Aug 2026 10:31:05 +0200
Received: from client.example.org (client.example.org [192.0.2.100])
    by mail.example.com (Postfix) with ESMTPSA id XYZ789
    for <bob@university.edu>; Sat, 29 Aug 2026 10:30:00 +0200

Перший Received (внизу) — відправник, останній (вгорі) — одержувач. Різниця у часових мітках показує затримки між серверами.

MIME (Multipurpose Internet Mail Extensions)

Оригінальний email підтримував лише 7-бітний ASCII-текст. MIME розширює можливості:

MIME-заголовки:

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.pdf"

Multipart повідомлення:

Для листів з HTML + текстова версія або вкладеннями:

Content-Type: multipart/alternative; boundary="----=_Part_123"

------=_Part_123
Content-Type: text/plain; charset=utf-8

This is the plain text version.

------=_Part_123
Content-Type: text/html; charset=utf-8

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

------=_Part_123--

Поштовий клієнт показує HTML-версію, якщо підтримує HTML, інакше — текстову.

POP3 та IMAP: протоколи отримання пошти

POP3 (Post Office Protocol v3)

POP3 реалізує модель «завантажити та видалити» (download and delete):

1. З'єднання з сервером (порт 110 або 995 для POP3S)
2. Автентифікація (USER bob, PASS secretpassword)
3. Завантажити всі листи з сервера
4. Видалити листи з сервера (опціонально)
5. Закрити з'єднання

Основні команди:

C: USER bob
S: +OK
C: PASS secretpassword
S: +OK Logged in
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <email content>
S: .
C: DELE 1
S: +OK message 1 deleted
C: QUIT
S: +OK Bye

Обмеження POP3:

• Немає синхронізації між пристроями (листи завантажуються на один пристрій і видаляються з сервера).
• Немає підтримки папок, міток, категорій.
• Неможливо позначити лист як прочитаний на сервері або переміщувати між папками.

IMAP (Internet Message Access Protocol)

IMAP реалізує модель «пошта залишається на сервері» (mail stays on server):

1. З'єднання (порт 143 або 993 для IMAPS)
2. Автентифікація
3. Вибрати папку (INBOX, Sent, Drafts)
4. Завантажити метадані (заголовки, розмір)
5. Завантажити тіло при відкритті листа
6. Синхронізувати зміни (прочитано, видалено)
7. З'єднання може залишатися відкритим (IDLE для push-нотифікацій)

Основні команди:

C: A001 LOGIN bob secretpassword
S: A001 OK LOGIN completed
C: A002 SELECT INBOX
S: * 42 EXISTS
S: * 0 RECENT
S: A002 OK [READ-WRITE] SELECT completed
C: A003 FETCH 1:10 (FLAGS ENVELOPE RFC822.SIZE)
S: * 1 FETCH (FLAGS (\Seen) ENVELOPE (...) RFC822.SIZE 1234)
S: A003 OK FETCH completed
C: A004 STORE 1 +FLAGS (\Seen)
S: * 1 FETCH (FLAGS (\Seen))
S: A004 OK STORE completed
C: A005 IDLE
S: + idling
... (push-нотифікації про нові листи) ...
C: DONE
S: A005 OK IDLE terminated

Переваги IMAP:

• Повна синхронізація між усіма пристроями (зміни відображаються скрізь).
• Підтримка папок, підпапок, міток, прапорців.
• Економія трафіку (завантажуються лише заголовки, тіло за запитом).
• Push-нотифікації через команду IDLE (миттєва доставка без polling).
• Пошук на сервері (SEARCH FROM "alice@example.com" SINCE 1-Aug-2026).

Безпека електронної пошти

Традиційний email має три критичні проблеми безпеки: відсутність шифрування, відсутність автентифікації відправника та відсутність гарантій цілісності. Розглянемо сучасні механізми захисту.

TLS-шифрування (STARTTLS)

Порти з TLS:

• SMTP submission (MUA → MSA): 587 з STARTTLS або 465 з SSL/TLS (SMTPS)
• SMTP relay (MTA → MTA): 25 з opportunistic STARTTLS
• POP3S: 995
• IMAPS: 993

Opportunistic vs Mandatory TLS:

Opportunistic TLS (порт 25): якщо обидва сервери підтримують — шифрується, якщо ні — передається відкритим текстом. Вразливий до downgrade-атак (атакуючий блокує STARTTLS).

Mandatory TLS (порти 465, 587, 993, 995): TLS обов'язковий, якщо недоступний — з'єднання відхиляється. Безпечніше, але несумісно зі старими серверами.

MTA-STS (Mail Transfer Agent Strict Transport Security): Новий стандарт, що змушує використовувати TLS між MTA через політику, опубліковану через HTTPS.

SPF (Sender Policy Framework)

SPF — механізм перевірки, чи дозволено IP-адресі надсилати пошту від імені домену.

Проблема: Будь-хто може вказати довільний MAIL FROM у SMTP.

Рішення: Домен публікує SPF-запис у DNS:

example.com.    IN    TXT    "v=spf1 ip4:93.184.216.0/24 include:_spf.google.com ~all"

Механізм:

1. MTA одержувача отримує лист з MAIL FROM:<alice@example.com>
2. Виконує DNS-запит: TXT example.com
3. Перевіряє, чи IP відправника належить до дозволеного діапазону
4. Результат: Pass, Fail, Soft Fail, Neutral

Обмеження: SPF перевіряє тільки MAIL FROM (envelope sender), а не заголовок From:, який бачить користувач.

DKIM (DomainKeys Identified Mail)

DKIM — механізм цифрового підпису email для гарантування автентичності та цілісності.

Як працює:

1. Відправник генерує пару ключів (приватний/публічний)
2. Публічний ключ публікується у DNS: default._domainkey.example.com TXT
3. MTA підписує повідомлення приватним ключем
4. Підпис додається у заголовок DKIM-Signature
5. MTA одержувача завантажує публічний ключ з DNS і перевіряє підпис

Приклад DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=default;
    h=from:to:subject:date;
    b=XYZ789...

Переваги:

• Гарантує, що лист надіслано саме з домену example.com
• Гарантує цілісність (повідомлення не змінено)
• Працює з заголовком From:, на відміну від SPF

DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC — політика, що вказує, що робити з листами, які не пройшли SPF або DKIM.

Приклад DMARC-запису:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

Поля:

• p=quarantine — політика: none (моніторинг), quarantine (спам), reject (відхилити)
• rua=mailto:... — адреса для агрегованих звітів
• pct=100 — відсоток листів, до яких застосовувати політику

Послідовність впровадження:

1. Налаштувати SPF (дозволити легітимні IP)
2. Налаштувати DKIM (підписувати листи)
3. Налаштувати DMARC з p=none (моніторинг)
4. Аналізувати звіти кілька тижнів
5. Змінити на p=quarantine
6. Через кілька місяців → p=reject

Питання для самоперевірки

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Content-Type: application/pdf; name="document.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.pdf"

Content-Type: multipart/alternative; boundary="----=_Part_123"

------=_Part_123
Content-Type: text/plain
Plain text version

------=_Part_123
Content-Type: text/html
<p>HTML version</p>
------=_Part_123--

Підсумок

Електронна пошта є фундаментальною розподіленою системою асинхронної комунікації, що працює через ланцюжок спеціалізованих серверів та протоколів. Розуміння її архітектури критично важливе для розробки вебзастосунків з email-нотифікаціями, інтеграції поштових серверів та діагностики проблем доставки.

Практичні висновки:

• Для вебзастосунків використовувати email API (SendGrid, Mailgun, AWS SES) замість власного SMTP-сервера.
• Налаштовувати SPF, DKIM, DMARC для запобігання підміні домену та покращення deliverability.
• Використовувати IMAP для багатопристроїних сценаріїв, POP3 тільки для специфічних випадків.
• Завжди використовувати TLS-шифрування (STARTTLS на порту 587 для submission).
• Аналізувати заголовки Received та Authentication-Results для діагностики проблем доставки.