Mail Submission Agent

Агент передачи электронной почты ( _en. Mail Submission Agent, MSA) это компьютерная программа или программный агент, который принимает сообщение электронной почты из почтового агента (MUA) и соеденяется с mail transfer agent (MTA) для доставки электронной почты.

Many MTAs act as an MSA as well, but there are also programs that are specially designed as MSAs without full MTA functionality. Historically in Internet mail, both MTA (acceptance of locally-destined mail from other domains) and MSA (acceptance of submitted mail from local users) functions were both performed by MTAs using the same protocol (SMTP).

Separation of the MTA and MSA function 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’s format (such as a missing Date field, 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 he has already sent the message.

Another benefit is that separating the MTA and MSA functions makes it possible (and desirable) for an MTA that accepts incoming mail to refuse any mail that is not addressed to a recipient at a domain that is served by the MTA. 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.

Another benefit is that 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.

The separation of MTA and MSA functions has made it easier for many internet service providers and enterprise networks to restrict the ability of unauthorized computers on their networks to connect directly to remote MTAs on port 25 (the usual SMTP port), in order to prevent those computers on their networks from being used to relay spam. Widespread support for use of the MSA protocol on port 587 enables nomadic users to continue to send mail via their own submission servers even from within others' networks, and the widespread requirement for authentication on port 587 means that enterprise networks have little desire to filter outgoing traffic on that port.

См. также

* List of mail servers
* Comparison of mail servers

Ссылки

* R. Gellens & J. Klensin. "Message Submission ". RFC 2476, December 1998.
* J. Klensin, ed. "Simple Mail Transfer Protocol ". RFC 2821, April 2001.
*
*