Модул 1 · 1.1

Какво се случва, когато натиснете Изпрати

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

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

Основни понятия: уебпоща, пощенски сървър, SMTP, MX запис, IMAP, плик, заглавни редове (хедъри), Return-Path, Received, Message-ID, SPF, DKIM, DMARC

Уебпощата е пощенска програма във Вашия браузър

Вашата поща не се намира във Вашия браузър, нито на Вашия компютър. Тя се намира на пощенски сървър: компютър, който работи денонощно, получава, съхранява и препраща писма. За да четете тези писма, Ви е нужна пощенска програма. Това може да бъде Outlook, пощенското приложение на Вашия телефон или уебпощата.

Уебпощата е просто пощенска програма, която работи във Вашия браузър. При WebOké това е Roundcube. Roundcube сам по себе си не е пощенски сървър. Той общува от Ваше име с пощенския сървър, на същите „езици“, които използват Outlook или Apple Mail:

IMAP за четене, преместване и изтриване на писма;
SMTP за изпращане на писма.

Ако нещо не работи в уебпощата, причината често не е в самата уебпоща, а в това, което сървърът прави или връща като отговор. И обратното: ако изпращането работи в уебпощата, но не и във Вашата пощенска програма, проблемът е в настройките на тази програма.

От Изпрати до Входящи в пет стъпки

Елена Димитрова (elena@example.com) има флорално ателие. Тя изпраща на своя клиент Ахмед (ahmed@example.net) оферта за булчински букет. Ето какво се случва, когато тя натисне Изпрати.

Предаване на собствения сървър. Уебпощата предава писмото чрез SMTP на пощенския сървър на Елена. Това се нарича още подаване или submission. При това Елена трябва да се впише, иначе всеки би могъл да използва нейния сървър за изпращане на спам. Пощенските програми използват за целта порт 465 или 587, с криптиране. Уебпощата на WebOké изпраща през същия сървър, в който сте вписани.
Намиране на пътя. Сървърът на Елена поглежда частта след @ в адреса на Ахмед: example.net. Той търси в DNS MX записа на този домейн. Този запис показва кой сървър приема пощата за example.net.
Доставяне. Сървърът на Елена се свързва с получаващия сървър и доставя писмото, отново чрез SMTP. Между сървърите това става през порт 25.
В пощенската кутия. Получаващият сървър проверява писмото (съществува ли адресът, спам ли е?) и го поставя в пощенската кутия на Ахмед, във Входящи или в папката за спам.
Четене. Ахмед отваря своята пощенска програма или уебпоща. Тя изтегля писмото чрез IMAP и го показва.

Всяка стъпка може да се провали отделно. Затова съобщението за грешка винаги подсказва къде е проблемът: дали Елена не е успяла да се впише в собствения си сървър (стъпка 1), дали сървърът ѝ не е открил получателя (стъпка 2 или 3), или получаващият сървър е отказал писмото (стъпка 4)?

Плик и писмо: два вида адреси

Електронното писмо прилича на писмо в плик. Сървърите гледат само плика. Вие и Ахмед виждате главно самото писмо.

Пликът се създава по време на SMTP разговора между два сървъра. Изпращащият сървър първо казва от кого е писмото (командата MAIL FROM), а след това за кого е (RCPT TO). Едва след това следва самото писмо. Адресът на подателя върху плика е адресът, към който се изпращат съобщенията за грешка. При последното доставяне получаващият сървър го поставя най-горе в писмото като Return-Path.

Писмото започва със заглавни редове (хедъри): редове с име, двоеточие и стойност. Най-известните са:

From: подателят, когото виждате в пощенската си програма;
To и Cc: получателите, които виждате;
Subject: темата;
Date: моментът на изпращане, според часовника на програмата на подателя;
Message-ID: уникален идентификатор на това писмо. Отговорите се позовават на него и така пощенската програма разбира кои писма са свързани.

Пликът и заглавните редове не е задължително да съвпадат. Ако Елена изпрати писмо със скрито копие (Bcc) до своя колега Димитър (dimitar@example.com), Димитър е записан върху плика, но не и в заглавните редове. Затова Ахмед не вижда, че Димитър също чете писмото. А един бюлетин често има Return-Path към услугата за бюлетини, докато From е адресът на магазина. Тогава съобщенията за грешка отиват при услугата.

Редовете Received: пътният дневник на писмото

Всеки сървър, който приема писмо, трябва да добави заглавен ред Received, и то най-горе. Така по пътя си писмото натрупва пътен дневник. Най-горният ред Received е следователно последната стъпка, а най-долният е първата. Четете ги отдолу нагоре.

Ето приблизително как изглеждат заглавните редове на писмото на Елена при Ахмед (съкратено):

Return-Path: <elena@example.com>
Received: from mail.example.com (mail.example.com [192.0.2.10])
        by mx.example.net with ESMTPS
        for <ahmed@example.net>; Tue, 10 Nov 2026 10:15:04 +0100
Received: from webmail.example.com ([192.0.2.20])
        by mail.example.com with ESMTPSA
        for <ahmed@example.net>; Tue, 10 Nov 2026 10:15:02 +0100
