Пътят на един имейл

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

Учебна цел: След този урок ще можете стъпка по стъпка да опишете как писмо от подателя стига до получателя, и за всяка стъпка да кажете коя програма или кой сървър върши работата.

Основни понятия: пощенска програма (MUA), сървър за изпращане (MSA, submission), пощенски сървър (MTA), MX запис, опашка за изчакване, доставка (MDA), пощенска кутия, изтегляне (IMAP/POP3), envelope, заглавни редове (kopregels)

Поща е като писмо, не чат съобщение

Когато изпратите чат съобщение, то минава през една компания: приложението на подателя и приложението на получателя говорят с едни и същи сървъри. При имейла е различно. Подателят и получателят могат да бъдат при различни доставчици: единият при хостинг компания, другият в Gmail, трети в Microsoft 365 или на собствения сървър на фирмата си. И въпреки това писмото пристига. Това се получава, защото всички пощенски сървъри по света следват едни и същи правила.

Можете добре да сравните имейла с пощата. Пишете писмо (съобщението), поставяте го в плик с адрес (envelope), занасяте го до пощенската кутия (сървъра за изпращане), пощенската компания проверява къде се намира адресът (справката за MX записа), превозва писмото до правилния сортировъчен център (приемащия пощенски сървър) и той го поставя в пощенската кутия на получателя (mailbox). Получателят го взема оттам, когато му е удобно.

Станциите подред

Да кажем: Anna изпраща писмо от anna@example.com до jan@example.net. Ето какво се случва:

При малките доставчици MSA, MTA и MDA често са една и съща програма на един сървър. При големите доставчици това са отделни клъстери. За Вас това почти няма значение: това са роли, а не отделни кутии.

Обърнете внимание на разликата между стъпка 1 и стъпка 4. И двете използват SMTP, Simple Mail Transfer Protocol (RFC 5321). Но при стъпка 1 Вие влизате с парола и използвате порт 587 или 465; това се нарича submission (RFC 6409). При стъпка 4 два сървъра говорят помежду си на порт 25, без вход с парола: приемащият сървър приема поща за собствените си домейни от когото и да е. В урок 1.4 ще видите защо съществува това разделение.

Стъпка 3 отблизо: справката за MX записа

Изпращащият сървър не знае сам къде example.net получава своята поща. Той пита DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Най-ниското число има предимство. Сървърът първо пробва mx1, а ако той не отговаря, пробва mx2. След това търси IP адреса на това име (A или AAAA запис) и установява връзка.

Два особени случая, с които ще се сблъскате на практика:

• Няма MX запис. Тогава изпращачът пробва A или AAAA записа на самия домейн (т.нар. "implicit MX" от RFC 5321, параграф 5.1). Това е остатък от миналото и не работи надеждно; всеки домейн, който получава поща, трябва да има MX запис.
• Null MX: 0 . Това означава: "този домейн никога не получава поща" (RFC 7505). Домейнът example.com има точно такъв запис. Изпращачът се отказва веднага и връща съобщение за грешка, вместо да продължава да опитва с дни.

Как точно работят MX записите и приоритетите, можете да прочетете в урок 4.1 от курса за DNS.

Опашката за изчакване: имейлът може да отнеме време

Едно писмо не винаги пристига за секунда. Ако приемащият сървър не отговаря, или казва "опитайте по-късно" (код, който започва с 4), писмото остава в опашката за изчакване на сървъра за изпращане. Той ще опита отново по-късно, всеки път с малко повече време между опитите. RFC 5321 (параграф 4.5.4.1) препоръчва поне 30 минути между опитите и отказ едва след 4 до 5 дни. Много сървъри изпращат предупреждение ("delayed", все още недоставено) след няколко часа и окончателно съобщение за грешка след няколко дни.

Това е силна страна на имейла: ако пощенски сървър не работи за час, не се губи писмо. Това е и причината защо писмо понякога пристига едва часове по-късно. В модул 6 ще видите как да разпознаете такова забавяне.

