Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!Пости з тегом #SMTP
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. Щоб впевнено шукати помилки, навіть якщо вони не повʼязані очевидно з поточними змінами.