Модул 1 · 1.1

Български

Nederlands English Deutsch Français Dansk Español Svenska Italiano Polski Português Română Čeština Ελληνικά Magyar Slovenčina Български Suomi

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

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

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

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

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

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

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

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

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

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

Sanne de Vries (sanne@example.com) има цветарско ателие. Тя изпраща на своя клиент Ahmed (ahmed@example.net) оферта за булчински букет. Ето какво се случва, когато натисне Изпрати.

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

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

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

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

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

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

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

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

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

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

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

Return-Path: <sanne@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: Sanne de Vries <sanne@example.com>
To: Ahmed <ahmed@example.net>
Subject: Offerte bruidsboeket
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, сървъра на Ahmed. Частта след "from" е сървърът, който е предложил писмото, а частта след "by" е сървърът, който го е приел. Часовете показват колко време е отнела всяка стъпка.

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

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

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

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

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

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

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

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

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

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

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

В уебпощата можете да видите заглавните редове на писмото с бутона Заглавни блокове над писмото или чрез Още > Покажи изходния код. Урок 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é

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

Необходими

Маркетинг