Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

Переменный путь возврата конверта ( VERP ) - это метод, используемый некоторым программным обеспечением электронных списков рассылки для автоматического обнаружения и удаления недоставленных адресов электронной почты . Он работает с использованием другого пути возврата (также называемого «отправителем конверта») для каждого получателя сообщения.

Мотивация [ править ]

Любой долговечный список рассылки в конечном итоге будет содержать адреса, с которыми невозможно связаться. Адреса, которые когда-то были действительными, могут стать непригодными для использования, потому что человек, получающий почту, перешел на другого поставщика . В другом сценарии адрес может все еще существовать, но быть заброшенным, а непрочитанная почта накапливается до тех пор, пока не останется достаточно места для приема.

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

Однако большинство рикошетов исторически создавались для чтения пользователями-людьми, а не автоматически обрабатывались программным обеспечением. Все они передают одну и ту же основную идею («сообщение от X до Y не могло быть доставлено по причине Z»), но с таким количеством вариаций, что было бы почти невозможно написать программу, которая бы надежно интерпретировала значение каждого сообщения о недоставке. RFC 1894 (устаревший в RFC 3464) определяет стандартный формат для решения этой проблемы, но поддержка этого стандарта далеко не универсальна. Однако существует несколько распространенных форматов (например, RFC 3464, qsbmf qmail и формат DSN Microsoft для Exchange ), которые покрывают большую часть отказов.

Microsoft Exchange может иногда возвращать сообщение без указания адреса, на который было отправлено исходное сообщение. Когда Exchange знает предполагаемого получателя, но не желает принимать от него электронную почту, он пропускает их адрес. Если сообщение отправлено, [email protected]и сервер знает, что это «Пользователь Джо», он возвратит сообщение о том, что сообщение «Пользователю Джо» не может быть доставлено, при этом [email protected]адрес будет полностью пропущен. VERP - единственный жизнеспособный способ правильно обрабатывать такие отскоки.

Как VERP решает проблему обработки отказов [ править ]

Сложная часть обработки отказов - сопоставление сообщения о недоставке с недоставленным адресом, который вызвал отказ. Если программа списка рассылки видит, что отказ был результатом попытки отправить сообщение на адрес [email protected] , то ему не нужно понимать остальную информацию в сообщении о недоставке . Он может просто подсчитать, сколько сообщений было недавно отправлено на [email protected] , и сколько в результате было возвращено сообщений, и, если доля отклоненных сообщений слишком высока, адрес удаляется из списка.

Хотя форматы рикошетов в целом сильно различаются, есть один аспект рикошета, который очень предсказуем: адрес, на который оно будет отправлено . VERP в полной мере использует это. В списке рассылки, который использует VERP, для каждого получателя используется свой адрес отправителя.

Диспетчер списков рассылки знает, что он отправил сообщение от X к Y, поэтому, если сообщение о недоставке получено на адрес X, это может быть только потому, что адрес Y был недоставлен, потому что ничего не было отправлено с X на любой другой адрес. Таким образом, важная информация была извлечена из сообщения о недоставке, без какой-либо необходимости понимать его содержимое, а это означает, что лицу, ответственному за список, не нужно обрабатывать его вручную.

Происхождение [ править ]

Первым серьезным сторонником этого решения и создателем термина VERP для его описания был Дэниел Дж. Бернстайн , который первым применил эту идею на практике в своем диспетчере списков рассылки qmail MTA и ezmlm . [1]

Пример [ править ]

Предположим, что существует названный список рассылки [email protected]и что на [email protected]него подписалось отдельное лицо, но позже Боб покинул example.org, поэтому его адрес больше не действителен. Подумайте, что происходит, когда кто-то отправляет сообщение в список.

Без VERP [ править ]

Без VERP менеджер списков рассылки мог бы отправить сообщение со следующими характеристиками:

Это приведет к отказу, сгенерированному MTA на example.net или example.org, со следующими характеристиками:

  • отправитель конверта: пустой
  • получатель: [email protected]
  • content: example.org не удалось доставить bob следующее сообщение: ...

От менеджера списков рассылки нельзя ожидать, что он поймет содержимое этого возврата, и он не может ничего вывести из адреса получателя, потому что сотни других людей, кроме Боба, также были отправлены сообщениями [email protected].

С VERP [ править ]

С VERP исходное сообщение было бы другим:

Тогда отскок будет более полезным:

  • отправитель конверта: пустой
  • получатель: [email protected]
  • content: example.org не удалось доставить bob следующее сообщение: ...

Из этого сообщения о недоставке менеджер списка рассылки может сделать вывод, что сообщение [email protected]должно быть неудачным.

В этом примере показан простейший возможный метод сопоставления VERP со списком подписчиков: весь адрес получателя включен в путь возврата, при этом знак at заменен знаком равенства, поскольку путь возврата с двумя знаками at будет недопустимым. Возможны другие схемы кодирования.

Программное обеспечение, поддерживающее VERP [ править ]

Недостатки [ править ]

Использование VERP требует, чтобы каждое сообщение отправлялось один раз для каждого получателя, а не один раз каждому принимающему SMTP- серверу. Это связано с ограничением SMTP, который позволяет указывать несколько адресов получателей в одной транзакции, но только один адрес отправителя. Когда в одном домене много подписчиков , список рассылки, не использующий VERP, может объединить несколько доставок в одну транзакцию. Он подключается к соответствующему серверу для домена, дает единственный адрес отправителя, адреса получателя, а затем отправляет содержимое сообщения только один раз.

С другой стороны, список рассылки, использующий VERP, должен многократно отправлять все тело сообщения, что приводит к общему увеличению использования полосы пропускания . Эта неэффективность обычно не считается большой проблемой, особенно пользователями qmail , поскольку qmail всегда отправляет сообщения один раз для каждого получателя, даже когда VERP не используется. Некоторые пакеты смягчают влияние VERP, применяя его выборочно, например, менеджер списков рассылки может использовать VERP только в 1 из 10 рассылок. Таким образом, вы можете получить большую часть жесткого контроля отказов и точной обратной связи VERP, не вызывая каждый раз обработку и сетевые издержки.

Другая проблема с VERP (и с любой схемой автоматической обработки отказов) заключается в том, что в Интернете есть MTA, которые не соответствуют основным стандартам SMTP. VERP зависит от MTA получателей в соответствии с правилом, согласно которому сообщения о недоставке отправляются отправителю конверта . Это было стандартным требованием с момента появления SMTP в 1982 году (см. RFC 821), но до сих пор есть MTA, которые ошибаются, обычно возвращаясь к адресу в From: заголовке .

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

См. Также [ править ]

  • Bounce Address Tag Validation (BATV) - для отказов от backscatter
  • Схема перезаписи отправителя (SRS) - для отказов от пересылки электронной почты и SPF
  • Простой протокол передачи почты (SMTP)
  • проект расширения SMTP для оптимизации VERP

Ссылки [ править ]

  1. ↑ DJ Bernstein qmail , 1 февраля 1997 г.
  2. ^ https://meta.discourse.org/t/handling-bouncing-e-mails/45343
  3. ^ «Доставка электронной почты для ИТ-специалистов. Руководство MailChimp» (PDF) . Mailchimp .
  4. ^ http://compgroups.net/comp.mail.sendmail/sendmail-verp-ruleset/1311680