Електронна пошта

Що це таке

Електронна пошта — це система, яка доставляє написане повідомлення на адресу вигляду ім'я@домен і залишає його в поштовій скриньці, доки власник його не прочитає. Її називають також e-mail, імейл або просто поштою, а стандарти здебільшого кажуть просто mail. Одержувачеві не треба бути в мережі в момент надсилання: сервери приймають лист, зберігають і передають далі, тому цю модель описують як «збережи й передай», а не як розмову.

Основну частину визначення дають два документи. RFC 5322 описує, що таке повідомлення: блок полів заголовка, один порожній рядок, а далі сам текст. RFC 5321 описує SMTP — протокол, яким сервер-відправник передає лист наступному серверу на шляху. Щоб знайти цей наступний сервер, відправник шукає в DNS MX-записи домену, і вони називають машини, готові приймати пошту для нього.

Повний лист може бути зовсім коротким:

From: Ana Holm <ana@example.org>
To: orders@example.com
Date: Fri, 16 Oct 2026 09:14:00 +0200
Subject: Invoice 114 has the wrong VAT number
Message-ID: <20261016.0914.ana@example.org>

Hello, could you send a corrected copy?

Обов’язкових полів заголовка тут лише два: дата й адреса автора. Усе інше за буквою стандарту необов’язкове, хоча лист без теми чи без ідентифікатора повідомлення виглядає недбало для програм, що сортують пошту. Рядок може мати щонайбільше 998 символів і бажано не довше за 78, бо чимало поштових програм досі обрізають або переносять усе довше.

Є й другий, прихований шар. SMTP переносить лист у конверті: це адреса повернення, куди надходять звіти про збої, і список одержувачів. Конверт і рядки From: та To:, які бачить читач, існують окремо й часто різняться. Прихована копія працює, бо одержувач є на конверті й відсутній у заголовках. Список розсилки працює, бо адреса повернення на конверті вказує на сам список, тож відмова від неіснуючої скриньки підписника потрапляє до програми розсилки, а не до людини, яка написала допис.

Чому це важливо

Адреса електронної пошти — це ідентичність, на яку спирається більша частина вебу. Підтвердження реєстрації, скидання пароля, квитанції, рахунки й повідомлення про відхилений платіж — усе це йде поштою. Тож продукт, у якого губляться листи, має користувачів, що опинилися перед зачиненими дверима, і цього ніхто не помічає. Людина, якій так і не прийшло посилання для підтвердження, рідко пише про це. Вона просто йде.

У електронної пошти також немає власника. Будь-який домен може тримати власні сервери, будь-який сервер може говорити з будь-яким іншим, і саме ця відкритість пояснює, чому пошта пережила майже всі сервіси обміну повідомленнями, створені після неї. Ціна цього — довіра. Початкова схема дозволяє відправникові написати в рядку From: що завгодно, тому сервери-одержувачі тепер самі вирішують, чи вірити листу. Вирішують вони на підставі даних, які домен-відправник публікує в DNS: які хости можуть надсилати пошту від його імені, які ключі підписують його листи і що робити з повідомленням, яке видає себе за лист із цього домену, але не має ні того, ні іншого.

Для бізнесу корисно розрізняти два види трафіку. Транзакційний лист іде одній людині через те, що вона щойно зробила: код, квитанція, посилання для скидання пароля. Масова розсилка йде багатьом людям, бо так вирішив відправник. Ці два потоки заробляють репутацію окремо, отримують скарги з різною частотою і часто надсилаються з різних доменів. Якщо їх змішати, розсилка, яка дратує людей, може затримати лист для скидання пароля.

І нарешті питання, де живе пошта. Власний поштовий сервер означає сховище, фільтрацію спаму, оновлення і репутацію відправника, яку треба заробити й утримати. Звичайна відповідь — розміщена поштова скринька для читання і окремий сервіс для автоматичних листів, і цей вибір варто робити свідомо, а не за замовчуванням.

Як це виглядає на практиці

