Електронна пошта: HELO/EHLO неправильно — виправте це, поки провайдери не обмежили вас

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

Одна з тихих причин також одна з найдемкіших: ваш SMTP-сервер представляється з хибним ім’ям у HELO/EHLO.
Великі провайдери це помічають. Деякі почнуть тротлити вас. Інші просто відмовлять у прийомі. І найгірше — ви можете так працювати місяцями,
поки зміна політики, хиткість репутації IP або новий пул вихідних реле не перетворять вашу «дрібну помилку в конфігурації» на інцидент.

Для чого насправді потрібні HELO/EHLO (і чому провайдери звертають увагу)

SMTP починається з представлення. Клієнт підключається, сервер показує банер, а потім клієнт каже або:
HELO (старий стиль) або EHLO (розширений SMTP). Цей один рядок містить «ім’я», яке клієнт
заявляє як свою ідентичність. Це не автентифікація. Це не криптографічне підтвердження. Це твердження — часто чесне, іноді необережне,
інколи зловмисне.

Приймаючі провайдери все ще звертають увагу, бо HELO/EHLO виступає як дешевий ранній сигнал. Це частина ширшої історії про послідовність:
чи виглядає зворотний DNS підключаючогося IP адекватно, чи збігається він із заявленим ім’ям, чи збігається ім’я сертифіката TLS з
представленою ідентичністю, чи має домен у конверті SPF, проходить DKIM, чи погоджується з DMARC, чи поведінка відповідає історії?
HELO/EHLO — одна нитка в цьому полотні. Пошкоджена нитка не завжди потопить вас. Достатньо багато пошкоджених ниток — і ви в повільному ряду.

На практиці провайдери трактують поганий HELO/EHLO як одне з:

• Неправильно налаштована інфраструктура (не зловмисно, але непрофесійно)
• Скомпрометований хост (робоча станція, яка прикидається поштовим сервером)
• Масовий відправник, що економить (бо економія — це місце, де вмирає доставляність)

Що вважається «поганим»? Хіти:

• HELO/EHLO — localhost, localhost.localdomain або якийсь внутрішній хостнейм.
• HELO/EHLO — літерал IP або IP в дужках, коли це недоречно.
• HELO/EHLO — домен без записів A/AAAA.
• HELO/EHLO — домен, що резолвиться, але не відповідає очікуванням політики зворотного DNS.
• HELO/EHLO змінюється непередбачувано під час повторних спроб або в пулі реле.

Якщо ви керуєте поштою у продакшені, ви хочете, щоб приймаюча сторона бачила стабільне, маршрутизоване повністю кваліфіковане доменне ім’я (FQDN), яким ви володієте,
з узгодженими прямими і зворотними DNS там, де можливо. Не тому, що специфікація вимагає досконалості, а тому, що доставляність — це екосистема евристик,
і вам не дають голосу.

Цікаві факти та історичний контекст

Шість–десять коротких пунктів, бо історія пояснює нинішні дивні політики:

1. HELO з’явився до більшості сучасних антіспам-практик. Ранні SMTP припускали співпрацюючі мережі; «ідентичність» була здебільшого для логів і маршрутизаційної ясності.
2. EHLO прийшов з ESMTP, щоб домовлятися про можливості. Це не просто привітання; воно відкриває розширення, як SIZE та STARTTLS, залежно від сервера.
3. Зворотний DNS став основним інструментом проти зловживань у еру спаму. Провайдери опиралися на PTR, бо ботнетам було дорого підтримувати його послідовно.
4. Деякі приймачі досі трактують «немає PTR» як підозріле явище. Це не завжди порушення RFC, але сильна кореляція зі спам-джерелами.
5. Перевірки HELO існували в ранніх конфігураціях MTA задовго до SPF. Багато правил у Postfix/Sendmail використовували перевірки HELO як дешевий фільтр.
6. Системи репутації IP враховують аномалії привітання. EHLO з localhost із публічного IP виглядає як скомпрометована машина, бо так часто і є.
7. TLS ускладнив питання ідентичності. Тепер у вас є ім’я банера, ім’я EHLO і ім’я сертифіката; невідповідності можуть підвищити скоринг.
8. Хмарне масштабування збільшило ймовірність невідповідності. Пули автоскейлінгу й ефемерні імена хостів полегшують відправку MTA з некоректним представленням.
9. Доставляність стала критичною для продукту. Скидання паролів і коди MFA — це не маркетинг; тротлінг стає проблемою доступності.

