Сообщение об отказе или просто «возврат» — это автоматическое сообщение от системы электронной почты, информирующее отправителя предыдущего сообщения о том, что сообщение не было доставлено (или возникла какая-то другая проблема с доставкой). Исходное сообщение считается «возвратившимся».
Эта обратная связь может быть немедленной (некоторые из причин, описанных здесь) или, если отправляющая система может повторить попытку, может поступить через несколько дней после окончания этих повторных попыток.
Более формальные термины для сообщения о недоставке включают «Отчет о недоставке» или «Квитанцию о недоставке» (NDR), сообщение [Failed] «Уведомление о статусе доставки» (DSN) или «Уведомление о недоставке» (NDN). [1]
Хотя SMTP является зрелой технологией, насчитывающей более тридцати лет, ее архитектура все больше подвергается нагрузке как от обычной, так и от нежелательной нагрузки. [2] Системы электронной почты были улучшены с помощью систем репутации, привязанных к фактическому отправителю электронной почты, с идеей того, что серверы электронной почты получателя отклоняют электронную почту, если в протоколе используется поддельный отправитель. [3]
Поэтому были созданы два типа отказов электронной почты: жесткие отказы и мягкие отказы . [4] Оба они влияют на репутацию IP отправителя, поскольку поставщики услуг электронной почты (ESP) рассматривают общий показатель отказов как фактор принятия решения при направлении письма в папку «Входящие» пользователя. Вкратце, общий показатель отказов рассчитывается как сумма жесткого показателя отказов и мягкого показателя отказов.
Hard bounces являются постоянными и оцениваются выше с точки зрения повреждения IP отправителя. Hard bounces происходят, когда почтовый сервер отправителя определяет, что существует высокая вероятность того, что получатель недоступен, и, скорее всего, останется таковым. Несколько случаев, когда hard bounces происходят, когда получатели электронной почты оказываются в одной из следующих ситуаций: неверный идентификатор/неправильный домен (например, опечатка в адресе электронной почты или в домене) или их сервер больше не принимает электронные письма. В этом случае удаление адресов электронной почты, которые возвращаются, является обязательным.
Мягкие возвраты являются временными. Возвращенное сообщение, которое испытывает мягкий возврат, может быть повторно доставлено в другое время. [5] Мягкие возвраты происходят, когда у получателя электронной почты либо заполнен почтовый ящик, и, следовательно, нет места для хранения другого электронного письма, либо достигнут предел размера писем, которые ему разрешено получать. Дополнительные ситуации, в которых появляется мягкий возврат, — это блокировка, установленная на электронную почту получателя, чтобы пометить определенного отправителя как отправителя «спама» или занести определенного отправителя в черный список. Более того, временная приостановка электронной почты получателя или временная ошибка на сервере также являются причинами мягкого возврата.
Ошибки могут возникать в нескольких местах при доставке почты. Отправитель иногда может получить сообщение о недоставке от своего собственного почтового сервера, сообщающее о том, что он не смог отправить сообщение, или же от почтового сервера получателя, сообщающего о том, что хотя он принял сообщение, он не может доставить его указанному пользователю. Когда сервер принимает сообщение для доставки, он также принимает на себя ответственность за доставку сообщения о недоставке в случае сбоя доставки.
Когда электронное письмо поступает на сервер назначения для адреса (например, mymail.example при отправке на [email protected] ), может случиться так, что почтовый демон не сможет поместить сообщение в почтовый ящик указанного пользователя, если на жестком диске сервера недостаточно места.
При отправке электронного письма служба, с которой отправляется электронное письмо, может не иметь возможности достичь адреса назначения. В таком случае отправитель получит сообщение о недоставке от своего собственного почтового сервера. Распространенные причины, по которым почтовые серверы не могут достичь адресата:
Пользователи могут получать ошибочные сообщения о недоставке сообщений, которые они на самом деле не отправляли. Это может произойти, в частности, в контексте спама или вирусов электронной почты , когда спамер (отправитель) может подделать сообщение для другого пользователя (предполагаемого получателя спама) и подделывает сообщение, чтобы оно выглядело как сообщение от еще одного пользователя (третьей стороны). Если сообщение не может быть доставлено предполагаемому получателю, то сообщение о недоставке будет «возвращено» третьей стороне вместо спамера. Это называется backscatter .
Если бы почтовый сервер library.example знал, что сообщение будет не доставлено (например, если бы у Джилл не было учетной записи пользователя), то он бы изначально не принял сообщение и, следовательно, не отправил бы отказ. Вместо этого он бы отклонил сообщение с кодом ошибки SMTP. Это оставило бы почтовый сервер Джека ( store.example ) обязанным создать и доставить отказ.
Bounces — это особая форма автоответчика . Автоответы (автоматические ответы) — это письма, отправляемые программой (а не пользователем-человеком) в ответ на полученное письмо и отправляемые на адрес bounce .
Примерами других автоответов являются письма об отпуске , вызовы от спам-фильтрации с вызовом-ответом , ответы от серверов списков и отчеты об отзывах . Эти другие автоответы обсуждаются в RFC 3834: автоответы должны быть отправлены на Return-Pathуказанный в полученном письме адрес, который вызвал автоответ, и этот ответ обычно отправляется с пустым Return-Path; в противном случае автоответчики могут попасть в ловушку, отправляя автоответы туда и обратно. [ необходима цитата ]
отображается Return-Pathв доставленной почте как поле заголовка, вставленное агентом доставки почтыReturn-Path SMTP ( MDA ) (который обычно объединен с агентом передачи почты или MTA ). MDA просто копирует обратный путь в команде SMTP в . MDA также удаляет фиктивные поля заголовка, вставленные другими MTA; это поле заголовка, как правило, гарантированно отражает последний обратный путь, увиденный в команде.MAIL FROMReturn-PathReturn-PathMAIL FROM
Сегодня эти пути обычно сокращаются до обычных адресов электронной почты , поскольку старый SMTP ' source routing ' был устарел в 1989 году; для некоторой исторической справочной информации см. Sender Rewriting Scheme . Одна особая форма пути все еще существует: пустой путь 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]
NDR — это базовая функция SMTP. Как только MTA принял почту для пересылки или доставки, он не может молча удалить («сбросить») ее; он должен создать и отправить сообщение о недоставке отправителю, если пересылка или доставка не удались.
За исключением MDA, все MTA пересылают почту другому MTA. Следующий MTA может отклонить почту с сообщением об ошибке SMTP, например, "user unknown" , "over quota" и т. д. На этом этапе отправляющий MTA должен отклонить сообщение , т. е. сообщить его отправителю. Отказ может возникнуть и без отклоняющего MTA, или, как говорится в RFC 5321:
«Если SMTP-сервер принял задачу по ретрансляции почты и позже обнаружил, что пункт назначения указан неверно или что почта не может быть доставлена по какой-то другой причине, то он ДОЛЖЕН создать сообщение-уведомление о «недоставленной почте» и отправить его отправителю недоставленной почты (как указано в обратном пути)».
Это правило имеет важное значение для SMTP: как следует из названия, это «простой» протокол, он не может надежно работать, если почта тихо исчезает в черных дырах, поэтому для обнаружения и устранения проблем необходимы сообщения об ошибках.
Однако сегодня можно часто получать в основном спам -сообщения, которые обычно используют поддельные Return-Paths. Тогда MTA часто не может сообщить об этом отправителю, а отправка сообщения о недоставке поддельному письму Return-Pathударит по невиновной третьей стороне. Кроме того, есть определенные причины, по которым предпочтительнее молча отклонить сообщение, а не отклонять его (не говоря уже о том, чтобы вернуть ):
Снова цитируем RFC 5321, раздел 6.2:
«Как обсуждалось в Разделе 7.8 и Разделе 7.9 ниже, сброс почты без уведомления отправителя на практике разрешен. Однако это чрезвычайно опасно и нарушает давнюю традицию и ожидания сообщества, что почта либо доставляется, либо возвращается. Если скрытое сброс сообщений используется не по назначению, это может легко подорвать доверие к надежности почтовых систем Интернета. Поэтому скрытое сброс сообщений следует рассматривать только в тех случаях, когда есть очень высокая уверенность в том, что сообщения являются серьезно мошенническими или иным образом ненадлежащими».
Отсутствие проверки отправителя является неотъемлемым недостатком сегодняшнего SMTP, в котором отсутствуют устаревшие исходные маршруты, упомянутые ранее. Это решается различными предложениями, наиболее прямо BATV и SPF .
Существует множество причин, по которым электронное письмо может возвращаться. Одна из причин — неправильно написанный адрес получателя или его просто нет в принимающей системе. Это неизвестное пользователю состояние. Другие причины включают истощение ресурсов, например, полный диск, или отклонение сообщения из-за спам- фильтров. Кроме того, существуют MUA , которые позволяют пользователям «возвращать» сообщение по требованию. [7] Эти инициированные пользователем возвраты являются фиктивными возвратами; по определению, настоящий возврат автоматизирован и выдается MTA или MDA.
Сообщения о недоставке в SMTP отправляются с адресом отправителя конверта <>, известным как нулевой адрес отправителя . Они часто отправляются с From:адресом заголовка MAILER-DAEMONна сайте получателя.
Как правило, сообщение о недоставке содержит несколько фрагментов информации, которые помогут первоначальному отправителю понять причину, по которой его сообщение не было доставлено:
RFC 3463 описывает коды, используемые для указания причины возврата. Распространенные коды: 5.1.1 (Неизвестный пользователь), 5.2.2 (Почтовый ящик заполнен) и 5.7.1 (Отклонено политикой безопасности/почтовым фильтром).
Формат отчетов об административных сообщениях определен в RFC 6522. DSN может быть сообщением MIME multipart/report, состоящим из трех частей:
Вторая часть DSN также вполне читаема. Важно понимать, какой MTA какую роль сыграл. Reporting -MTA отвечает за составление и отправку DSN.
Когда Remote-MTA отклоняет сообщение во время транзакции SMTP, поле Diagnostic-Code типа smtp может быть использовано для сообщения этого значения. Обратите внимание, что помимо числового 3-значного значения, ответ SMTP содержит часть, удобочитаемую для человека. Информация
Remote-MTA: dns; smtp.store.example [ 192.0.2.3 ] Диагностический код: smtp; 550 Такого пользователя здесь нет при обращении к smtp.store.example [192.0.2.3]>>> RCPT TO:<[email protected]><<< 550 Такого пользователя здесь нет
{{cite journal}}: Цитировать журнал требует |journal=( помощь )Другой способ борьбы со спамом — возвращать им почту. Это создает видимость того, что вашей учетной записи не существует, и, если вам повезет, ваше имя будет удалено из их списков., и Брин, Кристофер (2006-01-27). "Bouncing the creeps". Macworld . Получено 2008-10-02 .
Как вы, вероятно, знаете, использование команды Bounce в Mail (Сообщение > Bounce) неэффективно против спамеров, поскольку почти весь спам, который вы получаете, содержит поддельный адрес "от".