Editing Message submission agent

{{more citations needed|date=March 2017}}
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 [[Request for Comments|RFC]] 6409.<ref name="rfc6409"/>

Many MTAs perform the function of an MSA as well, but there are also programs that are specially designed as MSAs without full MTA functionality.<ref>{{Cite book |last1=Costales |first1=Bryan |url=https://books.google.com/books?id=NQblqMiVqvQC&dq=MTAs+performing+as+MSA&pg=PT26 |title=sendmail: Build and Administer sendmail |last2=Assmann |first2=Claus |last3=Jansen |first3=George |last4=Shapiro |first4=Gregory Neil |date=2007-10-26 |publisher="O'Reilly Media, Inc." |isbn=978-0-596-55534-4 |language=en}}</ref> Historically, in [[Internet mail]], both MTA and MSA functions use [[port number]] 25, but the official port for MSAs is 587.<ref name="rfc6409">
{{cite IETF
  | title = Message Submission for Mail
  | rfc = 6409
  | std = 72
  | section = 3.1
  | sectionname = Submission Identification
  | first1 = R. | last1 = Gellens
  | first2 = J. | last2 = Klensin
  |date=November 2011
  | publisher = [[Internet Engineering Task Force|IETF]]
  | accessdate = November 14, 2013
}}
</ref> The MTA accepts a user's incoming mail, while the MSA accepts a user's outgoing mail.

[[Image:SMTP-transfer-model.svg|thumb|300px|The computer running an '''MSA''' is also known as the ''outgoing mail server''.]]

==Benefits==
Separation of the [[Mail transfer agent|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 [[Internet service provider|ISPs]] and institutional [[Computer network|networks]] restrict the ability to connect to remote MTAs on port 25. The accessibility of an MSA on port 587<ref>{{cite IETF |title=Email Submission Operations: Access and Accountability Requirements |author1=C. Hutzler |author2=D. Crocker |author3=P. Resnick |author4=E. Allman |author4-link=Eric Allman |author5=T. Finch |rfc=5068 |date=November 2007 |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=13 February 2013 |quote=Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.}}</ref> 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 Policy Framework|sender policies]] or [[Author Domain Signing Practices|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 [[E-mail spam|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.<ref>{{cite journal |doi=10.1016/j.cose.2009.05.002 |title=DNS-based email sender authentication mechanisms: A critical review  |author=Amir Herzberg |date=19 May 2009 |journal=Computers & Security |volume=28  |issue=8  |pages=731–742  }}</ref><ref>{{cite web |url=http://www.usenix.org/event/lisa04/tech/blosser/blosser_html/ |title=Scalable Centralized Bayesian Spam Mitigation with Bogofilter |author=Jeremy Blosser and David Josephsen |date=November 2004 |work=Proceedings of LISA '04: Eighteenth Systems Administration Conference |publisher=[[USENIX]] |accessdate=24 June 2010}}</ref> 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.

==Protocol==

===Configuration===
While recent [[email client]]s 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 record]]s for that domain.  Domain example.com can publish its record like so:<ref>{{cite IETF |title=Use of SRV Records for Locating Email Submission/Access Services |rfc=6186 |sectionname=Email Submission |section=3.1 |author=Cyrus Daboo |date=March 2011 |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=17 April 2013}}</ref>

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

===Mandatory authentication===
{{Main|SMTP Authentication}}
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 certificate]]s, or (the mostly obsolete) [[POP before SMTP]].

===Policy enforcement===
The MSA must check that the submitted mail is syntactically valid and conforms to the relevant site policies. RFC 6409 contains some optional features:

* ''Enforce submission rights'' guarantees that the [[bounce address|envelope sender address]] is valid and authorized with the used authentication. This in essence complies with the [[Sender policy framework|SPF]] model specified in RFC 7208.
* ''May add sender'' permits to add a Sender address header field if the [[bounce address|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.

==See also==
*[[E-mail authentication]]
*[[List of mail servers]]
*[[Comparison of mail servers]]
*[[Smart host]]
* [[E-mail agent (infrastructure)]] (MxA)
* [[Mail delivery agent]] (MDA)
* [[Mail user agent]] (MUA)

==References==
* {{cite IETF
  | title = Simple Mail Transfer Protocol
  | rfc = 2821
  | first1 = J. | last1 = Klensin
  |date=April 2001
  | publisher = [[Internet Engineering Task Force|IETF]]
  | accessdate = November 14, 2013
}}
* {{cite web | title=SMTP is not secure | work=Kasoft Central | url=http://kasoft.freeyellow.com/Central/smtpbad.html | accessdate=2008-06-14}}
{{Reflist}}

[[Category:Email agents]]
[[Category:Email authentication]]
[[Category:Internet mail protocols]]