Як некоректний HELO/EHLO провалюється в продакшені

1) М’який тротлінг, що виглядає як «випадкова повільність»

Багато провайдерів віддають перевагу тротлінгу замість відмови. Вони приймуть невеликий потік і відкладатимуть решту з тимчасовими помилками
(4xx відповіді). Ваш MTA повторює спроби. Черга росте. Зрештою, користувачі кричать.

Курящий доказ — не повний збій; це обрив часу доставки. І оскільки повтори «зрештою проходять», on-call іноді знизить плечима і повернеться до «реального» збою.
Це зниження плечей перетворює вас на постійний повільний ряд.

2) Жорсткі відмови з неінформативними рядками помилок

Деякі приймачі відкидають із «bad HELO» або «invalid hostname», що принаймні чесно. Інші повертають нечіткі політичні помилки.
Якщо ваші логи не зберігають текст віддаленої відповіді, ви неправильно діагностуєте це як «провайдер нестабільний».

3) Зниження репутації: ви не помічаєте, поки не помітите

Неправильний EHLO може терпітися, коли репутація IP/домену бездоганна. Потім один скомпрометований акаунт надсилає спам,
або новий вихідний IP погано «розігрівається», і різко скоринг приймача змінюється. Ваше налаштування HELO стає зручним приводом для покарання.

4) Накопичення невідповідностей TLS і ідентичності

Якщо ваш EHLO каже mail.example.com, але ваш TLS-сертифікат для smtp-out.example.net, а PTR для IP —
ec2-203-0-113-10.compute-1.amazonaws.com, ви створили невелику музейну колекцію невідповідностей. Жодна поодинока невідповідність не завжди фатальна.
Колекція — так.

Парафраз думки Вернера Фогелса (CTO Amazon): «Все ламається постійно; проєктуйте для виявлення й відновлення.» Ідентичність пошти — частина виявлення, тільки з боку приймача.

Жарт №1: Ваш поштовий сервер, що каже «HELO localhost», — як прийти на зустріч із клієнтом з бейджем «Привіт, я хтось інший.»
Ніхто не буде заарештований, але ніхто не довірятиме.

Швидкий план діагностики

Коли доставка сповільнюється або стрибки відмов ростуть, не починайте з ротації API-ключів або звинувачення DNS «взагалі».
Зробіть це в порядку й ви зазвичай знайдете вузьке місце за менше ніж 20 хвилин.

Спочатку: підтвердіть, чи віддаляє вас приймач чи відкидає

• Перевірте вихідні логи на 4xx відкладання та їхній текст.
• Визначте топ-домени отримувачів, які відкладають (Gmail, Microsoft, Yahoo, корпоративні домени).
• Підтвердіть, чи ті самі отримувачі успішні через кілька годин (класична поведінка тротлінгу).

Друге: зафіксуйте точну SMTP-розмову, яку представляє ваш клієнт

• Банер, який ви отримуєте від віддаленого.
• Ваш рядок EHLO/HELO.
• Чи змінює STARTTLS щось.
• Чи віддалений явно скаржиться на HELO/EHLO.

Третє: перевірте вирівнювання ідентичності (EHLO ↔ прямий DNS ↔ зворотний DNS ↔ TLS)

• Чи розв’язується ім’я EHLO (A/AAAA)?
• Чи має підключаючийся IP PTR і чи виглядає він адекватно?
• Чи PTR резолвиться назад на підключаючийся IP (forward-confirmed reverse DNS), де можливо?
• Чи ім’я сертифіката TLS узгоджується з тим, за кого ви себе видаєте?

