Агент передачи почты (MSA): Функции, преимущества и безопасность.
Message submission agent
Агент передачи почты (MSA): что это такое? Прием исходящей почты от MUA, взаимодействие с MTA по протоколу ESMTP (RFC 6409), порт 587. Преимущества разделения функций.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Агент приема сообщений (MSA), или агент отправки почты, — это компьютерная программа или программный агент, который принимает электронные почтовые сообщения от агента пользователя почты (MUA) и взаимодействует с агентом передачи почты (MTA) для доставки почты. Он использует ESMTP, разновидность протокола простой передачи почты (SMTP), как определено в RFC 6409. Исторически, в системах электронной почты в интернете, как MTA, так и MSA использовали порт 25, однако официальный порт для MSA — 587. MTA принимает входящую почту для пользователя, а MSA — исходящую почту от пользователя.
A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409. Historically, in Internet mail, both MTA and MSA functions use port number 25, but the official port for MSAs is 587. The MTA accepts a user's incoming mail, while the MSA accepts a user's outgoing mail.
Преимущества
Разделение функций MTA и MSA дает несколько преимуществ. Одно из преимуществ MSA заключается в том, что, взаимодействуя напрямую с MUA автора, он может исправлять незначительные ошибки в формате сообщения (например, отсутствующие дату, идентификатор сообщения, поля To или адрес без указанного доменного имени) и/или немедленно сообщать об ошибке автору для исправления до отправки сообщения получателям. MTA, принимающий сообщение с другого сайта, не может надежно вносить такие исправления, а любые отчеты об ошибках, генерируемые таким MTA, достигнут автора (если вообще достигнут) только после отправки сообщения. Еще одно преимущество заключается в том, что благодаря выделенному номеру порта 587 пользователям всегда доступно подключение к своему домену для отправки новой почты. Для борьбы со спамом (включая спам, отправляемый невольно жертвой ботнета) многие интернет-провайдеры и институциональные сети ограничивают возможность подключения к удаленным MTA на порту 25. Доступность MSA на порту 587 позволяет мобильным пользователям (например, работающим на ноутбуке) продолжать отправлять почту через предпочитаемые серверы отправки, даже находясь в чужих сетях. Использование конкретного сервера отправки является обязательным требованием при применении политик отправителя или практик подписи. Еще одно преимущество заключается в том, что разделение функций MTA и MSA упрощает для MTA отказ в ретрансляции, то есть отказ в обработке почты, не адресованной получателю в локально обслуживаемом домене. Это стратегия, используемая интернет-провайдерами для предотвращения рассылки спама с зараженных вирусами клиентских компьютеров. В отличие от этого, MSA обычно должен принимать почту для любого получателя в Интернете, но только от авторов, авторизованных для использования этого MSA и прошедших аутентификацию. В то время, когда отправка и прием почты обычно осуществлялись с использованием одного и того же протокола и сервера, возможность отправки почты в произвольные пункты назначения без аутентификации позволяла спамерам использовать MTA для распространения спама (поскольку одна транзакция сообщения может потребовать от MTA пересылки сообщения большому количеству получателей), а также затрудняла отслеживание сообщения до его источника. Кроме того, MSA и MTA могут иметь различные политики фильтрации спама. Большинство MSA требуют аутентификации в виде имени пользователя и пароля, предоставленных автором. Любые сообщения, полученные таким MSA, могут быть прослежены до автора, имеющего прямую связь с MSA и несущего ответственность за свои действия. Это позволяет MSA либо не применять фильтрацию спама, либо использовать более лояльную фильтрацию спама, чем MTA, предназначенный для приема входящей электронной почты из других доменов. Установить доверие к почте, отправляемой между произвольными доменами, сложно, поскольку обычно нет прямой связи между этими доменами, позволяющей установить доверие или даже идентифицировать отправителя. В отсутствие такого доверия MTA обычно полагаются на эвристические методы и сервисы репутации третьих сторон для различения спама и легитимного трафика, и оба этих механизма имеют историю ошибок. Поэтому разделение MSA и MTA позволяет избежать использования ненадежных механизмов распознавания спама при отправке почты и повышает вероятность успешной доставки легитимной почты.
Separation of the MTA and MSA functions produces several benefits. One benefit is that an MSA, since it is interacting directly with the author's MUA, can correct minor errors in a message format (such as a missing Date, Message ID, To fields, or an address with a missing domain name) and/or immediately report an error to the author so that it can be corrected before it is sent to any of the recipients. An MTA accepting a message from another site cannot reliably make those kinds of corrections, and any error reports generated by such an MTA will reach the author (if at all) only after the message has already been sent. One more benefit is that with a dedicated port number, 587, it is always possible for users to connect to their domain to submit new mail. To combat spam (including spam being sent unwittingly by a victim of a botnet) many ISPs and institutional networks restrict the ability to connect to remote MTAs on port 25. The accessibility of an MSA on port 587 enables nomadic users (for example, those working on a laptop) to continue to send mail via their preferred submission servers even from within others' networks. Using a specific submission server is a requirement when sender policies or signing practices are enforced. Another benefit is that separating the MTA and MSA functions makes it easier for an MTA to deny relaying, that is to refuse any mail that is not addressed to a recipient at a domain that is served locally. This is a strategy used by ISPs to prevent the sending of spam from virus infected client computers. By contrast, an MSA must generally accept mail for any recipient on the Internet, though it only accepts such mail from authors who are authorized to use that MSA and who have established their identity to the MSA via authentication. In times when both mail submission and acceptance of incoming mail were usually accomplished using the same protocol and the same server, the ability to send mail to arbitrary destinations without authentication allowed spammers to use MTAs as a means of distributing spam (since a single message transaction can request that an MTA relay a message to a large number of recipients), and also made it more difficult to trace a message to its origin. Moreover, MSAs and MTAs can have different policies for filtering of spam. Most MSAs require authentication in the form of a username and password provided by the author. Any messages received by such an MSA are therefore traceable to an author who has a direct relationship with the MSA, and who can be held accountable for his actions. This allows the MSA to have either no spam filtering, or more permissive spam filtering than an MTA that exists for the purpose of accepting incoming email from other domains. It is difficult to establish trust in mail sent between arbitrary domains, because there is generally no direct relationship between those domains via which trust, or even identity, can be established. In the absence of such trust, an MTA must generally rely on heuristics and third party reputation services to distinguish spam from legitimate traffic, and both of these mechanisms have a history of being error prone. The separation of MSA and MTA therefore avoids the use of unreliable spam recognition mechanisms during mail submission, and increases the probability for legitimate mail to be delivered successfully.
Конфигурация
В то время как современные почтовые клиенты по умолчанию используют порт 587, более старые версии по-прежнему предлагают порт 25. В этом случае пользователям необходимо вручную изменить номер порта. Также возможно, что почтовый клиент (MUA) может автоматически определить, какой сервер предоставляет MSA для указанного домена, выполняя поиск SRV-записей для этого домена. Например, домен example.com может опубликовать следующую запись:
While recent email clients use port 587 by default, older ones still propose port 25. Users have to change the port number manually in the latter case. It is also possible that the MUA may automatically discover which server provides the MSA for a given domain, looking up the SRV records for that domain. Domain example. com can publish its record like so:
RFC 6409 требует, чтобы клиенты были авторизованы и аутентифицированы для использования службы передачи почты, например, как описано в SMTP AUTH (ESMTPA), или другими способами, такими как RADIUS, сертификаты открытого ключа или (в основном устаревший) POP перед SMTP.
RFC 6409 requires that clients are authorized and authenticated to use the mail submission service, e. g., as described in SMTP AUTH (ESMTPA), or by other means such as RADIUS, public key certificates, or (the mostly obsolete) POP before SMTP.
Применение политики
MSA должен проверять, что отправленное письмо синтаксически корректно и соответствует действующим политикам сайта. RFC 6409 содержит некоторые необязательные функции:
The MSA must check that the submitted mail is syntactically valid and conforms to the relevant site policies. RFC 6409 contains some optional features:
Гарантия прав на отправку обеспечивает проверку действительности и авторизации адреса отправителя конверта с использованием примененной аутентификации. По сути, это соответствует модели SPF, описанной в RFC 7208. Может добавлять разрешения отправителю для добавления поля заголовка "Sender", если адрес отправителя конверта не совпадает ни с одним адресом автора в поле заголовка "From". Это приблизительно соответствует модели Sender ID, описанной в RFC 4406, игнорируя сложный случай полей заголовка "Resent From", которые не рассматриваются в RFC 6409.
Enforce submission rights guarantees that the envelope sender address is valid and authorized with the used authentication. This in essence complies with the SPF model specified in RFC 7208. May add sender permits to add a Sender address header field if the envelope sender address does not match any author address in the "From" header field. This roughly complies with the Sender ID model specified in RFC 4406 – ignoring the tricky case of Resent From header fields not covered in RFC 6409.