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

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

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

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

Преимущества [ править ]

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

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

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

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

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

Протокол [ править ]

Конфигурация [ править ]

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

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

Обязательная аутентификация [ править ]

Основная статья: Аутентификация SMTP

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

Применение политики [ править ]

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

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

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

  • E-mail аутентификация
  • Список почтовых серверов
  • Сравнение почтовых серверов
  • Умный хост
  • Почтовый агент (инфраструктура) (MxA)
  • Агент доставки почты (MDA)
  • Почтовый пользовательский агент (MUA)

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

  • Кленсин, Дж. (Апрель 2001 г.). Простой протокол передачи почты . IETF . DOI : 10,17487 / RFC2821 . RFC 2821 . Проверено 14 ноября 2013 года .
  • «SMTP небезопасен» . Kasoft Central . Проверено 14 июня 2008 .
  1. ^ a b Gellens, R .; Кленсин, Дж. (Ноябрь 2011 г.). «Идентификация представления» . Отправка сообщений по почте . IETF . сек. 3.1. DOI : 10,17487 / RFC6409 . STD 72. RFC 6409 . Проверено 14 ноября 2013 года .
  2. ^ К. Хатцлер; Д. Крокер; П. Резник; Э. Оллман ; Т. Финч (ноябрь 2007 г.). Операции по отправке электронной почты: требования к доступу и отчетности . IETF . DOI : 10,17487 / RFC5068 . RFC 5068 . Проверено 13 февраля 2013 года . Провайдеры доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету через порт SUBMISSION 587.
  3. ↑ Амир Херцберг (19 мая 2009 г.). «Механизмы аутентификации отправителя электронной почты на основе DNS: критический обзор». Компьютеры и безопасность . 28 (8): 731–742. DOI : 10.1016 / j.cose.2009.05.002 .
  4. ^ Джереми Blosser и Дэвид Josephsen (ноябрь 2004). «Масштабируемое централизованное противодействие байесовскому спаму с помощью Bogofilter» . Труды LISA '04: Восемнадцатая конференция системного администрирования . USENIX . Проверено 24 июня 2010 года .
  5. ^ Сайрус Daboo (март 2011). «Отправка по электронной почте» . Использование записей SRV для поиска служб отправки электронной почты / доступа . IETF . сек. 3.1. DOI : 10,17487 / RFC6186 . RFC 6186 . Проверено 17 апреля 2013 года .