Четверте: перевірте конфігурацію MTA та маршрути відправлення

• Чи використовуєте ви кілька реле або NAT вихідних IP?
• Чи перевизначається ваш HELO по транспортам, відправнику або relayhost?
• Чи змінювало це «оптимізація» недавно (образ контейнера, шаблон автоскейлу, нове реле)?

П’яте: тільки після цього перевіряйте SPF/DKIM/DMARC

Вони дуже важливі. Але коли ви усуваєте тротлінг, що почався відразу після зміни вихідних IP або після перебудови поштових вузлів,
HELO/EHLO і зворотний DNS — найшвидше виправлення. Поставте вступ правильно, перш ніж домовлятися про довіру.

Практичні завдання: команди, виводи, рішення

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

Завдання 1: Подивіться, що ваш сервер надсилає як EHLO (з логів)

cr0x@server:~$ sudo grep -R "EHLO" /var/log/mail.log | tail -n 5
Jan 03 09:12:41 mx1 postfix/smtp[22104]: <remote>: EHLO localhost
Jan 03 09:13:02 mx1 postfix/smtp[22177]: <remote>: EHLO mx1.internal
Jan 03 09:13:30 mx1 postfix/smtp[22230]: <remote>: EHLO mail.example.com
Jan 03 09:14:05 mx1 postfix/smtp[22301]: <remote>: EHLO localhost.localdomain
Jan 03 09:14:40 mx1 postfix/smtp[22392]: <remote>: EHLO mail.example.com

Що це означає: Ваші клієнти представляють неконсистентні значення EHLO: localhost, внутрішні імена та правильний FQDN.

Рішення: Припиніть випадковість. Налаштуйте одне стабільне ім’я EHLO для вихідного SMTP і переконайтеся, що всі вузли його використовують.

Завдання 2: Відтворіть SMTP-розмову з OpenSSL (STARTTLS)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com < /dev/null
CONNECTED(00000003)
---
220 mx.google.com ESMTP
---
no peer certificate available
---

Що це означає: Ви можете дістатися до порту 25 і отримати банер. Це доводить лише доступність, не ваш EHLO. Потрібно фактично говорити SMTP.

Рішення: Використайте інтерактивну сесію, щоб відправити EHLO і спостерігати відповіді сервера (наступне завдання).

Завдання 3: Поговоріть SMTP інтерактивно й подивіться, чи EHLO викликає політику

cr0x@server:~$ nc -v gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!
220 mx.google.com ESMTP
EHLO localhost
550-5.7.1 Invalid HELO/EHLO domain. See https://support.google.com/mail/?p=InvalidHelo
550 5.7.1 Bad HELO/EHLO

Що це означає: Приймач явно відкидає ваше значення EHLO. Це не «привид репутації»; це конкретна помилка конфігурації.

Рішення: Негайно виправте ім’я EHLO. До того моменту повторні спроби не допоможуть; вам дають політичну відмову.

Завдання 4: Перевірте, чи ім’я EHLO резолвиться (прямий DNS)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Що це означає: Ім’я EHLO має запис A. Це базова вимога.

Рішення: Продовжуйте: також перевірте AAAA і чи ця IP-адреса дійсно ваш вихідний.

Завдання 5: Перевірте наявність AAAA (не дивуйтеся з IPv6)

cr0x@server:~$ dig +short AAAA mail.example.com

Що це означає: Немає запису IPv6. Це нормально, якщо ви не надсилаєте по IPv6. Це також підказка: якщо ви надсилаєте по IPv6, можливо використовуєте інше ім’я/шлях.

Рішення: Підтвердіть, яку сімейство IP ваш MTA фактично використовує для доступу до великих провайдерів.

Завдання 6: Визначте фактичний вихідний IP (не вгадуйте)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Що це означає: Дефолтний egress public IP цього хоста — 203.0.113.10 (принаймні для HTTP). SMTP може відрізнятися, якщо у вас є політика маршрутизації або реле.

