Сообщение о возврате

Сообщение о возврате или просто «возврат» — это автоматическое сообщение от системы электронной почты, информирующее отправителя предыдущего сообщения о том, что сообщение не было доставлено (или возникла какая-либо другая проблема с доставкой). Говорят, что исходное сообщение «отскочило».

Этот отзыв может быть немедленным (некоторые из причин описаны здесь) или, если отправляющая система может повторить попытку, может поступить через несколько дней после завершения этих повторных попыток.

Более формальные термины для сообщения о возврате включают «Отчет о недоставке» или «Квитанция о недоставке» (NDR), [Не удалось] «Уведомление о статусе доставки» (DSN) или «Уведомление о недоставке» (NDN). ^[1]

Классификация

Хотя SMTP является зрелой технологией, насчитывающей более тридцати лет, ее архитектура все больше перегружается как обычной, так и нежелательной нагрузкой. ^[2] Системы электронной почты были расширены за счет систем репутации, привязанных к фактическому отправителю электронного письма, с идеей, что серверы электронной почты получателя отклоняют электронное письмо, если в протоколе используется поддельный отправитель. ^[3]

Поэтому были созданы два типа возврата электронной почты: жесткий возврат и мягкий возврат . ^[4] Оба они влияют на репутацию IP-адреса отправителя, поскольку поставщики услуг электронной почты (ESP) рассматривают общий показатель отказов как фактор принятия решения при направлении электронного письма в папку «Входящие» пользователя. Вкратце, общий показатель отказов рассчитывается как сумма показателей жестких и мягких отказов.

Жесткие отскоки

Жесткие возвраты являются постоянными и оцениваются выше с точки зрения повреждения IP отправителя. Жесткие возвраты происходят, когда почтовый сервер отправителя определяет, что существует высокая вероятность того, что получатель недоступен и, скорее всего, останется таковым. Некоторые случаи жесткого возврата связаны с тем, что получатели электронного письма оказываются в одной из следующих ситуаций: неправильный идентификатор/неверный домен (например, опечатка в адресе электронной почты или домене) или их сервер не принимает писем больше нет. В этом случае удаление адресов электронной почты, которые возвращаются, является обязательным.

Мягкие отскоки

Мягкие отскоки носят временный характер. Возвращенное сообщение, которое испытывает мягкий возврат, можно попытаться доставить повторно в другое время. ^[5] Мягкие возвраты происходят, когда у получателя электронного письма либо полный почтовый ящик, и, следовательно, нет места для хранения другого электронного письма, либо достигнут предел размера электронных писем, которые ему разрешено получать. Дополнительные ситуации, в которых появляется мягкий отказ, — это блокировка электронной почты получателя, позволяющая пометить определенного отправителя как отправителя «спама» или внести определенного отправителя в черный список. Более того, временная приостановка электронной почты получателя или временная ошибка на сервере также являются причинами мягкого возврата.

Ошибки доставки

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

Отказ из-за нехватки места на диске

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

Отказ из-за недоступности пункта назначения

При отправке электронного письма служба, с которой отправляется электронное письмо, может не достичь адресата назначения. В таком случае отправитель получит сообщение о возврате от своего собственного почтового сервера. Распространенные причины, по которым почтовые серверы не могут достичь места назначения:

Не удалось определить адрес назначения. Например, если доменное имя не существует.
Невозможно установить соединение с адресом назначения. Например, если IP-адрес не назначен серверу или если сервер находится в автономном режиме .

Отказ от поддельного сообщения

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

Другие причины

Если бы почтовый сервер Library.example знал, что сообщение невозможно доставить (например, если бы у Джилл не было там учетной записи пользователя), то он бы не вообще принял сообщение и, следовательно, не отправил бы возврат. Вместо этого он отклонил бы сообщение с кодом ошибки SMTP. Это оставило бы почтовый сервер Джека (в store.example ) обязанностью создавать и доставлять возвраты.

Терминология

Отказы — это особая форма автоответчика . Автоответы (автоматические ответы) — это письма, отправленные программой, а не пользователем-человеком, в ответ на полученное письмо и отправленные на адрес возврата .

