Агент отправки сообщений

Агент отправки сообщений ( MSA ) или агент отправки почты — это компьютерная программа или программный агент , который получает электронные почтовые сообщения от почтового агента пользователя (MUA) и взаимодействует с агентом передачи почты (MTA) для доставки почты. Он использует ESMTP, вариант простого протокола передачи почты (SMTP), как указано в RFC 6409. [1]

Многие MTA также выполняют функцию MSA, но существуют также программы, специально разработанные как MSA без полной функциональности MTA. [2] Исторически сложилось так, что в интернет-почте функции MTA и MSA используют порт номер 25, но официальный порт для MSA — 587. [1] MTA принимает входящую почту пользователя, в то время как MSA принимает исходящую почту пользователя.

Компьютер, на котором запущен MSA, также называется сервером исходящей почты .

Преимущества

Разделение функций MTA и MSA дает ряд преимуществ.

Одним из преимуществ является то, что MSA, поскольку он напрямую взаимодействует с MUA автора, может исправлять незначительные ошибки в формате сообщения (например, отсутствующие поля Date , Message-ID , To или адрес с отсутствующим доменным именем) и/или немедленно сообщать об ошибке автору, чтобы ее можно было исправить до отправки любому из получателей. MTA, принимающий сообщение с другого сайта, не может надежно вносить такие исправления, и любые отчеты об ошибках, сгенерированные таким MTA, дойдут до автора (если вообще дойдут) только после того, как сообщение уже будет отправлено.

Еще одним преимуществом является то, что с выделенным номером порта 587 пользователи всегда могут подключиться к своему домену для отправки новой почты. Для борьбы со спамом (включая спам, непреднамеренно отправляемый жертвой ботнета ) многие интернет-провайдеры и институциональные сети ограничивают возможность подключения к удаленным MTA на порту 25. Доступность MSA на порту 587 [3] позволяет кочевым пользователям (например, тем, кто работает на ноутбуке) продолжать отправлять почту через свои предпочтительные серверы отправки даже из сетей других людей. Использование определенного сервера отправки является обязательным, когда применяются политики отправителя или методы подписи .

Еще одним преимуществом является то, что разделение функций MTA и MSA упрощает для MTA задачу запрета ретрансляции, то есть отклонения любой почты, которая не адресована получателю в домене, обслуживаемом локально. Это стратегия, используемая интернет-провайдерами для предотвращения отправки спама с зараженных вирусом клиентских компьютеров. Напротив, MSA должен, как правило, принимать почту для любого получателя в Интернете, хотя он принимает такую ​​почту только от авторов, которые уполномочены использовать этот MSA и которые установили свою личность в MSA посредством аутентификации. Во времена, когда и отправка почты, и прием входящей почты обычно выполнялись с использованием одного и того же протокола и одного и того же сервера, возможность отправлять почту по произвольным адресатам без аутентификации позволяла спамерам использовать MTA как средство распространения спама (поскольку одна транзакция сообщения может потребовать, чтобы MTA ретранслировал сообщение большому количеству получателей), а также затрудняла отслеживание сообщения до его источника.

Более того, MSA и MTA могут иметь разные политики фильтрации спама. Большинство MSA требуют аутентификации в виде имени пользователя и пароля, предоставленных автором. Таким образом, любые сообщения, полученные таким MSA, отслеживаются до автора, который имеет прямые отношения с MSA и который может быть привлечен к ответственности за свои действия. Это позволяет MSA либо не фильтровать спам, либо фильтровать спам более щадяще, чем MTA, который существует для приема входящей электронной почты с других доменов. Трудно установить доверие к почте, отправляемой между произвольными доменами, поскольку, как правило, между этими доменами нет прямой связи, через которую можно установить доверие или даже личность. При отсутствии такого доверия MTA обычно должен полагаться на эвристику и сторонние службы репутации, чтобы отличать спам от законного трафика, и оба этих механизма имеют историю подверженности ошибкам. [4] [5] Таким образом, разделение MSA и MTA позволяет избежать использования ненадежных механизмов распознавания спама во время отправки почты и увеличивает вероятность успешной доставки законной почты.