Рішення: Зіставте з логами й правилами NAT/firewall; не припускайте, що «curl IP» = «SMTP IP».

Завдання 7: Перевірте зворотний DNS (PTR) для вихідного IP

cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.

Що це означає: PTR вказує на mail.example.com. Це бажаний шлях: IP заявляє ім’я, яким ви контролюєте.

Рішення: Переконайтеся, що ваше ім’я EHLO збігається з цим PTR (або принаймні знаходиться в тій самій контрольованій доменній родині з консистентним прямим DNS).

Завдання 8: Перевірте forward-confirmed reverse DNS (FCrDNS)

cr0x@server:~$ host mail.example.com
mail.example.com has address 203.0.113.10

Що це означає: PTR → ім’я, і ім’я → той самий IP. Багато приймачів цінують цю симетрію.

Рішення: Якщо це не працює, виправте DNS перед тим, як ганятися за налаштуваннями MTA. Приймачі використовують це як підказку довіри.

Завдання 9: Подивіться, що Postfix думає про ваше ім’я/HELO

cr0x@server:~$ sudo postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name|smtp_helo_timeout|smtp_host_lookup|inet_protocols)'
myhostname = mx1.internal
mydomain = internal
inet_protocols = all

Що це означає: Ваш myhostname — внутрішнє ім’я, і ви не встановили smtp_helo_name. Postfix може використовувати $myhostname як EHLO. Ось як ви починаєте говорити «hi, I’m mx1.internal» Gmail.

Рішення: Встановіть myhostname на публічний FQDN або задайте smtp_helo_name на публічний FQDN, який використовується для вихідних привітань (часто безпечніше, коли внутрішня іменна політика має залишатися).

Завдання 10: Застосуйте безпечне виправлення EHLO для Postfix (і перевірте)

cr0x@server:~$ sudo postconf -e 'smtp_helo_name = mail.example.com'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf smtp_helo_name
smtp_helo_name = mail.example.com

Що це означає: Вихідний SMTP тепер має використовувати mail.example.com для EHLO.

Рішення: Негайно повторно протестуйте віддаленою SMTP-сесією (Завдання 3) і спостерігайте за змінами політики відповіді.

Завдання 11: Підтвердіть налаштування HELO в Exim (якщо ви використовуєте Exim)

cr0x@server:~$ sudo exim -bP helo_data
helo_data = 

Що це означає: Явного перевизначення HELO немає. Exim у багатьох налаштуваннях виводить його з системного hostname.

Рішення: Якщо системне ім’я хоста внутрішнє або нестабільне, задайте постійний helo_data на публічний FQDN і переконайтеся, що DNS відповідає.

Завдання 12: Перевірте, чи системний hostname вам не шкодить

cr0x@server:~$ hostname -f
mx1.internal

Що це означає: ОС вважає свій FQDN внутрішнім. Багато MTA за замовчуванням використовують це для привітань, якщо його не перевизначено.

Рішення: Або виправте FQDN хоста на публічне ім’я (якщо доречно), або явно налаштуйте ім’я helo в MTA для вихідного трафіку.

Завдання 13: Переконайтеся, що ви не саботуєте себе банером (banner vs EHLO)

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_banner|myhostname)'
myhostname = mx1.internal
smtpd_banner = $myhostname ESMTP

Що це означає: Ваш вхідний банер рекламує mx1.internal. Це не те саме, що EHLO, але це ще одна поверхня ідентичності. Дехто з приймачів і сканерів корелює ці сигнали, коли ваш сервер діє як клієнт десь ще (реле, smarthost-послідовності).

Рішення: Якщо цей хост доступний із інтернету, виправте myhostname та банер. Якщо він лише вихідний за реле, віддайте пріоритет вихідному EHLO, але уникайте реклами внутрішніх доменів, якщо можливо.

Завдання 14: Підтвердіть, що ви випадково не надсилаєте через IPv6 з ломаним rDNS