From: Елена Димитрова <elena@example.com>
To: Ахмед <ahmed@example.net>
Subject: Оферта за булчински букет
Date: Tue, 10 Nov 2026 10:15:01 +0100
Message-ID: <20261110091501.a1b2c3@example.com>

Прочетете първо най-долния ред Received. Уебпощата е предала писмото на mail.example.com. Буквите ESMTPSA означават: криптирано (S) и с вписване (A). След това mail.example.com го е предал на mx.example.net, сървъра на Ахмед. Частта след "from" е сървърът, който е предложил писмото, а частта след "by" е сървърът, който го е приел. Часовете показват колко време е отнела всяка стъпка.

Внимавайте за един капан: подателят може сам да добави фалшиви редове най-отдолу, преди да изпрати писмото. Затова се доверявайте главно на най-горните редове, които са създадени от сървъри, които познавате, например сървъра на Вашия собствен доставчик.

Защо From може да бъде подправен

Протоколът SMTP е създаден във време, когато всички са си имали доверие. Нищо в самия протокол не проверява дали подателят във From е истински. Така измамник може да изпрати писмо с From: elena@example.com, без да има нищо общо с Елена.

Затова по-късно са добавени три проверки, които собственикът на домейна настройва в своя DNS:

SPF посочва кои сървъри имат право да изпращат поща с подател върху плика от този домейн.
DKIM поставя цифров подпис върху писмото. Получателят го проверява с ключ от DNS на домейна, който е подписал.
DMARC свързва тези две проверки с домейна, който виждате във From, и указва какво да направи получателят, ако проверката е неуспешна: нищо, преместване в спама или отказ.

Това се урежда от администратора на домейна, а не от Вас като потребител на уебпощата. Как точно работи, ще научите в курса Имейлът в ред. Засега е достатъчно да знаете, че показаното име на подателя не доказва нищо и че в заглавните редове можете да видите дали тези проверки са успешни (урок 2.2).

Изпратено още не означава пристигнало

Ако писмото Ви е в папката Изпратени, със сигурност знаете само едно: Вашият собствен сървър го е приел (стъпка 1). Останалото се случва след това, понякога много по-късно.

Получаващият сървър може временно да откаже писмото. Някои сървъри първо молят непознат подател да опита отново по-късно (greylisting). Тогава Вашият сървър опитва отново, понякога в продължение на дни, и Ви уведомява, ако опитите продължават да са неуспешни.
Получаващият сървър може да откаже писмото окончателно, например защото адресът не съществува или пощенската кутия е пълна. Тогава получавате обратно съобщение за грешка (bounce, урок 8.4).
Писмото може да пристигне, но да попадне в папката за спам. Тогава не получавате никакво уведомление.

Затова, ако Елена чака отговор, който не идва, тя първо проверява дали във Входящи има съобщение за грешка и моли Ахмед да погледне в папката си за спам.

На практика: как работи това в уебпощата

В уебпощата виждате заглавните редове на писмото чрез бутона Заглавни блокове над писмото или чрез Още > Покажи изходния код. Урок 2.2 разглежда това по-подробно. Как уебпощата и Вашата пощенска програма показват едни и същи писма, ще прочетете в ръководството за Roundcube, в раздела Какво е уебпощата. В други уебпощи, като Gmail или Outlook.com, това работи по подобен начин, само бутонът се казва другояче (в Gmail например Показване на оригинала).

Обобщение

Уебпощата е пощенска програма във Вашия браузър. Тя общува с пощенския сървър чрез IMAP (четене) и SMTP (изпращане).
Писмото отива от Вашия собствен сървър до сървъра, посочен в MX записа на домейна на получателя.
Пликът (MAIL FROM, RCPT TO, по-късно Return-Path) е за сървърите, а заглавните редове (From, To, Subject, Date, Message-ID) са за хората и програмите.
Всеки сървър добавя ред Received най-горе; четете ги отдолу нагоре.
From може да бъде подправен; SPF, DKIM и DMARC затрудняват подправянето. Изпратено не означава пристигнало.

Тест (quiz)

Задача

Задача A1.1: Четене на заглавни редове (хедъри). Материалът kopregels-1.txt се намира под тази задача: заглавните редове на истинско, но анонимизирано писмо. Прочетете ги отдолу нагоре и попълнете: домейна във From, домейна на Return-Path, колко реда Received има и кой сървър последен е получил писмото (най-горният ред Received, частта след "by"). Програмата сравнява Вашите отговори с ключа с отговорите и показва за всеки въпрос дали е верен, с обяснение къде в заглавните редове е можело да го намерите.

Задача A1.1: Четене на заглавни редове (хедъри)

Файл към тази задача: kopregels-1.txt

Домейн във From

Домейн на Return-Path

Брой редове Received

Сървър, който е получил писмото последен (след "by" в най-горния Received)

Това, което въвеждате, и резултатите от проверката не се съхраняват. Браузърът Ви запомня отговорите и дали сте изпълнили задачата. Ако сте влезли, запазваме само дали задачата е била (почти) правилна в Моите курсове; и там можете да го изтриете.

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

Където са описани стъпки в уебпощата, те се отнасят за уебпощата на WebOké; в други уебпощи това работи по подобен начин.

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг