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

Для агента пересылки почты (MTA) схема перезаписи отправителя (SRS) - это схема для перезаписи адреса отправителя в конверте электронного сообщения с целью его повторной отправки. В этом контексте повторная рассылка - это своего рода пересылка электронной почты . SRS была разработана для пересылки электронной почты без нарушения структуры политики отправителя (SPF) в 2003 году [1].

Фон [ править ]

В ряде случаев, включая изменение адреса электронной почты и списков рассылки, MTA принимает сообщение электронной почты, которое не предназначено для локального почтового ящика, но требует пересылки. В таких случаях возникает вопрос, кто заслуживает получения любого связанного сообщения о недоставке . Как правило, это либо автор, либо физическое или иное лицо, которое администрирует пересылку. [2] Отправка отказов автору с административной точки зрения проще и раньше выполнялась, просто сохраняя первоначального отправителя конверта. Однако, если на адрес автора распространяется строгая политика SPF (-all), а целевой MTA принудительно его применяет, транзакция пересылки может быть отклонена. В качестве обходного пути можно на лету синтезировать временный адрес возврата, который будет направлять любой возврат к текущему MTA. Схема предусматривает восстановление исходного адреса конверта, так что в случае получения рикошета он может быть переадресован по обратному пути - на этот раз с пустым отправителем конверта.

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

Схема переписывания [ править ]

SRS - это форма пути возврата переменного конверта (VERP), поскольку он кодирует исходный отправитель конверта в локальной части перезаписанного адреса. [1] Рассмотрим example.com пересылки сообщения , первоначально предназначенного для [email protected] в свой новый адрес <[email protected]> :

 ОРИГИНАЛЬНЫЙ отправитель конверта : [email protected]  получатель конверта : [email protected]
 ПЕРЕПИСАНО отправитель конверта : [email protected] получатель конверта : [email protected]

Приведенный выше пример адаптирован из Шевека. [3] Что касается VERP, локальная часть ( алиса ) перемещается после ее доменного имени ( example.org ), дополнительно добавляя префикс ( SRS0), хэш ( HHH ) и метку времени ( TT ). Это отражает операционную разницу: возможные возвраты на адрес VERP обрабатываются в домене перезаписи, а поддельные сообщения могут в лучшем случае отменить подписку некоторых пользователей, что является разновидностью злоупотреблений, которые не видели значительных эксплойтов в последние десятилетия. Вместо этого SRS направлена ​​на повторную отправку возможного возврата к Алисе , чтобы поддельные сообщения возврата могли стать заманчивой техникой для внедрения спама, очевидно исходящего от отправителя, выполняющего перезапись.

  • Локальная часть , в данном случае Алисы , перемещаются , поскольку он может содержать одинаковые знаки (=), так что положить его на оконечности переписано локальной части делает последние оформленным.
  • Метка времени ( TT ) имеет разрешение на один день для того , чтобы сделать адрес недействительным через несколько дней. Компьютерная в Unix времени / (60 × 60 × 24) по модулю 2 10 , он может быть сохранен в качестве двух Base32 символов, с периодом переработки около 3,5 лет.
  • Код аутентификации сообщения на основе хэша ( HHH ) вычисляется на основе локального секрета, но используется только его часть; например, сохранение первых 4 символов представления base64 обеспечивает 24 бита безопасности . Хеш проверяется доменом, который его сгенерировал, в случае получения отказов.
  • Префикс , SRS0, предназначен для устранения неоднозначности регулярных адресов из переписанных из них; именно example.com должен гарантировать, что ни у одного из его пользователей нет адреса электронной почты, начинающегося с SRS0=.

SRS предусматривает другой префикс, SRS1который будет использоваться для перезаписи уже перезаписанного адреса в сценарии с несколькими переходами. Если example.net необходимо переслать сообщение по очереди, он может сэкономить, добавив еще одну метку времени и повторив исходную локальную часть ( Алиса ). То есть каждый новый сервер пересылки добавляет только свой собственный хэш ( HHH ) и доменное имя предыдущего сервера пересылки:

 ДАЛЬШЕ ПЕРЕПИСАНО отправитель конверта : [email protected] получатель конверта : bob@f Further.example

Альтернатива базы данных [ править ]

Использование базы данных определенно может контролировать рост перезаписываемых адресов, поскольку достаточно поместить только уникальный ключ в перезаписываемую локальную часть. Это также обеспечивает определенную анонимность в процессе повторной отправки, если это желательно. Однако база данных требует централизации и является единственной точкой отказа. [4]

Альтернативный вариант поля заголовка [ править ]

Другая возможность - сохранить длинный перезаписанный адрес где-нибудь в заголовке сообщения. Я = бирка DKIM-подписи может быть хорошим местом, так как такой выбор значительно повышает безопасность. Эта техника только что наблюдалась. [5] Если нет механизма резервного копирования, он может работать только в том случае, если рикошет имеет стандартный формат. [6]

Историческая справка [ править ]

Исторически все агенты передачи почты (MTA) добавляли свое имя хоста к обратному пути . В протоколе Simple Mail Transfer Protocol (SMTP) этот обратный путь также известен как MAIL FROM , но пути также использовались до и за пределами SMTP, например, как bang-пути в UUCP и Usenet (NetNews). Все новостные статьи по-прежнему содержат заголовок Path , например:

Путь :news.server.example! other.example! not-for-mail

Та же информация в конверте электронной почты RFC 5321 - это информация SMTP, такая как MAIL FROM - будет:

  1. ПОЧТА ОТ :<[email protected]>
  2. ПОЧТА ОТ :<@ news.server.example: [email protected]>

1-й шаг отражает отправителя, 2-й шаг - следующего MTA и т. Д. В этом примере предположим, что 2-й MTA пересылает почту 3-му MTA, где она наконец доставляется. Последний MTA также известен как агент доставки почты (MDA), помещая почту в почтовый ящик получателя. MDA преобразует обратный путь в известное поле заголовка Return-Path :

Обратный путь :<@ news.server.example: [email protected]>

SMTP использует записи MX для прямой маршрутизации. Явные исходные маршруты, как в ...

RCPT TO :<@ news.server.example: [email protected]>

... перенаправлять почту от other.example через MTA news.server.example к MDA destination.example были обременительными. Иногда, что еще хуже, новый (1982 г.) стиль адресов смешивался со старыми путями взрыва UUCP в таких конструкциях, как ...

[email protected] другой[email protected]

... и различные другие клуджи. Записи SMTP и MX сделали все это практически бесполезным. Поэтому маршрутизация от источника была объявлена ​​устаревшей в 1989 году в RFC 1123 .

Одним из особых случаев в RFC 1123 являются шлюзы из или в другие сети, такие как UUCP и NetNews, где первый отправляющий MTA не может напрямую связаться с конечным получателем через TCP . Решается MX-записями и при необходимости перезаписью внешних адресов на шлюзе. MX - это аббревиатура от Mail eXchanger .

Другой особый случай - списки рассылки , где сервер списков переписывает все обратные пути на свой собственный адрес обработки ошибок для отказов (сообщений об ошибках) получателями. Сервер списков может автоматически отменять подписку на возвращающихся получателей. Этот тип перезаписи адресов известен со времен RFC 821 и используется до сих пор ( RFC 5321 , а также RFC 2821 обновили главу SMTP в RFC 1123 ).

И последнее, но не менее важное: пересылка на другой адрес всегда работала путем перезаписи адреса в прямом пути, также известном как RCPT TO , тогда и только тогда, когда пересылающий MTA принимает на себя ответственность как за пересылку почты, так и за возврат потенциальных сообщений о недоставке отправителю. RFC 821 и все более поздние спецификации SMTP предлагают два кода результата для этой ситуации:

  • 251 пользователь не локальный (попытка пересылки)
  • 551 пользователь не локальный (почта отклонена)

По соображениям конфиденциальности эти коды результатов сегодня используются редко; они включаютперенаправлен на (251) или же не переадресовано на адрес (551). Но смысл и эффект пересылки третьим лицам идентичны длякод результата 250 и код ошибки 550 соответственно.

Как отмечалось в RFC 1123, маршрутизация от источника не рекомендуется, а также неявно устарела обратная маршрутизация отказов. В 1989 году это был относительно небольшой Интернет, почтовые администраторы (почтмейстеры) часто знали друг друга и решали проблемы на лету. Маршрутизация обратных сообщений через любые пересылки была пустой тратой времени и полосы пропускания, если MTA, обнаруживший проблему (например, отклонение с кодом ошибки 5xx), мог отправить сообщение об ошибке непосредственно обратно в MX отправителя.

Начиная с RFC 1123, серверы пересылки третьим лицам по-прежнему переписывали адрес RCPT TO , но сохраняли MAIL FROM как есть. В качестве побочного эффекта MTA, желающие принимать почту от экспедиторов, обычно принимают любой адрес MAIL FROM .

Более чем десять лет спустя спамеры начали злоупотреблять этим недостатком SMTP после 1123, сегодня большинство писем является спамом, а обратные пути - подделаны. Обратите внимание, что спамеры обычно подделывают рабочие обратные пути , многие MTA отклоняют почту, если проверка обратного вызова или другие проверки достоверности не работают для обратного пути .

RFC 5321 , а также RFC 2821 , заявляют , что отчеты о недоставке ( отказы ) должны быть отправлены отправителю, как указано в обратном пути, после того, как MTA принял ответственность за доставку. Однако сообщение о недоставке может быть подавлено, если исходное содержимое является враждебным (например, спам или вирусная почта) или если сообщение является поддельным ( RFC 5321 , раздел 6). Обратите внимание, что все современные методы обнаружения подделки требуют, чтобы владелец почтового ящика предоставил информацию для их работы. Отсутствие критериев не должно приводить к классификации сообщений о недоставке как обратное рассеяние., хотя некоторые ошибочно думают, что так и должно быть.

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

Эта проблема SMTP, вызванная побочным эффектом RFC 1123 , решается с помощью SPF , и краткое изложение состоит в том, что SPF прерывает пересылку - на самом деле это не так,SPF FAIL только просит получателей проверить SPF на их пограничном MTA, не позже.

Получатели могут организовать свою пересылку таким образом, чтобы это работало с SPF, по существу с тремя стратегиями:

  1. не проверять SPF за границей, например, перенаправители белого списка
  2. просто отклонить SPF FAIL, что приводит к отскоку (Ошибка SMTP 550)
  3. переписать ПОЧТУ ОТ пересылки (как это делается в списках рассылки)

Схема перезаписи отправителя (SRS) - один из вариантов третьей стратегии.

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

  • Структура политики отправителя (SPF)
  • Сообщение о недоставке (отчет о недоставке SMTP)
  • Проверка тега адреса возврата (BATV)
  • Простой протокол передачи почты (SMTP)

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

  1. ^ a b Мэн Вэн Вонг (июнь 2003 г.). «Схема перезаписи отправителя для пересылки и пересылки для перезаписи адресов отправителя» . OpenSPF.org . Проверено 5 июля 2013 года . SRS можно рассматривать как форму VERP.
  2. ^ «Списки рассылки и псевдонимы» . Простой протокол передачи почты . IETF . Октябрь 2008. с. 3.9. DOI : 10,17487 / RFC5321 . RFC 5321 . Когда сообщение доставляется или пересылается на каждый адрес в форме расширенного списка, обратный адрес в конверте («ПОЧТА ОТ:») ДОЛЖЕН быть изменен на адрес человека или другого объекта, который управляет списком.
  3. ^ Shevek (июнь 2004). «Схема перезаписи отправителя» (PDF) . Anarres.org . Проверено 5 июля 2013 года .
  4. ↑ Meng Weng Wong (январь 2004 г.). «Требования СГД» . Список рассылки spf-обсуждения . Monharc.org . Проверено 5 июля 2013 года .
  5. ↑ Лаура Аткинс (июнь 2013 г.). «Странно i = в клиентской почте» . Список рассылки ietf-dkim . Mipassoc.org . Проверено 5 июля 2013 года .
  6. ^ Майкл Дойчманн (июль 2013 г.). «Этот странный i =, скорее всего, EDSP» . Список рассылки ietf-dkim . Mipassoc.org . Проверено 5 июля 2013 года .

Внешние ссылки [ править ]

  • домашняя страница libsrs2
  • Статья по СГД (PDF)
  • Исторический проект SRS по Meng Weng Wong (2003)
  • Патч Qmail SRS
  • Домашняя страница PostSRSd (демон, который обрабатывает SRS для Postfix)