cr0x@server:~$ postconf -n | grep inet_protocols
inet_protocols = all

Що це означає: Postfix може використовувати IPv6. Якщо ваша мережа має вихід IPv6, але без PTR для v6-адреси, ви можете отримати тротлінг або блокування, що виглядає «випадковим», бо деякі напрямки віддають перевагу v6.

Рішення: Якщо ви не можете підтримувати IPv6 rDNS і репутацію наразі, розгляньте тимчасове inet_protocols = ipv4, поки не виправите v6 правильно.

Завдання 15: Спостерігайте тиск черги в реальному часі, поки виправляєте ідентичність

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A81C04E*     2199 Fri Jan  3 09:10:12  noreply@example.com
                                         user@gmail.com
                                         (host gmail-smtp-in.l.google.com[142.250.102.26] said: 550 5.7.1 Bad HELO/EHLO (in reply to EHLO command))

Що це означає: Черга явно фіксує відмову віддаленого, пов’язану з EHLO. Це корінна причина в чистому вигляді.

Рішення: Виправте EHLO, а потім вибірково промийте чергу. Не чистіть бездумно — вашим користувачам потрібна їхня пошта.

Завдання 16: Після виправлення змусьте повторну спробу і підтвердіть прийняття

cr0x@server:~$ sudo postqueue -f
cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan 03 09:22:10 mx1 postfix/smtp[24511]: 3F2A81C04E: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=716, delays=715/0.01/0.2/0.3, dsn=2.0.0, status=sent (250 2.0.0 OK  1704273730 a1-20020a170902d1c100b003d7f9c0d1a9si1234567plb.123 - gsmtp)

Що це означає: Повідомлення прийняте (2.0.0). Ймовірно, ваше виправлення спрацювало. Велика затримка відображає час, який повідомлення провело в невдачах перед корекцією.

Рішення: Моніторьте стійке покращення: глибину черги, рівні відкладань по доменах і кількість скарг. Один успішний відправ — це ще не тренд.

Типові помилки: симптом → корінь → виправлення

1) Симптом: Gmail відкидає з «Bad HELO/EHLO»

Корінь: EHLO — localhost, внутрішній домен або недійсний (без крапки, без DNS).

Виправлення: Налаштуйте вихідний HELO/EHLO на публічний FQDN, яким ви володієте (Postfix: smtp_helo_name; Exim: helo_data), і переконайтеся, що він розв’язується.

2) Симптом: Microsoft 365 приймає частково, потім сильно відкладає (4xx)

Корінь: Неконсистентна ідентичність: EHLO змінюється в пулі вузлів/IP або EHLO не збігається з PTR/репутацією.

Виправлення: Стандартизувати EHLO для всього пулу відправників і вирівняти зворотний DNS для кожного IP. Якщо ви використовуєте кілька вихідних IP, для кожного має бути адекватний PTR у тій самій доменній родині.

3) Симптом: Доставляність була нормальна тижнями, потім раптово сповільнилася після перебудови

Корінь: Новий образ/шаблон повернув hostname до localhost.localdomain або змінив поведінку cloud-init. MTA тепер вітає некоректно.

Виправлення: Задокументуйте HELO у системі керування конфігурацією. Додайте інтеграційний тест після розгортання, який говорить SMTP і перевіряє рядок EHLO.

4) Симптом: Тільки деякі напрямки падають, інші в порядку

Корінь: Провайдери мають різну суворість щодо HELO; дехто поблажливий, дехто ні. Або ви використовуєте dual-stack і лише шлях IPv6 не працює.

Виправлення: Перевірте логи по доменах і підтвердіть, яка сімейство IP використовується. Якщо IPv6 — проблема, виправте v6 rDNS або тимчасово примусьте IPv4.

5) Симптом: Приймач каже «HELO name does not resolve»

Корінь: Ваше ім’я EHLO не має запису A/AAAA або split-horizon DNS робить його доступним лише внутрішньо.

