Агент отправки сообщений
 | Эта статья нуждается в дополнительных цитатах для проверки . ( март 2017 г. ) |
Агент отправки сообщений ( MSA ) или агент отправки почты — это компьютерная программа или программный агент , который получает сообщения электронной почты от почтового пользовательского агента (MUA) и сотрудничает с агентом передачи почты (MTA) для доставки почты. Он использует ESMTP, вариант простого протокола передачи почты (SMTP), как указано в RFC 6409. [1]
Многие MTA также выполняют функцию MSA, но есть также программы, специально разработанные как MSA, без полной функциональности MTA. [2] Исторически сложилось так, что в почте Интернета функции MTA и MSA используют порт номер 25, но официальный порт для MSA — 587. [1] MTA принимает входящую почту пользователя, а 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 содержит некоторые дополнительные функции:
- Принудительные права на отправку гарантируют, что адрес отправителя конверта действителен и авторизован с использованием используемой аутентификации. По сути, это соответствует модели SPF , указанной в RFC 7208.
- Можно добавить разрешения отправителя на добавление поля заголовка «Адрес отправителя», если адрес отправителя конверта не соответствует ни одному адресу автора в поле заголовка «От». Это примерно соответствует модели Sender ID , указанной в RFC 4406, игнорируя сложный случай полей заголовка Resent-From, не описанный в RFC 6409.
См. также
[ редактировать ]- Аутентификация по электронной почте
- Список почтовых серверов
- Сравнение почтовых серверов
- Умный хост
- Агент электронной почты (инфраструктура) (MxA)
- Агент доставки почты (MDA)
- Почтовый пользовательский агент (MUA)
Ссылки
[ редактировать ]- Кленсин, Дж. (апрель 2001 г.). Простой протокол передачи почты . IETF . дои : 10.17487/RFC2821 . РФК 2821 . Проверено 14 ноября 2013 г.
- «SMTP небезопасен» . Касофт Централ . Проверено 14 июня 2008 г.
- ^ Перейти обратно: а б Гелленс, Р.; Кленсин, Дж. (ноябрь 2011 г.). «Идентификация подачи» . Отправка сообщения на почту . IETF . сек. 3.1. дои : 10.17487/RFC6409 . СТД 72. RFC 6409 . Проверено 14 ноября 2013 г.
- ^ Косталес, Брайан; Ассманн, Клаус; Янсен, Джордж; Шапиро, Грегори Нил (26 октября 2007 г.). sendmail: Создание и администрирование sendmail . «О'Рейли Медиа, Инк.». ISBN 978-0-596-55534-4 .
- ^ К. Хатцлер; Д. Крокер; П. Резник; Э. Оллман ; Т. Финч (ноябрь 2007 г.). Операции по отправке электронной почты: требования к доступу и подотчетности . IETF . дои : 10.17487/RFC5068 . РФК 5068 . Проверено 13 февраля 2013 г.
Поставщики доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету с использованием порта ПОДАЧИ 587.
- ^ Амир Герцберг (19 мая 2009 г.). «Механизмы аутентификации отправителя электронной почты на основе DNS: критический обзор». Компьютеры и безопасность . 28 (8): 731–742. дои : 10.1016/j.cose.2009.05.002 .
- ^ Джереми Блоссер и Дэвид Джозефсен (ноябрь 2004 г.). «Масштабируемая централизованная защита от байесовского спама с помощью Bogofilter» . Материалы LISA '04: Восемнадцатая конференция по системному администрированию . УСЕНИКС . Проверено 24 июня 2010 г.
- ^ Сайрус Дабу (март 2011 г.). «Отправка по электронной почте» . Использование записей SRV для поиска служб отправки электронной почты/доступа . IETF . сек. 3.1. дои : 10.17487/RFC6186 . РФК 6186 . Проверено 17 апреля 2013 г.