Примерами других автоматических ответов являются письма об отпуске , запросы от спам-фильтрации «запрос-ответ» , ответы от серверов рассылок и отчеты об отзывах . Эти другие автоматические ответы обсуждаются в RFC 3834: автоматические ответы следует отправлять на Return-Path указано в полученном письме, которое вызвало автоматический ответ, и этот ответ обычно отправляется с пустым Return-Path; в противном случае автоответчики могут оказаться в ловушке, отправляя автоответы туда и обратно. ^{[ нужна ссылка ]}

The Return-Path виден в доставленной почте как поле заголовка Return-Path SMTP вставляется агентом доставки почты ( MDA ) (который обычно сочетается с агентом передачи почты или MTA ). MDA просто копирует обратный путь в SMTP. MAIL FROM команду в Return-Path. MDA также удаляет поддельные Return-Path поля заголовка, вставленные другими MTA; это поле заголовка обычно гарантированно отражает последний обратный путь, замеченный в MAIL FROM команда.

Сегодня эти пути обычно сводятся к обычным адресам электронной почты , поскольку старая « маршрутизация источника » SMTP устарела в 1989 году; некоторую историческую справочную информацию см. в разделе «Схема перезаписи отправителей» . Еще существует одна особая форма пути: пустой путь. MAIL FROM:<>, используется для многих автоответов и особенно для всех отказов.

Строго говоря, возвраты отправляются с непустым Return-Path неверны. RFC 3834 предлагает некоторые эвристики для выявления неправильных возвратов на основе локальной части (левая часть перед «@») адреса в непустом формате. Return-Pathи даже определяет поле заголовка письма, Auto-Submitted, чтобы идентифицировать автоответы. Но заголовок письма является частью почтовых данных (команда SMTP DATA), а MTA обычно не просматривают почту . Они имеют дело с конвертом , который включает в себя MAIL FROM адрес (он же Return-Path, Envelope-FROMили «обратный путь»), но не, например, RFC 2822- From в поле заголовка письма From. Эти детали важны для таких схем, как BATV .

Остальные отскакивают с пустым Return-Path — это отчеты о недоставке ( NDR ) или уведомления о статусе доставки (DSN). DSN могут быть явно запрошены с помощью расширения службы SMTP, однако оно широко не используется. Явные запросы сведений о сбое доставки гораздо чаще реализуются с помощью пути возврата переменного конверта (VERP), тогда как явные запросы на них реализуются редко. ^[6]

Отчеты о недоставке — это базовая функция SMTP. Как только MTA принял почту для пересылки или доставки, он не может молча удалить («отбросить») ее; он должен создать и отправить сообщение об отказе отправителю, если пересылка или доставка не удались.

Отказ против отклонения

За исключением MDA, все MTA пересылают почту другому MTA. Следующий MTA может отклонить почту с сообщением об ошибке SMTP, например «пользователь неизвестен» , «превышение квоты» и т. д. На этом этапе отправляющий MTA должен отклонить сообщение , т. е. проинформировать его отправителя. Отказ может возникнуть и без отклонения MTA, или, как это сформулировано в RFC 5321:

«Если SMTP-сервер принял задачу пересылки почты, а затем обнаруживает, что пункт назначения неверен или что почта не может быть доставлена по какой-либо другой причине, тогда он ДОЛЖЕН создать сообщение с уведомлением о «недоставленной почте» и отправить его отправителю. недоставленной почты (как указано в обратном пути)».

Это правило важно для SMTP: как следует из названия, это «простой» протокол, он не может надежно работать, если почта бесшумно исчезает в черных дырах, поэтому для обнаружения и устранения проблем необходимы возвраты.

Тихое удаление сообщений

Сегодня, однако, часто можно получать в основном спам -сообщения, в которых обычно используются поддельные письма. Return-Pathс. В этом случае MTA часто не может проинформировать отправителя, и отправка возврата поддельному Return-Path ударит невиновное третье лицо. Кроме того, существуют конкретные причины, по которым предпочтительнее молча удалить сообщение, чем отклонить его (не говоря уже о том, чтобы отклонить его):

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