Виправлення: Опублікуйте публічний DNS для імені EHLO. Не використовуйте внутрішню зону як зовнішню ідентичність SMTP.

6) Симптом: Приймачі скаржаться на «invalid hostname» навіть з FQDN

Корінь: Ви використали підкреслення, заборонені символи або ім’я, що порушує правила hostname.

Виправлення: Використовуйте просте DNS-ім’я: літери, цифри, дефіси, крапки. Без підкреслень. Будьте нудними.

7) Симптом: Ви «виправили» EHLO, але тротлінг лишається

Корінь: Репутація IP була пошкоджена або PTR/TLS/SPF все ще неконсистентні. HELO був лише однією з кількох санкцій.

Виправлення: Перевірте rDNS і узгодженість TLS-імен, потім оцініть SPF/DKIM/DMARC і шаблони відправлення. Очікуйте період прогріву, якщо ви змінили сигнали ідентичності нещодавно.

8) Симптом: Все працює з одного вузла, з іншого — ні

Корінь: Вузли пулу мають різні конфіги: hostname, параметри MTA, NAT egress або поведінку DNS-різолвера.

Виправлення: Сприймайте конфігурацію ідентичності MTA як невідмінну інфраструктуру. Аудитуйте всі вузли, порівняйте конфіги і забезпечте примусове виконання через CI/CD.

Три корпоративні міні-історії з поштових польових умов

Міні-історія 1: Інцидент через неправильне припущення

Середня SaaS-компанія перенесла вихідну пошту з кількох вручну керованих VM на невеликий пул з автоскейлінгом.
Команда зробила великі правильні речі: підпис DKIM, оновлення SPF, політика DMARC у режимі моніторингу, моніторинг черги.
Вони припустили, що привітання — «лише косметика». Воно не було.

Нові образи мали жорсткі налаштування: гарні системні настройки, закритий SSH, адекватні логи.
Але образ також ставив hostname в ідентифікатор інстансу. Postfix підібрав це. Пул представляв себе світу
як ip-10-2-3-4 і іноді localhost залежно від часу завантаження і cloud-init.

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

On-call намагався лімітувати швидкість, додав більше вузлів і спостерігав, як черга зростає — бо масштабування misconfiguration перетворює баг у стиль життя.
Зрештою хтось підключився і подивився сирий SMTP-транскрипт і побачив EHLO. Виправлення зайняло п’ять хвилин. Тур вибачень — два дні.

Урок не в тому, щоб «читати RFC». Він простіший: ніколи не припускайте, що поверхні ідентичності — косметика. У пошті «косметичні» сигнали часто — єдині сигнали, які бачать приймачі.

Міні-історія 2: Оптимізація, що відкотилася назад

Фінансова компанія хотіла вищої пропускної здатності для термінових виписок і сповіщень. Їхня команда налаштувала паралельність і pipelining,
і розгорнула кілька вихідних IP для розподілу навантаження. На папері: гарна інженерія.

Потім вони «оптимізували» HELO, зробивши його унікальним для кожного вузла, думаючи, що це допоможе з налагодженням. Кожен сервер вітався як
mx-out-01.example.com, mx-out-02.example.com тощо. Вони забули неприємну деталь: зворотний DNS оновлено лише для половини IP,
а деякі EHLO-імена навіть ще не існували в публічному DNS.

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

Справжня історія була в тому, що вони збільшили варіативність ідентичності одночасно з ростом обсягу відправлень. Це саме те, коли провайдери підкручують гайки.
Більше IP і більше EHLO-імен збільшили шанси розбіжностей.

Остаточне виправлення було непривабливе: зменшити набір HELO до одного стабільного імені, вирівняти PTR для кожного вихідного IP і розгорнути зміни з канаркою.
«Оптимізація» для налагодження ускладнила систему, бо приймаюча сторона почала трактувати їх як непослідовних відправників.

Міні-історія 3: Нудна, але правильна практика, що врятувала

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