Envelope и заглавни редове: два адреса

Точно както при пощата, едно писмо има два вида адреси:

• Envelope. Това са адресите, които сървърите използват помежду си в SMTP разговора: MAIL FROM (подателят за съобщения за грешки, по-късно виждан като Return-Path) и RCPT TO (получателят). Сървърите доставят въз основа на envelope.
• Заглавните редове (headers). Това е, което стои в самото писмо: From:, To:, Cc:, Subject:, Date:. Вашата пощенска програма показва тях.

Най-често те съвпадат, но не винаги. Получател в BCC стои в envelope, но не и в заглавните редове; затова другите получатели не го виждат. Услуга за бюлетини поставя собствения си адрес като envelope подател, така че съобщенията за грешки стигат до нея, докато в From: стои Вашият адрес. А измамник може да постави каквото пожелае в From:.

Защо това има значение: SPF проверява envelope подателя, потребителят вижда From:. Затова съществува DMARC, който свързва двете (модул 4).

Къде може да се объркате

С тази картина можете при всеки проблем да си зададете въпроса: на коя станция нещо се обърква?

• Изпращането не успява (съобщение за грешка веднага в програмата Ви): стъпка 1 или 2. Почти винаги са настройки: порт, вход, парола (модул 2).
• Получавате bounce обратно: стъпка 4 или 5. Приемащият сървър е отказал писмото, или адресът не съществува (модул 6).
• Писмото пристига, но в папката за спам: стъпка 5. Получателят не се доверява на писмото (модули 4 и 5).
• Получателят не вижда нищо, а Вие не получавате съобщение за грешка: писмото може все още да е в опашка за изчакване, или е било тихо филтрирано при получателя. Тук помагат логовете на сървъра за изпращане (модул 6).
• Поща не пристига никъде за Вашия домейн: стъпка 3. MX записите не са верни, например след преместване (модул 8).

На практика: така изглежда това при хостинг пакет

При хостинг пакет на WebOké един сървър за пакет изпълнява всички роли: пощенската Ви програма доставя писмото на този сървър (стъпки 1 и 2), сървърът го изпраща навън (стъпки 3 и 4) и получава поща за Вашия домейн (стъпка 5). В DirectAdmin можете с E-mail Tracking да видите за всяко съобщение дали е доставено. При други доставчици работи по сходен начин; там подобна функция се нарича например "проследяване на съобщения" или "mail log".

Обобщение

• Писмо преминава от Вашата пощенска програма (MUA) през сървъра за изпращане (MSA/MTA) до приемащия сървър (MTA/MDA) и оттам до пощенската програма на получателя.
• Изпращането от Вашата програма е SMTP-submission с вход (587/465); сървърите помежду си говорят SMTP на порт 25; изтеглянето се извършва с IMAP или POP3.
• Изпращащият сървър търси MX записите на домейна след знака @. Null MX (0 .) означава: този домейн не получава поща.
• Писмо, което не може да бъде доставено веднага, остава в опашката за изчакване и се опитва отново в продължение на дни.
• Envelope (Return-Path) и заглавните редове (From) са два различни подателя. SPF гледа първия, потребителят вижда втория.

Тест

Задача

Задача Z1.1: Намиране на първия пощенски сървър. Намерете MX записите на gmail.com (или на Вашия собствен домейн). Попълнете кой сървър ще бъде пробван първи, с неговото число за приоритет, и един IP адрес (IPv4 или IPv6) на този сървър. Програмата пита за същите данни на живо и проверява отговора.

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

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

• Как се изпращат имейлите / SMTP
• Ръководство за DirectAdmin 8.7: IMAP или POP3: каква е разликата?
• Безплатен курс по DNS 4.1: MX записи и приоритет
• RFC 5321 (SMTP), параграф 5.1 (MX и implicit MX) и 4.5.4.1 (повторни опити); RFC 7505 (null MX)