Цитируем еще раз RFC 5321, раздел 6.2:

«Как обсуждается в разделах 7.8 и 7.9 ниже, удаление почты без уведомления отправителя разрешено на практике. Однако это чрезвычайно опасно и нарушает давнюю традицию и ожидания сообщества о том, что почта либо доставляется, либо возвращается. В случае молчаливого удаления сообщения используется не по назначению, это может легко подорвать доверие к надежности почтовых систем Интернета. Поэтому молчаливое удаление сообщений следует рассматривать только в тех случаях, когда существует очень высокая уверенность в том, что сообщения являются серьезно мошенническими или иным образом неуместными».

Отсутствие проверки отправителя является неотъемлемым недостатком современного SMTP, в котором отсутствуют устаревшие исходные маршруты, упомянутые ранее. Этому способствуют различные предложения, в первую очередь БАТВ и ФГИ .

Причины возврата сообщения

Существует множество причин, по которым электронное письмо может не получиться. Одна из причин заключается в том, что адрес получателя написан с ошибкой или просто не существует в принимающей системе. Это неизвестное пользователю состояние. Другие причины включают исчерпание ресурсов (например, полный диск) или отклонение сообщения из-за спам- фильтров. Кроме того, существуют MUA , которые позволяют пользователям «пересылать» сообщения по требованию. ^[7] Эти отказы, инициированные пользователем, являются фиктивными; по определению реальный отказ автоматизирован и генерируется MTA или MDA.

Сообщения о возврате в SMTP отправляются с адресом отправителя конверта. <>, известный как нулевой адрес отправителя . Их часто отправляют с From: адрес заголовка MAILER-DAEMON на сайте получателя.

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

Дата и время, когда сообщение было отклонено,
Идентификатор почтового сервера, который вернул письмо,
Причина возврата (например, пользователь неизвестен или почтовый ящик переполнен ),
Заголовки возвращенного сообщения и
Часть или все содержимое возвращенного сообщения.

В RFC 3463 описаны коды, используемые для указания причины отказа. Общие коды: 5.1.1 (Неизвестный пользователь), 5.2.2 (Почтовый ящик заполнен) и 5.7.1 (Отклонено политикой безопасности/почтовым фильтром).

Формат

MTA, участвующие в *отклонении* , названы в соответствии с точкой зрения *Reporting MTA* . Имена MTA часто имеют тип *dns* .

Формат представления административных сообщений определяется РФК 6522 . DSN может представлять собой MIME, многочастное сообщение/сообщение отчета состоящее из трех частей:

понятное человеку объяснение;
машинно анализируемое сообщение/статус доставки , список строк «имя: тип; значение» , в которых указаны несколько возможных полей; и
исходное сообщение или его часть как объект типа message/rfc822 .

Вторая часть DSN также вполне читаема. Важно понимать, какой MTA какую роль сыграл. Reporting -MTA отвечает за составление и отправку DSN.

Когда Remote-MTA отклоняет сообщение во время транзакции SMTP, поле Diagnostic-Code типа smtp может использоваться для сообщения об этом значении. Обратите внимание, что помимо числового трехзначного значения ответ SMTP содержит удобочитаемую часть. Информация

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here

иногда сообщается как, например,

while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<[email protected]>
<<< 550 No such user here

См. также

Backscatter (обратное рассеяние спама по электронной почте)
Проверка тега адреса возврата (BATV)
Отслеживание электронной почты
Структура политики отправителей (SPF)
Идентифицированная почта DomainKeys (DKIM)
Схема перезаписи отправителя (SRS)
Простой протокол передачи почты (SMTP)
Переменный путь возврата конверта (VERP)

Связанные RFC

RFC 5321 — Простой протокол передачи почты
RFC 3461 - Расширение службы простого протокола передачи почты (SMTP) для уведомлений о статусе доставки (DSN)
RFC 6522 - Тип носителя Multipart/Report для отчетов об административных сообщениях почтовой системы
RFC 3463 — расширенные коды состояния для SMTP
RFC 3464 — расширяемый формат сообщений для уведомлений о статусе доставки
RFC 3834 — Рекомендации по автоматическим ответам на электронную почту
RFC 5337 — Интернационализированные уведомления о статусе доставки и размещении