Протокол

Конфигурация

В то время как последние почтовые клиенты используют порт 587 по умолчанию, более старые по-прежнему предлагают порт 25. В последнем случае пользователи должны вручную изменить номер порта. Также возможно, что MUA может автоматически обнаружить, какой сервер предоставляет MSA для данного домена, просматривая записи SRV для этого домена. Домен example.com может публиковать свою запись следующим образом: [6]

 _submission._tcp.example.com. SRV 0 1 587 mail.example.com.

Обязательная аутентификация

RFC 6409 требует, чтобы клиенты были авторизованы и аутентифицированы для использования службы отправки почты, например, как описано в SMTP-AUTH (ESMTPA), или другими способами, такими как RADIUS , сертификаты открытых ключей или (в основном устаревший) POP перед SMTP .

Обеспечение соблюдения политики

MSA должен проверить, что отправленное сообщение является синтаксически правильным и соответствует соответствующим политикам сайта. RFC 6409 содержит некоторые дополнительные функции:

  • Enforce submission rights гарантирует, что адрес отправителя конверта действителен и авторизован с использованной аутентификацией. Это по сути соответствует модели SPF , указанной в RFC 7208.
  • Может добавить отправителя, разрешающего добавлять поле заголовка адреса отправителя, если адрес отправителя конверта не совпадает ни с одним адресом автора в поле заголовка «От». Это примерно соответствует модели идентификатора отправителя , указанной в RFC 4406, — игнорируя сложный случай полей заголовка Resent-From, не охваченных в RFC 6409.

Смотрите также

Ссылки

  • Кленсин, Дж. (апрель 2001 г.). Простой протокол передачи почты. IETF . doi : 10.17487/RFC2821 . RFC 2821 . Получено 14 ноября 2013 г. .
  • «SMTP не безопасен». Kasoft Central . Получено 2008-06-14 .
  1. ^ ab Gellens, R.; Klensin, J. (ноябрь 2011 г.). "Идентификация отправки". Отправка сообщения по почте. IETF . раздел 3.1. doi : 10.17487/RFC6409 . STD 72. RFC 6409. Получено 14 ноября 2013 г.
  2. ^ Косталес, Брайан; Ассманн, Клаус; Янсен, Джордж; Шапиро, Грегори Нил (2007-10-26). sendmail: Создание и администрирование sendmail. "O'Reilly Media, Inc.". ISBN 978-0-596-55534-4.
  3. ^ C. Hutzler; D. Crocker; P. Resnick; E. Allman ; T. Finch (ноябрь 2007 г.). Операции отправки электронной почты: требования к доступу и подотчетности. IETF . doi : 10.17487/RFC5068 . RFC 5068. Получено 13 февраля 2013 г. Поставщики доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету с использованием порта 587 ОТПРАВКИ.
  4. ^ Амир Герцберг (19 мая 2009 г.). «Механизмы аутентификации отправителя электронной почты на основе DNS: критический обзор». Компьютеры и безопасность . 28 (8): 731–742. doi :10.1016/j.cose.2009.05.002.
  5. ^ Джереми Блоссер и Дэвид Джозефсен (ноябрь 2004 г.). «Масштабируемое централизованное байесовское подавление спама с помощью Bogofilter». Труды LISA '04: Восемнадцатая конференция по системному администрированию . USENIX . Получено 24 июня 2010 г.
  6. ^ Cyrus Daboo (март 2011 г.). «Отправка электронной почты». Использование записей SRV для поиска служб отправки электронной почты/доступа. IETF . раздел 3.1. doi : 10.17487/RFC6186 . RFC 6186. Получено 17 апреля 2013 г.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Message_submission_agent&oldid=1172039639"