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

редактировать

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

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

Компьютер, на котором запущен MSA, также известен как сервер исходящей почты.
СОДЕРЖАНИЕ
  • 1 Преимущества
  • 2 Протокол
    • 2.1 Конфигурация
    • 2.2 Обязательная аутентификация
    • 2.3 Применение политики
  • 3 См. Также
  • 4 ссылки
Преимущества

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

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

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

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

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

Протокол

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

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

 _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.
Смотрите также
Рекомендации
Последняя правка сделана 2024-01-02 08:16:51
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте