Чому лист, який ви переслали собі, потрапив у спам — редакційна ілюстрація

read receipts

Чому лист, який ви переслали собі, потрапив у спам

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

·3 хв

Налаштуйте автоматичне перенаправлення зі старого облікового запису на новий — і частина листів тихо зникне у спамі не тому, що ваш провайдер несправний, а тому, що перенаправлення змінює того, хто надсилає повідомлення, без змін криптографічного доказу. SPF перевіряє невірний сервер, рішення DMARC змінюється на fail, і легітимний лист, який ви надіслали самому собі, потрапляє на карантин. Рішення має назву: ARC, визначений у RFC 8617 ще у 2019 році.

Чому перенаправлення змушує мій лист не пройти SPF?

Тому що SPF перевіряє останній сервер, що передав повідомлення, а перенаправлення змінює цей сервер. SPF — Sender Policy Framework — це DNS-запис, у якому вказані IP-адреси, яким дозволено надсилати листи для домену. Коли bank.com надсилає вам квитанцію, приймаючий сервер перевіряє: чи прийшло це з IP-адреси, авторизованої bank.com? Так. Пройдено.

Тепер перенаправте цю квитанцію з Gmail на вашу нову адресу. Сервери Google передають її далі. Фінальний приймаючий сервер запускає перевірку SPF і запитує: чи авторизований Google надсилати листи для bank.com? Ні, не авторизований. SPF не пройдено. У документації Google Workspace про це прямо сказано — перенаправлені листи не проходять SPF, тому що сервер перенаправлення не перебуває в SPF-записі вихідного домену. Нічого не було підроблено. Перевірка просто дивиться на невірний хіп.

Отже, чому це надсилає лист у спам?

DMARC. Раніше SPF, що не пройшло, можна було пережити; DMARC перетворив це на рішення. DMARC поєднує SPF і DKIM й повідомляє одержувачам, що робити, коли обидва не пройдені: нічого, карантин або відхилення. До 2024 року великі надавачі не мали вибору — Google та Yahoo почали вимагати DMARC у всіх, хто надсилає більше 5000 повідомлень на день своїм користувачам.

DKIM, другий стовп, — це підпис, вбудований у повідомлення. Теоретично він пережити перенаправлення, тому що підписує вміст, не маршрут. На практиці все, що торкається повідомлення, його ламає. Список розсилки, який додає нижній колонтитул «ви підписані, відписатися тут», сервер, який переписує тему, навіть зміна способу переносу рядків — підпис більше не збігається, і DKIM теж не пройдено. Тепер обидва стовпи впали, DMARC говорить fail, і ваша квитанція в папці «Спам».

Що таке ARC і справді це це виправляє?

ARC — Authenticated Received Chain, RFC 8617 — дозволяє чесному перенаправляльнику засвідчити, що лист пройшов автентифікацію до того, як він його торкнув. Сервер перенаправлення ставить на повідомлення запечатаний запис, який говорить «коли це прийшло до мене, SPF і DKIM були чинні — довіряйте моєму слову щодо ділянки, яку ви не можете перевірити». Фінальний одержувач, якщо він довіряє цьому перенаправляльнику, може переобирати DMARC fail і доставити лист.

Мінус у словах «якщо він довіряє». ARC — це не пароль; це система репутації. Одержувач зважує, чи є ущільнювач ARC відомим, добре поведеним оператором. Google як ставить заголовки ARC, так і поважає їх від надавачів, яким він довіряє, і саме тому перенаправлення з Gmail на Gmail зазвичай уникне карантину, а перенаправлення через якийсь древній університетський реле — ні.

Якщо ви самі керуєте перенаправленням, два конкретних кроки допомагають. Використовуйте Server-Side Redirect / переписування стилю SRS, якщо ваш хост це пропонує, що переписує адресу конверта так, щоб SPF перевіряв ваш перенаправляльник замість вихідного домену. І віддавайте перевагу перенаправленню між провайдерами, які обидва підтримують ARC. Якщо ви консолідуєте облікові записи й хочете, щоб адреса призначення просто розібралась з проблемами автентифікації для вас, це саме той вид сантехніки, для якої побудована платформа AI для електронної пошти.

Коли мені припинити звинувачувати свого провайдера?

Коли закономірність такова: «не проходять тільки перенаправлені листи», провайдер роботу свою виконує правильно — проблема в протоколі. Ось указівка: відкрийте заголовки втраченого повідомлення й шукайте рядок Authentication-Results. Якщо ви бачите spf=fail поряд з IP надавача, що належить перенаправляльнику, а не вихідному надавачу, то SPF перевіряє невірний хіп. Якщо dkim=fail з'являється на листах, що пройшли через список чи реле, які редагують повідомлення, то це пошкоджений підпис, а не підробка.

Невтішна правда в тому, що автентифікацію електронної пошти прибивали шар за шаром протягом двох десятиліть до системи, яка ніколи не припускала, що хтось буде брехати. SPF прийшов у 2006 році, DKIM у 2007 році, DMARC у 2015 році, ARC у 2019 році — кожен один латав дірку, яку попередній відкрив. Перенаправлення — це шов, де всі чотири терлись один об одного, а ваша скринька — це місце, де ви відчуваєте це тертя.

daily messages that trigger Google & Yahoo's DMARC requirement (2024)

Джерела

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← Усі матеріали