SMTP: разговорът между пощенските сървъри

Модул 1: Как работи имейлът · Време за четене: 10 минути

Учебна цел: След този урок ще можете да четете SMTP разговор, да обясните какво правят EHLO, MAIL FROM, RCPT TO и DATA, и да разпознаете по код за отговор дали дадена грешка е временна или окончателна.

Основни понятия: SMTP (RFC 5321), сесия, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, код за отговор (2xx, 3xx, 4xx, 5xx), разширен код за състояние, разширения (STARTTLS, AUTH, SIZE), null MX

Разговор на обикновен текст

SMTP е много стар протокол (първата версия е от 1982 г.) и затова е много четим. Два сървъра си изпращат редове текст. Подателят (клиентът) изпраща команда, получателят (сървърът) отговаря с трицифрено число и кратко обяснение. Такъв разговор можете буквално да прочетете обратно в съобщение за грешка или лог файл и точно затова си струва да го разберете.

По-долу е показан пълен разговор. S: е получаващият сървър, C: е изпращащият сървър. Писмото отива от anna@example.com до jan@example.net.

S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (от тук нататък връзката е шифрована; клиентът изпраща отново EHLO)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Offerte
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Hoi Jan, hierbij de offerte.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

Командите една по една

Най-важното прозрение е: всичко преди DATA е envelope, всичко след DATA е съдържанието. Това, което стои в MAIL FROM, и това, което стои в кополовката From:, се доставят отделно и не е задължително да съвпадат. Сървърът доставя според RCPT TO; редът To: в съдържанието не играе роля при доставката.

Кодовете за отговор

Първата цифра на кода е най-важна:

При съвременните сървъри зад трите цифри стои разширен код за състояние във формата class.subject.detail (RFC 3463), например 5.1.1. Първата цифра отново е 2, 4 или 5. Втората цифра казва за какво става дума: 1 = адрес, 2 = пощенска кутия, 3 = пощенска система, 4 = мрежа и маршрутизиране, 5 = протокол, 6 = съдържание, 7 = сигурност и политика. Няколко примера, които често ще срещнете:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (временно)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (политика: спам, списък с блокирания, DMARC)

В модул 6 ще научите как да разчитате пълен bounce и ще намерите таблица с най-често срещаните кодове.

Защо разликата между временно и окончателно е толкова важна

Сървър, който се колебае, често отговаря с 4xx. Известен пример е greylisting: сървър, който все още не познава подателя, първия път казва "опитайте по-късно". Истински пощенски сървър се връща след няколко минути, много спам програми не го правят. Големите получатели също използват 4xx, за да забавят темпото, когато все още не се доверяват на даден IP адрес. За Вас като подател това означава: забавяне, но не загуба. Системата обикновено сама решава проблема.

5xx е различно. Там подателят не прави нов опит. Ако получите 5xx, някой трябва да промени нещо: адреса, съдържанието или настройките на изпращащия домейн.

Внимавайте: някои сървъри връщат 5xx, въпреки че проблемът е временен (например при пълна пощенска кутия 552 5.2.2), а други връщат 4xx за нещо, което никога няма да успее. Затова винаги четете текста след кода, не само числото.

Кой носи отговорност?

След 250 на точката след DATA отговорността преминава върху получаващия сървър. Ако впоследствие той не успее да постави писмото в пощенската кутия, той самият трябва да изпрати съобщение за грешка обратно. Това е източникът на един неприятен феномен: backscatter. Сървър, който първо приема всичко и едва по-късно установява, че адресът не съществува, изпраща bounce до подателя в envelope-а. Ако той е бил подправен от спамър, невинна трета страна получава bounce-а. Затова сървърите трябва да отхвърлят още при RCPT TO това, което не може да бъде доставено (вижте също catch-all в урок 3.3).

На практика: виждане на SMTP във Вашата собствена среда

Обикновеният потребител рядко вижда целия SMTP разговор, но вижда части от него:

• в bounce съобщение стои последният ред от разговора, например Remote-MTA: mx1.mailprovider.example и Diagnostic-Code: smtp; 550 5.1.1 ...;
• в кополовките на получено писмо за всеки сървър стои ред Received: с EHLO името и IP адреса (урок 1.5);
• в панел с лог на пощата, като E-mail Tracking в DirectAdmin при WebOké, виждате за всяко съобщение отговора на получаващия сървър. При други доставчици подобна функция се нарича например проследяване на съобщения или mail log, а съдържанието е сходно.

Така че не е нужно сами да се свързвате с пощенски сървър, за да можете да прочетете това. За тези, които все пак искат да опитат: с openssl s_client -starttls smtp -connect server:25 можете ръчно да проведете разговора, но много доставчици на домашен интернет блокират изходящия трафик на порт 25 (урок 1.4).

Обобщение

• SMTP е четим разговор: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Всичко преди DATA е envelope (доставка и съобщения за грешка), всичко след това е съдържанието с кополовките, които виждате.
• 2xx = успешно, 4xx = временно (опит отново по-късно), 5xx = окончателно (bounce).
• Разширеният код X.Y.Z показва за какво става дума; X.1 адрес, X.2 пощенска кутия, X.7 политика и сигурност.
• Винаги четете текста след кода; сървърите не са винаги последователни.

Тест

Задача

Задача Z1.2: Домейн, който не получава поща. Намерете MX записите на example.com. Попълнете какво сте открили и изберете какво прави изпращащ сървър с писмо за info@example.com: (a) доставя до сървъра с приоритет 0, (b) опитва A записа, (c) веднага се отказва, или (d) опитва отново по-късно. Програмата проверява MX записа на живо и го сверява.

Прочетете още

Стъпките в тези статии важат за панелите на WebOké; при други доставчици процесът е сходен.

• Как се изпращат имейлите / SMTP
• Неуспешно доставяне на имейл (Mail delivery failed): как да разчетете съобщението за грешка и какво означават кодовете
• Ръководство за DirectAdmin 9.3: E-mail Tracking: къде се е дянала моята поща?
• RFC 5321 (SMTP), параграф 3 и 4.2 (кодове за отговор); RFC 3463 (разширени кодове за състояние); RFC 7505 (null MX)