В один квартал їм довелося поміняти вихідні IP через зміну мережевого провайдера. Тут організації часто розпадаються:
PTR змінюються довго, стара репутація IP зникає, і порада «просто оновіть DNS» не завжди достатня.

У них був чекліст, де вирівнювання HELO було первинним пунктом: нові IP отримали PTR, що вказували на mail.example.org,
прямий DNS вже показував це ім’я на потрібний IP, і Postfix мав зафіксований smtp_helo_name.
Також був канар: одне низьковагове реле спробувало новий маршрут першим.

Коли один провайдер почав відкладати трафік канарки, вони вчасно виявили проблему, обмежили зону ураження і тимчасово зменшили паралельність
для того напрямку, поки репутація не відновилася. Головний пул ніколи не досяг кризової черги.

Їхня «нудна» практика просто трактувала ідентичність SMTP як контракт інтерфейсу, а не як пропозицію. Це не запобігло всьому болю, але зробило його контрольованим.

Жарт №2: Доставляність електронної пошти — як сантехніка: ніхто не хоче її оплачувати, але всі помічають, як тільки щось смердить.

Контрольні списки / покроковий план (безпечне розгортання)

Покроковий план: виправлення HELO/EHLO без створення ще одного інциденту

1. Виберіть одне вихідне ім’я ідентичності.
   • Використовуйте стабільний FQDN, яким ви контролюєте, наприклад mail.example.com або smtp.example.com.
   • Уникайте імен на вузол, якщо у вас немає сильної причини і не менш сильної гігієни DNS.
2. Переконайтеся, що ім’я резолвиться публічно.
   • Опублікуйте A (і AAAA, якщо відправляєте по IPv6) для вибраного імені.
   • Не покладайтеся на split-horizon DNS для інтернетної ідентичності.
3. Вирівняйте зворотний DNS для кожного вихідного IP.
   • Встановіть PTR на hostname у вашій доменній родині.
   • Надавайте перевагу PTR, що точно відповідає вашому EHLO, або принаймні співпадає з простором імен вашого домену.
4. Явно налаштуйте вихідний HELO в MTA.
   • Postfix: встановіть smtp_helo_name.
   • Exim: встановіть helo_data (і перевірте по транспортам, якщо потрібно).
5. Аудитуйте консистентність пулу.
   • Порівняйте postconf -n між вузлами.
   • Підтвердіть, що жоден вузол не використовує інший резолвер або пошуковий домен, що змінює поведінку резолвінгу hostname.
6. Запустіть канарку змін.
   • Перенаправте невеликий відсоток вихідної пошти через один вузол або один вихідний IP з виправленим HELO.
   • Спостерігайте відкладання і відмови по доменах призначення.
7. Розгортайте поступово, потім обережно промивайте черги.
   • Після виправлення можна виконати postqueue -f, але майте на увазі ліміти: ви можете раптово перевантажити провайдерів і отримати новий тротлінг.
   • Розгляньте поступове промивання за напрямками, якщо обсяги великі.
8. Додайте регресійний тест.
   • У CI або після розгортання проведіть SMTP-розмову з тестовим отримувачем, що перевіряє рядок EHLO.
   • Нехай збірка падає, якщо EHLO містить localhost або внутрішній суфікс.

Операційний чекліст: як виглядає «добре»

• EHLO — дійсний FQDN, стабільний під час повторних спроб і між вузлами.
• EHLO має публічні записи A/AAAA.
• Вихідний IP має PTR, що є адекватним і бажано вирівняним з EHLO.
• Ім’я PTR резолвиться назад на вихідний IP (FCrDNS).
• Ім’я в TLS-сертифікаті узгоджується з ідентичністю пошти (особливо якщо ви самі термінуєте TLS).
• Логи зберігають віддалені рядки відповіді для відмов/відкладань (щоб бачити «Bad HELO», а не «delivery failed»).
• Моніторинг черги включає рівні відкладань по призначенню (бо «розмір черги» сам по собі брехун).

Питання й відповіді

1) HELO/EHLO — це те саме, що домен у заголовку «From:»?