На одній платформі пошта несла верифікацію, сповіщення, дайджести й кампанії, а з одним-єдиним постачальником кожен збій ставав повним. Рішенням стали три постачальники за одним інтерфейсом з автоматичним перемиканням: спершу SendGrid, далі SMTP2GO та Azure Communication Services. Вхідні вебхуки повідомляють, що кожен постачальник зробив із листом, і обидві сторони потрапляють у журнал надсилань та таблицю подій доставки, тож чи отримала людина свій лист верифікації, стає запитом, а не здогадкою. Кампанії для окремих сегментів користувачів працюють в окремій схемі розсилок із 5 таблиць і 24 функцій, збудованій окремо від транзакційної пошти, бо це інша задача. Перевірка під час запуску надсилає справжній лист крізь усю систему за прапорцем; у розробці збій записується як попередження, а в staging і production зупиняє процес. Сторінка називає й ціну: три інтеграції, які треба підтримувати, і журнали доставки, що ростуть і потребують чищення.

Власна пошта компанії починається з DNS. Зона містить близько двадцяти записів, серед них маршрутизацію пошти через постачальника розміщених скриньок, домен для транзакційних листів і записи автентифікації для обох, а уся зона зберігається як дані в репозиторії і звіряється з API постачальника. Окрема точка входу для аудиту показує різницю між оголошеним станом і тим, що реально віддається, нічого не змінюючи, і саме нею користуються найчастіше.

Де житиме пошта самої компанії, вирішила арифметика. Її публічні сервіси працюють на одному хості з 512 МБ пам’яті, і пошту свідомо тримають поза цією машиною: поштовому серверу потрібен запас, який хост уже витратив, тож його написано як заготовку для встановлення, що чекає на окремий хост. Тим часом листи до компанії ми читаємо у власній поштовій скриньці в Apple iCloud, і жодної розсилки за нею немає.

Де виникають проблеми

Пошта починає падати в спам того тижня, коли змінюють постачальника. У застосунку нічого не змінилося, а одержувачі стають підозріливими. Опубліковані записи домену досі називають старого відправника, тож листи від нового приходять без підпису або з хоста, якого домен ніколи не дозволяв. Додайте нового відправника до записів ще до переходу, залиште старого, доки не піде його останній лист, і, якщо домен їх запитує, читайте зведені звіти, які надсилають одержувачі.

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

Відмови накопичуються на адресі, яку ніхто не читає. Адреса повернення на конверті вказує на скриньку no-reply, тож повідомлення про остаточні збої приходять і лежать нерозкритими. Відправник і далі пише на скриньки, закриті рік тому, а одержувачі бачать у цьому звичку спамера. Спрямуйте адресу повернення туди, де звіти обробляються, і припиняйте писати на адресу після остаточного збою.

Тимчасову відмову сприймають як остаточну. Відповіді SMTP, що починаються з 4, означають «спробуйте пізніше», а ті, що починаються з 5, — «зупиніться». Відправник, який здається після першого 4xx, втрачає листи, які зайнятий чи обережний сервер прийняв би пів години по тому. RFC 5321 просить повторювати спроби щонайменше з інтервалом 30 хвилин і не здаватися раніше, ніж за чотири-п’ять днів. Транзакційній пошті зазвичай потрібні швидші повтори зі зростаючими паузами і чіткий запис про те, коли спроби нарешті припинилися.

Що почитати далі

• RFC 5322: Internet Message Format — поля заголовка, порожній рядок, обмеження довжини рядків і два поля, які має кожен лист.
• RFC 5321: Simple Mail Transfer Protocol — конверт, коди відповідей, пошук MX-записів і поради щодо повторних спроб.
• RFC 7208: Sender Policy Framework (SPF) — як домен перелічує хости, яким дозволено надсилати пошту від його імені.
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — підпис заголовків і тексту ключем, який одержувач бере з DNS.
• RFC 7489: DMARC — прив’язує обидві перевірки до домену у видимому рядку From:, додаючи політику і звіти; інформаційний документ, а не стандарт.