Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!Пости з тегом #SMTP
27.09.2022
DKIM - механізм підпису листів SMTP
🔐✉️✍️ Сьогодні розкажу про DKIM - один з механізмів безпеки поштового протоколу SMTP.
SMTP - унікально лібертаріанська система. Як і в реальному світі, до вашої поштової скрині може покласти будь-хто та будь-що. Хто завгодно в інтернеті може надіслати листа з будь-яким змістом. Немає ніяких механізмів авторизації. Це, мабуть, підходило для інтернету в 80-х, але в наші часи це й дозволяє існування спаму. З усім тим, SMTP, як найвитриваліша і найпоширеніша система комунікації, продовжує існувати та нема основ вважати, що колись перестане.
Так от, за відсутністю авторизації, SMTP працює за принципом довіри. Кожен лист оцінюється на автентичність. Вплинути може і зміст листа, і сервер відправника, і багато різних факторів, які цілком не оголошуються. (Бо попри всю відкритість, більшість скринь в інтернеті належать до GMail, а за ним — до декількох провайдерів менше. Кожен має свій ноу-хау для визначення спаму.)
DKIM - це один з погоджених механізмів, що покращить автентичність вашого листа. Якщо дуже просто, то це електронний підпис. Лист підписується деяким доменом. Такий підпис можна зробити тільки з дозволу власника домену. В першу чергу накладається підпис домену відправника (як вказаний в адресі), але також може бути домен сервера, що виконує виправляння. А взагалі технічно лист можна підписати будь-яким доменом, тільки навряд чи це вплине на автентичність.
DKIM працює за звичним принципом криптографічної пари. Приватний ключ знає тільки відправник і використовує для підпису змісту листа. Публічний ключ оголошують в особливому DNS-запису. Тоді будь-який отримувач може дістати публічний ключ та перевірити підпис.
Що це дає? Після перевірки DKIM, отримувач знає, що відправник — власник свого домену, або довірена особа. Це досить сильний сигнал автентичності. Звісно, спамери можуть (і роблять) повністю коректні DKIM підписи для своїх підозрілих доменів — але про це іншим разом.
Щоб подивитись підпис DKIM листа в вашій поштовій скрині, дивіться на заголовки DKIM-Signature, а також Authentication-Results (його додає ваш поштовий сервіс.)
28.09.2022
SMTP - діалоговий протокол. Шифрування SMTP
✉️📭💬 Продовжуючи серію про дивний протокол SMTP. Який ми всі використовуємо щодня, але ніхто не знає, як він працює.
Як вам така дивина: на відміну від HTTP, SMTP - протокол діалоговий. Тобто для того, щоб відправити одного листа, потрібно обмінятися з отримувачем не однією, а декількома командами. Спочатку HELO, потім MAIL FROM, потім RCPT TO, і нарешті DATA - зміст листа. Перед тим, як слати наступну команду, треба дочекатись відповіді до попередньої. Проблема в тому, що затримка підключення накладається на кожну з команд, тож з повільним звʼязком або на далекий сервер SMTP йде набагато довше, ніж HTTP. Це, до речі, одна з головних причин того, що сьогоденні поштові сервіси як то Mailtrap або SendGrid пропонують відправляти по HTTP API, а не по SMTP.
А ще через цю діалоговість SMTP має дуже дивну форму шифрування. (Бо, звісно, всі листи, як і вебсайти, варто відправляти тільки через зашифрований канал.) Так от, хоч і існує SMTP-аналог до HTTPS, тобто, коли спочатку встановлюється канал TLS, а потім вже через нього SMTP, але такий спосіб непопулярний. Натомість у протоколі SMTP є команда STARTTLS, після якої сервер має припинити комунікацію по відкритому каналу, та почати сеанс TLS на тому самому підключенні. І так роблять практично всі клієнти SMTP. Через STARTTLS всім серверам SMTP доводиться керувати власними TLS-сертифікатами, і не можна цю роботу делегувати балансиру, як це зазвичай трапляється з HTTP.
15.02.2023
Історія сьогоднішнього багу
Тільки закінчив випускати хотфікс. Випускати щось в продакшн вночі — завжди цікаво, та завжди з історією. Що ж трапилось на цей раз?
Баг зʼявився у надсиланні пошти. Його помітили ще на стейджингу — чомусь листи не відправлялись з помилкою SMTP 503 5.5.1 Error: authentication not enabled. Але на стейджингу принаймні я багато уваги цьому не приділив, бо було більше схоже на проблеми з налаштуваннями середовища, ніж на реальну проблему. Але ж на продакшні баг відтворився, та почав перешкоджати надсиланню чесних користувацьких листів. Довелося терміново розвʼязувати.
Перше питання — що взагалі значить ця помилка? З мого досвіду, аутентифікація SMTP потребує шифрування, тобто STARTTLS. Бо як я вже писав, інакше пароль зможуть підгледіти по дорозі. Тож інтуїція каже, що насправді проблема у тому, що клієнт не надсилає команду STARTTLS. Шукаю параметри підключення та знаходжу: enable_starttls_auto: false. Так, це дуже схоже на причину. Але цей рядок зʼявився в проєкті роки тому. Як трапилось, що поведінка змінилась зараз?
З нещодавніх змін до проєкту підозрою є оновлення Ruby on Rails. Оновлення мінімальне та стосується тільки патч-версії, але все ж таки це глобальна зміна, яка теоретично може вплинути на будь-що. А конкретно, при перегляді різниці файлу Gemfile.lock бачу, що помінялася також версія гему mail. Його має сенс перевірити в першу чергу.
І нарешті, в переліку змін гему mail бачу цікавий рядок “Bug Fixes: Regression: accept enable_starttls_auto: false”. Знайшов! (Окреме питання, що написано, що вона unreleased, хоча вже 2 тижні як released. Але буває.)
Тож послідовність подій така: в нас були поламані налаштування. Але через баг у гемі вони не застосовувались. Далі гем виправив баг, ми оновились на виправлену версію, налаштування набули чинності та проявили вже наш баг.
Що робити, щоб такого не було? Напевно, головне, це підтримувати стейджинг в повністю робочому стані, як пріоритет №1. Щоб впевнено шукати помилки, навіть якщо вони не повʼязані очевидно з поточними змінами.
24.03.2025
Чому спамери краще вміють в SMTP?
Я тут багато писав про особливості SMTP (бо саме з ним пощастило працювати останніми роками на Mailtrap.) Натрапив тут на пост, де згадувалося, що спамери краще виконують (так, виконують, а не обходять) механізми захисту SMTP, ніж легітимні відправники. Хотілося прокоментувати.
Проблема тих механізмів (DKIM, SPF, DMARC) в тому, що вони складні чисто технічно. А подолати технічні складності набагато легше, коли це твоя головна робота. Фактично, кожний новий механізм тільки покращує позиції спамерів та погіршує — пересічних відправників.
Всі поточні механізми захисту привʼязані до домену відправника. Та оскільки спамери вільні реєструвати безліч нових доменів, немає ефективного способу позначити когось як спамера. В цілому, також немає способу позначити себе як “не спамера” (бо таким способом відразу ж скористались би спамери.)
Отже, можна сказати, що SMTP приречений на спам. Причому це значно більша проблема для відправників. Бо через підозри на спам можуть не дійти абсолютно непорочні листи — як-от відновлення пароля. Бо в ньому була картинка велика, а ще було посилання на домен підтримки, який схожий на ваш, але не зовсім (прямо як з фішингом). Тож спамфільтр вирішив, що лист підозрілий — та до побачення.
27.03.2025
Чим складні SPF, DKIM, та DMARC?
Розгляньмо коротко три головні механізми автентифікації пошти, та чому вам варто звернутися до поштового сервісу (наприклад, до нас), та перекласти турботи на їхню голову.
SPF - це DNS (TXT) запис, що оголошує, з яких IP-адрес дозволено надсилати пошту від вашого домену. Складність 1: йдеться про Envelope FROM, то треба знати, що це таке. Та не забути налаштувати поштову програму, щоб вона використовувала правильний. А також, оскільки SPF оголошує айпішки, то треба, щоб поштова програма виконувалася на машині зі статичною айпішкою, а не десь в хмарі. Та, потрібно не забувати оновлювати той запис, коли адреси змінюються (та вміти його правильно скласти.)
DKIM - про який я вже розповідав - це асиметричний підпис листів. Публічний ключ сидить в TXT записі до вашого домену (А тут вже можна і домен Envelope FROM, і просто From:, а краще — обидва!) А приватним потрібно підписувати важливі заголовки в кожному листі. Мені особисто підпис заголовків це завжди головний біль, бо їх треба зібрати, нормалізувати, скласти до купи… Звісно, на то є бібліотеки, головне — інтегрувати їх у поштову програму.
DMARC - а оце дійсно просто. DMARC тільки оголошує про наш намір використати SPF та DKIM. Бо, бачите, без DMARC незрозуміло, чи вважати відсутність механізму сильним відʼємним сигналом. Але наявність DMARC (який стає зараз примусовим для листів на GMail та Yahoo) збільшує наслідки від поламки SPF/DKIM.
Але все ж головною проблемою є те, що всі ці механізми тільки підтверджують автентичність домену відправника. А те, що цей домен не bank.com, а bank.com.abcdef.xyz - їм всім абсолютно байдуже.