Ні. HELO/EHLO — це привітання SMTP-клієнта. «From:» — це заголовок повідомлення, який бачать користувачі.
Приймачі корелюють багато ідентичностей, але це різні шари і вони можуть відрізнятися легітимно (реле, сторонні відправники тощо).

2) Якщо у мене є SPF/DKIM/DMARC, чи можу я ігнорувати HELO/EHLO?

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

3) Що мені встановлювати як EHLO в Postfix?

Зазвичай одне стабільне FQDN, наприклад mail.example.com. В Postfix встановіть smtp_helo_name на це значення.
Переконайтеся, що воно публічно розв’язується і збігається з PTR вашого вихідного IP.

4) Чи має EHLO точно збігатися зі зворотним DNS?

«Повинно» залежить від вашого середовища, але точний збіг — найменш контроверсійний вибір.
Якщо не можете зробити тотожним (багато IP, обмеження провайдера), тримайте в тій самій доменній родині і зберігайте консистентність DNS.

5) Чи можна використовувати IP у HELO/EHLO?

Уникайте цього. Деякі системи приймають літерали адреси в дужках, але багато приймачів трактують це підозріло.
Використовуйте дійсний FQDN з правильним DNS замість цього.

6) Мої хости мають внутрішні імена за політикою. Можу їх зберегти?

Можете зберегти OS-hostname внутрішнім і при цьому представляти публічний EHLO для вихідного SMTP, явно налаштувавши його в MTA.
Це часто найчистіший компроміс між внутрішньою політикою і зовнішньою доставляністю.

7) Чому це «вламалося» раптово, якщо було неправильно місяцями?

Бо приймачі змінюють скоринг, ваші патерни трафіку змінюються, і репутація IP змінюється. Невелика санкція стає вирішальною, коли інші сигнали погіршуються.
Також: зміни інфраструктури (нові образи, новий NAT, ввімкнення IPv6) можуть непомітно змінити рядок привітання.

8) Чи важливий мій smtpd_banner для вхідного SMTP?

Так, особливо якщо ваш сервер доступний з інтернету. Банер, що рекламує localhost або внутрішні імена, виглядає непрофесійно і може вплинути на ставлення інших MTA.
Це не те саме, що вихідний EHLO, але це частина публічної ідентичності вашого поштового сервера.

9) Чи впливає HELO/EHLO на TLS?

Опосередковано. Деякі приймачі корелюють ім’я EHLO з іменами сертифікатів TLS і поведінкою SNI.
Невідповідності додаються. Ви хочете послідовну історію: ім’я, DNS, IP і сертифікат не повинні суперечити одне одному.

10) Якщо я використовую стороннє реле (smarthost), чи це важливо?

Так, але інакше. Якщо ви передаєте пошту реле, їхній EHLO і репутація IP контролюють доставляння остаточним отримувачам.
Ваш ризик зміщується на SMTP-сесію між вами і реле: переконайтеся, що ви пред’являєте адекватну ідентичність і не тригерите їхні політики.

Висновок: кроки, які можна відправити цього тижня

HELO/EHLO не привабливі. Це один рядок тексту. І він може абсолютно зіпсувати вам тиждень.
Провайдери читають його як сигнал компетентності. Коли ви надсилаєте «EHLO localhost», ви кажете їм, що ваша інфраструктура або погано керована, або скомпрометована.
Вони реагують відповідно: тротлінг, відкладення, відмова.

Практичні кроки:

1. Виберіть стабільний вихідний FQDN для EHLO і переконайтеся, що він публічно розв’язується.
2. Вирівняйте PTR для кожного вихідного IP і підтвердіть forward-confirmed reverse DNS, де можливо.
3. Явно налаштуйте EHLO у вашому MTA (не покладайтеся на системний hostname за замовчуванням).
4. Запустіть канарку і спостерігайте відкладання/відмови по призначеннях перед повним розгортанням.
5. Додайте регресійний тест, щоб наступна перебудова не занесла «localhost» у продакшн-пошту.

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