Кратко

  • RFC 2369 в июле 1998 года позволил указывать путь отписки в заголовке письма. Если одного обращения к URL хватало для удаления подписки, сервер не отличал автоматическую проверку от решения читателя.
  • RFC 8058 в январе 2017 года добавил List-Unsubscribe-Post: List-Unsubscribe=One-Click. Действительная подпись DKIM должна охватывать обе строки отписки; программа получателя обязана дождаться согласия пользователя перед HTTPS POST.
  • POST содержит только заданную пару ключа и значения, без cookie и HTTP-авторизации. Серверу запрещено отвечать перенаправлением HTTPS. Новая строка внесена в реестр IANA.

Посещение приняли за голос

Первоначальное решение было полезным. RFC 2369 дал рассылке место для объявления выхода. Почтовая программа могла показать List-Unsubscribe, не заставляя читателя искать ссылку внизу длинного письма. В поле допускался адрес HTTPS. Дверь стало легко найти. Но сам адрес не сообщал, кто впоследствии его откроет — человек, решивший уйти, или программа, проверяющая письмо.

Программы безопасности тоже посещают адреса. RFC 8058 описывает антиспам-средства, которые без участия пользователя автоматически получают ресурсы из почтовых заголовков. Если сервер завершал отписку при обычном посещении URL, проверка становилась удалением. По одному входящему запросу сервер не мог механически различить фоновую работу и действие человека. Инструмент защиты ящика мог удалить его владельца из списка.

Страницы подтверждения сдерживали ошибку. Сканер открывал страницу, но не нажимал следующую кнопку; человек мог закончить действие. От случайного удаления защищались ценой дополнительного шага для того, кто действительно хотел уйти. Причина заключалась в том, что адрес, предназначенный для просмотра, одновременно считали разрешением изменить запись.

Новый заголовок назвал действие

RFC 8058 сохранил прежнее поле и добавил отдельный знак для отписки одним действием. Отправитель помещает URI HTTPS в List-Unsubscribe, а ровно List-Unsubscribe=One-Click — в List-Unsubscribe-Post. После согласия читателя принимающая программа отправляет на URI запрос HTTPS POST с этой парой в теле. Получение адреса для проверки и POST для изменения подписки различаются самим методом HTTP.

Отправитель должен также наложить действительную подпись DKIM на оба поля и включить их в список h= подписи. Тогда адрес отписки и описание операции входят в одну проверяемую часть письма. Если требуемой подписи нет, принимающая программа не должна предлагать отписку одним действием. Подпись подтверждает заявление отправителя, а не желание читателя.

Желание имеет собственное правило. Получатель не вправе отправлять POST без согласия пользователя. Как именно интерфейс его получает, RFC не устанавливает. Оператор рассылки предлагает и подписывает действие; почтовая программа показывает выбор и отправляет запрос; читатель решает. Фоновая проверка ссылки не занимает место ни одного из них.

Сервер должен закончить дело по объявленному адресу

В теле POST находится одна предписанная пара. Запрос не несёт cookie, HTTP-авторизации или иного контекста. Поэтому сам URI должен достаточно точно определять и список, и получателя, которого нужно удалить. RFC советует непрозрачный идентификатор, который трудно угадать. Если сервер ждёт браузерную сессию, он не выполнит стандартный запрос почтовой программы.

Перенаправлять этот POST на другой адрес HTTPS сервер тоже не может. RFC называет практическую причину: в прошлом перенаправленные POST работали ненадёжно, а браузеры иногда превращали их в GET. Если переложить решающий шаг на цепочку переходов, граница между проверкой и командой может исчезнуть по дороге. Сервер обязан обработать согласованный запрос там, где обещал.

RFC 8058 не переписывает остальные способы использования адресов отписки из RFC 2369. Он отмечает особый маршрут для операции одним действием. IANA зарегистрировала List-Unsubscribe-Post. Но имя в реестре само по себе никого не удаляет: нужна цепочка подписи, согласия, POST и работающего сервера.

Выход состоит не из одной ссылки

Оператор рассылки контролирует подписанное предложение и сервер. Почтовая программа контролирует отображение и момент запроса. Читатель контролирует решение. Автоматический осмотр остаётся осмотром. Именно такое разделение обязанностей принесло короткое дополнение 2017 года. Если хотя бы звено подменено, выход превращается в машину случайных отписок или в бесполезную кнопку.

Три официальных документа подтверждают правило и регистрацию нового поля. Чтобы установить его применение у конкретной почтовой службы, потребовались бы датированные исходные письма, инструкции принимающей программы и журналы сервера. Исторический вывод точен: Сеть позволила программам легко открывать ссылки, поэтому почте пришлось определить, какое открытие считается приказом.