Ссылки

^ «Примеры мошеннических нежелательных сообщений электронной почты», Риски безопасности в технологиях социальных сетей , Elsevier, стр. 241–242, 2013 г., doi : 10.1016/b978-1-84334-714-9.50022-x , ISBN 978-1-84334-714-9
^ АферганМайк; БеверлиРоберт (1 января 2005 г.). «Состояние адреса электронной почты». Обзор компьютерных коммуникаций ACM SIGCOMM . 35 : 29–36. дои : 10.1145/1052812.1052822 . S2CID 16604893 .
^ «Противодействие незаконному обороту: обзор мониторинга и правоприменения». 27 сентября 2016 г. doi : 10.18356/0f24bf9f-en . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
^ «Жесткие отказы против мягких отказов и как их убрать | Блог» . bounceremove.com . Проверено 14 мая 2020 г.
^ [1] , «Управление доставкой электронных сообщений с использованием профилей возврата», выпущено 26 мая 2005 г.
^ Стросс, Рэндалл (15 июня 2008 г.). «В ретрансляторе электронной почты не каждая передача обслуживания проходит гладко» . Нью-Йорк Таймс . Проверено 26 апреля 2010 г.
^ Рэй, Уильям; Рэй, Джон (15 июля 2005 г.). «Использование интернет-приложений в Mac OS X Tiger» . Проверено 2 октября 2008 г. Еще один метод борьбы со спамом — возвращать им почту. Это создает видимость того, что вашей учетной записи не существует, и, если вам повезет, ваше имя будет удалено из их списков. , и Брин, Кристофер (27 января 2006 г.). «Подпрыгивающие крипы» . Макмир . Проверено 2 октября 2008 г. Как вы, вероятно, знаете, использование команды Bounce в Mail (Сообщение > Отказ) неэффективно против спамеров, поскольку почти весь спам, который вы получаете, содержит поддельный адрес «от».

Внешние ссылки

[1] «Примеры мошеннических нежелательных сообщений электронной почты», Риски безопасности в технологиях социальных сетей , Elsevier, стр. 241–242, 2013 г., doi : 10.1016/b978-1-84334-714-9.50022-x , ISBN 978-1-84334-714-9

[2] АферганМайк; БеверлиРоберт (1 января 2005 г.). «Состояние адреса электронной почты». Обзор компьютерных коммуникаций ACM SIGCOMM . 35 : 29–36. дои : 10.1145/1052812.1052822 . S2CID 16604893 .

[3] «Противодействие незаконному обороту: обзор мониторинга и правоприменения». 27 сентября 2016 г. doi : 10.18356/0f24bf9f-en . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )

[4] «Жесткие отказы против мягких отказов и как их убрать | Блог» . bounceremove.com . Проверено 14 мая 2020 г.

[5] [1] , «Управление доставкой электронных сообщений с использованием профилей возврата», выпущено 26 мая 2005 г.

[6] Стросс, Рэндалл (15 июня 2008 г.). «В ретрансляторе электронной почты не каждая передача обслуживания проходит гладко» . Нью-Йорк Таймс . Проверено 26 апреля 2010 г.

[7] Рэй, Уильям; Рэй, Джон (15 июля 2005 г.). «Использование интернет-приложений в Mac OS X Tiger» . Проверено 2 октября 2008 г. Еще один метод борьбы со спамом — возвращать им почту. Это создает видимость того, что вашей учетной записи не существует, и, если вам повезет, ваше имя будет удалено из их списков. , и Брин, Кристофер (27 января 2006 г.). «Подпрыгивающие крипы» . Макмир . Проверено 2 октября 2008 г. Как вы, вероятно, знаете, использование команды Bounce в Mail (Сообщение > Отказ) неэффективно против спамеров, поскольку почти весь спам, который вы получаете, содержит поддельный адрес «от».

[1]

[2]

[3]

[4]

[5]

[6]

[7]