Community Hub0 Subscribers
Community hub
Message submission agent
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (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 RFC 6409.[1]
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.[2] Historically, in Internet mail, both MTA and MSA functions use port number 25, but the official port for MSAs is 587.[1] The MTA accepts a user's incoming mail, while the MSA accepts a user's outgoing mail.
Benefits
[edit]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[3] 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.[4][5] 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
[edit]Configuration
[edit]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:[6]
_submission._tcp.example.com. SRV 0 1 587 mail.example.com.
Mandatory authentication
[edit]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.
Policy enforcement
[edit]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 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.
See also
[edit]References
[edit]- Klensin, J. (April 2001). Simple Mail Transfer Protocol. IETF. doi:10.17487/RFC2821. RFC 2821. Retrieved November 14, 2013.
- "SMTP is not secure". Kasoft Central. Retrieved 2008-06-14.
- ^ a b Gellens, R.; Klensin, J. (November 2011). "Submission Identification". Message Submission for Mail. IETF. sec. 3.1. doi:10.17487/RFC6409. STD 72. RFC 6409. Retrieved November 14, 2013.
- ^ Costales, Bryan; Assmann, Claus; Jansen, George; Shapiro, Gregory Neil (2007-10-26). sendmail: Build and Administer sendmail. O'Reilly Media, Inc. ISBN 978-0-596-55534-4.
- ^ C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (November 2007). Email Submission Operations: Access and Accountability Requirements. IETF. doi:10.17487/RFC5068. RFC 5068. Retrieved 13 February 2013.
Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.
- ^ Amir Herzberg (19 May 2009). "DNS-based email sender authentication mechanisms: A critical review". Computers & Security. 28 (8): 731–742. doi:10.1016/j.cose.2009.05.002.
- ^ Jeremy Blosser and David Josephsen (November 2004). "Scalable Centralized Bayesian Spam Mitigation with Bogofilter". Proceedings of LISA '04: Eighteenth Systems Administration Conference. USENIX. Retrieved 24 June 2010.
- ^ Cyrus Daboo (March 2011). "Email Submission". Use of SRV Records for Locating Email Submission/Access Services. IETF. sec. 3.1. doi:10.17487/RFC6186. RFC 6186. Retrieved 17 April 2013.
Message submission agent
View on Grokipediafrom Grokipedia
Overview
Definition
A message submission agent (MSA) is a software process that accepts email messages from a mail user agent (MUA) for initial submission into the email system, acting as a submission server that either delivers the messages locally or relays them to a message transfer agent (MTA) via SMTP.[3] This definition is formalized in RFC 6409, which specifies the MSA's conformance to submission protocols distinct from general message transfer.[3] The core function of an MSA involves validating the sender's identity through mandatory authentication mechanisms, such as SMTP-AUTH, to ensure secure submission.[3] It enforces submission rules by requiring fully qualified domain names in addresses and rejecting messages that violate syntax, policy, or content guidelines, thereby preventing abuse.[3] Once validated, the MSA forwards the message to an appropriate MTA for further routing and delivery, without performing inter-domain relaying itself.[3] Unlike general SMTP servers, which may handle open relaying between domains, an MSA is designed exclusively for authenticated user submissions, operating under strict access controls to mitigate spam and unauthorized use.[3] This distinction positions the MSA as a secure entry point in the email architecture, integrating with broader components like MTAs for efficient message flow.[3]Role in Email Architecture
In the email architecture, the Message Submission Agent (MSA) serves as the initial gateway for outgoing messages, positioned between the Mail User Agent (MUA) used by end-users and the broader Mail Transfer Agent (MTA) system responsible for relaying messages across the network.[4] When a user composes and sends an email via their MUA, such as an email client or web interface, the message is submitted to the MSA for validation and forwarding. The MSA then acts as an SMTP client to relay the accepted message to an appropriate MTA, which handles the store-and-forward transmission to the destination domain.[3] This placement ensures that user-submitted mail enters the email infrastructure through a controlled point, distinct from the unrestricted relay paths used for inter-domain transfers.[4] The MSA's interactions within this pipeline emphasize reliability and preliminary processing without assuming long-term storage responsibilities. Additionally, the MSA performs essential initial checks, such as enforcing organizational policies and Internet standards, which can include hooks for content scanning (e.g., for viruses or spam indicators) before relay.[3] However, the MSA does not engage in cross-domain store-and-forward operations; its role is limited to submission and handover to the MTA for routing to the recipient's domain.[4] This design maintains a clear separation, allowing the MSA to focus on secure ingress while the MTA manages the complexities of message transport. Visually, the MSA fits into the standard email flow as follows: MUA (sender) → MSA → MTA (relay network) → MDA (delivery to recipient mailbox) → MUA (recipient).[4] This sequence underscores the MSA's function as the secure entry point for user-generated content, where it rejects non-conforming submissions to protect the overall system integrity and prevent abuse.[3] Unlike the Mail Delivery Agent (MDA), which handles the final local delivery to a user's mailbox on the destination server, the MSA operates at the origin side, ensuring messages are properly authenticated and compliant before entering the transport layer.[4] This distinction enhances the architecture's modularity, enabling specialized handling at each stage.History and Standards
Origins and Development
In the 1990s, the open nature of Simple Mail Transfer Protocol (SMTP) servers, particularly through open relays on port 25, enabled widespread abuse by allowing unauthorized third parties to inject and relay messages without authentication. This vulnerability facilitated the explosion of spam and unsolicited bulk email, as spammers exploited unsuspecting servers to distribute large volumes of unwanted messages at low cost.[5][6] The escalating email abuse in the late 1990s motivated the Internet Engineering Task Force (IETF) to propose separating message submission from relaying, introducing the concept of Message Submission Agents (MSAs) to enforce authentication and policy controls. Initial proposals emerged from IETF working groups amid concerns over spam and security, aiming to distinguish authenticated user submissions from anonymous relaying.[6] Key milestones in MSA development included their formalization in late 1998 and subsequent adoption in enterprise environments post-2000, driven by the need to mitigate unauthorized relaying and bolster email infrastructure security. This shift influenced the integration of MSA capabilities into widely used mail servers, such as Postfix—released in December 1998[7]—and Sendmail extensions, enabling authenticated submission on dedicated ports like 587.[3][8]Key RFCs and Evolution
The foundational standard for message submission agents (MSAs) was established in RFC 2476, published in December 1998, which introduced the SMTP Service Extension for Submission.[6] This extension defined a specialized profile of the Simple Mail Transfer Protocol (SMTP) for use by message user agents (MUAs) to submit messages to MSAs, distinguishing submission from general message transfer.[6] Key provisions included the reservation of TCP port 587 exclusively for message submission, enabling servers to identify and handle incoming connections as submissions rather than relays.[6] Additionally, it mandated that MSAs require authentication, typically via SMTP-AUTH as per RFC 2554, to verify submitting users and enforce site-specific policies, thereby improving security over standard SMTP on port 25.[6][9] RFC 4409, published in April 2006, updated and obsoleted RFC 2476 by refining the submission guidelines to address evolving security needs.[10] It emphasized the separation of submission (handled by MSAs) from relay (handled by message transfer agents or MTAs), allowing distinct operational rules for each.[10] Notable additions included support for opportunistic TLS via the STARTTLS extension (RFC 3207), which enables encrypted submission sessions when both client and server support it, without making it mandatory at the time.[10][11] The document also introduced policy enforcement hooks, such as requirements for MSAs to validate message syntax, reject unauthorized submissions, and apply local policies before acceptance, further distinguishing MSA behavior from MTA relay functions.[10] The current primary standard, RFC 6409, published in November 2011, obsoleted RFC 4409 and consolidated the specifications with enhanced clarity and security mandates.[3] It reiterated the use of port 587 for submission and reinforced authentication as a default requirement for MSAs, while clarifying the distinct roles of MSAs (focused on authenticated submission from MUAs) versus MTAs (focused on unauthenticated relay between servers).[3] This version strengthened mandates for MSAs to enforce stricter validation of message content and envelopes to prevent abuse, including checks for proper formatting and sender authorization.[3] A subsequent update in RFC 8314 (January 2018) addressed TLS usage by recommending the adoption of Implicit TLS on port 465 as an alternative to STARTTLS on port 587, deprecating cleartext submission and urging encryption for all message submissions to mitigate interception risks.[12] The evolution of these RFCs reflects a progression from optional security features in early specifications to mandatory authentication and encryption requirements in later ones, primarily to combat spam, unauthorized relaying, and eavesdropping in email systems.[6][10][3][12] No further major revisions to the core MSA protocol have occurred since RFC 6409, though complementary standards like RFC 6531 have extended support for internationalized email in submission contexts.[3]Protocol and Operation
SMTP Submission Protocol
The SMTP Submission Protocol is an extension of the Simple Mail Transfer Protocol (SMTP) designed specifically for message submission by Message Submission Agents (MSAs). It operates as an Extended SMTP (ESMTP) service, initiated by the client's EHLO command, which prompts the server to advertise its supported extensions, including the required AUTH extension for authentication and optional capabilities like STARTTLS for Transport Layer Security (TLS) encryption. This protocol ensures that end-user clients submit messages in a controlled manner, distinct from the relay functions of Mail Transfer Agents (MTAs), by enforcing authentication and authorization before accepting messages.[1] In the submission process, the protocol mandates the use of specific SMTP commands to validate and transmit messages. The MAIL FROM command specifies the sender's address, allowing the MSA to verify it against the authenticated user's identity and reject mismatches to prevent unauthorized sending.[1] The RCPT TO command then declares each recipient's address, with the MSA evaluating authorization and rejecting invalid recipients or those the user is not permitted to send to early in the session.[1] Following recipient acceptance, the DATA command transfers the message body, including headers and content, in a format compliant with Internet Message Format standards, ensuring the message is queued for further processing only after successful validation. Unauthenticated sessions are explicitly rejected at the outset, typically via a 530 response code indicating policy-required authentication, thereby securing the submission endpoint against open relay abuse.[1] Error handling in the SMTP Submission Protocol incorporates response codes tailored to submission scenarios, differentiating it from standard MTA interactions on port 25. For instance, a 530 code signals authentication failure, 554 for permanent failures like invalid sender addresses (e.g., non-fully qualified domains), 550 for authorization or policy violations, and 450 for temporary issues such as resource limits. These codes provide precise feedback to clients, facilitating retries or corrections without compromising security. The protocol's design on port 587 further emphasizes its submission role, separate from MTA relaying.[1]Transport and Security Basics
Message Submission Agents (MSAs) utilize TCP port 587 as the default port for receiving email submissions from clients, distinct from TCP port 25, which is reserved for message relay between Mail Transfer Agents (MTAs).[1] This separation enables administrators to apply firewall rules that block unauthorized outbound traffic on port 25 to mitigate spam while permitting controlled submissions on port 587.[1] For transport security, MSAs support opportunistic encryption through the STARTTLS extension, which upgrades an initially plaintext SMTP connection to Transport Layer Security (TLS) if both client and server agree.[13][1] This mechanism protects the confidentiality and integrity of submitted messages during transit, and while fallback to plaintext is technically possible if STARTTLS fails (e.g., due to a temporary server issue), it is strongly discouraged in production environments to avoid exposing sensitive data.[13] Firewall and Network Address Translation (NAT) configurations pose common challenges for MSA communications, as client submissions on port 587 must traverse these barriers in enterprise networks.[14] Proper deployment requires firewalls to explicitly allow inbound and outbound TCP connections on port 587, often necessitating coordination between network teams to configure routing rules that support reliable traversal without resorting to insecure tunneling over other ports like 80 or 25.[14] NAT devices should adhere to minimum idle timeouts to prevent premature connection drops during submission sessions.[14]Authentication and Access Control
Mandatory Authentication Mechanisms
The primary mechanism for authenticating clients to a Message Submission Agent (MSA) is SMTP AUTH, an extension to the Simple Mail Transfer Protocol (SMTP) that integrates the Simple Authentication and Security Layer (SASL) to verify user identity before message acceptance.[15] This process enables the MSA to challenge the client for credentials and validate them against configured user accounts, ensuring only authorized submissions proceed.[3] Common SASL mechanisms supported include PLAIN, which transmits username and password in base64-encoded plain text (requiring transport encryption for security); LOGIN, a non-standard variant of PLAIN that prompts for credentials sequentially; and DIGEST-MD5, which uses a challenge-response protocol based on MD5 hashing to protect credentials without sending them in clear form.[15] Modern implementations prefer stronger mechanisms such as SCRAM-SHA-256 for hashed authentication without cleartext passwords, and OAuth 2.0-based XOAUTH2 for token-based authorization, particularly in cloud environments.[16][17] These methods allow flexible authentication while adhering to security best practices. As of 2025, major providers like Microsoft are deprecating basic username/password SMTP AUTH in favor of modern alternatives like OAuth.[18] RFC 6409 mandates that MSAs require authentication prior to accepting any MAIL FROM command, issuing a 530 error response if the session lacks valid credentials via SMTP AUTH, thereby explicitly prohibiting anonymous message submissions.[3] This requirement distinguishes MSAs from traditional Mail Transfer Agents (MTAs), which may permit relay without authentication in trusted environments, and applies by default unless the MSA independently verifies authorization through other means, such as network protections.[3] The authentication step occurs early in the SMTP session, typically after the client issues an AUTH command and before any message data is processed. Credential handling in MSAs involves username and password pairs directly tied to local or domain user accounts, where the MSA maps the authenticated identity to submission permissions.[3] To scale in enterprise settings, MSAs commonly integrate with external authentication backends like LDAP (Lightweight Directory Access Protocol), enabling the server to query directory services for credential validation and user attributes without storing all data locally.[19] For instance, during SASL negotiation with implementations like Dovecot, the MSA can bind to an LDAP server using the provided credentials to confirm authenticity.[20] These mechanisms are required to be layered over TLS encryption to safeguard credentials during transmission, with current standards (RFC 8314) mandating TLS for submission and preferring implicit TLS on port 465 over STARTTLS on port 587.[3][12]Authorization and User Policies
After authentication, a Message Submission Agent (MSA) enforces authorization by verifying that the authenticated user's identity permits the proposed message submission actions, such as specifying the envelope sender or recipients. This process typically employs role-based access control, where permissions are tied to the user's authenticated credentials, allowing the MSA to restrict actions based on predefined roles or attributes associated with the identity. For instance, an MSA may limit the number of recipients per message or session to prevent abuse, issuing a 450 or 550 response code if exceeded.[21] Similarly, domain restrictions can be applied, requiring all envelope domains to be fully qualified and ensuring the sender domain aligns with the user's authorized scope.[22] Policy integration in MSAs includes mechanisms to check that the envelope sender (MAIL FROM) matches or is authorized under the authenticated user's domain, thereby preventing unauthorized spoofing by legitimate users. If the sender address lacks sufficient submission rights relative to the authentication identity, the MSA rejects the command with a 550 response, enhanced by status code 5.7.1.[23] This hook operates post-authentication, building on mechanisms like SMTP-AUTH to map the identity to allowable senders without altering the core login process. Revocation and management of user policies in MSAs support dynamic updates through administrative interfaces, enabling operators to modify access rules—such as adjusting per-user volume limits or domain allowances—without requiring a server restart. In implementations like Postfix, external policy services allow real-time evaluation of authorization queries, facilitating revocation by updating policy databases or scripts that respond to SMTP events.[24] This approach ensures ongoing enforcement of user-specific permissions while maintaining service availability.Configuration and Implementation
Server Configuration
Common open-source mail transfer agents such as Postfix and Exim, as well as proprietary systems like Microsoft Exchange Server, are frequently configured to function as message submission agents (MSAs). In Postfix, the submission service is enabled by uncommenting the relevant line in the/etc/postfix/master.cf file, which by default specifies listening on TCP port 587 with the smtpd daemon and overrides to enforce SASL authentication and TLS opportunism.[25] Exim supports MSA functionality by configuring the daemon_smtp_ports option in its configuration file to include port 587 (for STARTTLS) and optionally 465 (for implicit TLS), alongside 25, to handle secure message submissions, as recommended by RFC 6409.[26] Microsoft Exchange Server provides MSA capabilities via its default "Client Frontend" Receive Connector, which listens on port 587 and requires authentication for client submissions, configurable through the Exchange Admin Center or PowerShell cmdlets like Set-ReceiveConnector.[27]
Key configuration parameters for an MSA focus on enabling secure authentication and transport. For Postfix, SASL authentication is configured in /etc/sasl2/smtpd.conf (or /usr/lib/sasl2/smtpd.conf on some systems), specifying the password check method (e.g., pwcheck_method: saslauthd) and supported mechanisms (e.g., mech_list: [PLAIN](/page/Plain) [LOGIN](/page/Login)), while enabling it globally in /etc/postfix/main.cf with smtpd_sasl_auth_enable = yes and smtpd_sasl_type = [cyrus](/page/Cyrus).[28] TLS is activated opportunistically with smtpd_tls_security_level = may in /etc/postfix/main.cf, allowing clients to initiate STARTTLS without mandating encryption, which is suitable for port 587 submissions.[29] Similar settings apply in Exim via the auth_advertise_hosts and tls_advertise_hosts options to advertise authentication and TLS on the submission port.[26]
For logging and monitoring submission events, Postfix administrators can enable verbose output by appending the -v flag to the smtpd daemon in the submission service line of /etc/postfix/master.cf (e.g., smtpd -v), which increases detail in syslog entries for authentication attempts and connections without affecting performance broadly.[30] To protect against brute-force attacks on the submission port, integration with Fail2Ban is common; the [postfix-sasl] jail scans mail logs for failed authentication patterns (e.g., "SASL LOGIN authentication failed") and bans offending IPs after a configurable number of attempts, using filters defined in /etc/fail2ban/filter.d/postfix-sasl.conf. After changes, reloading the services (e.g., postfix reload or systemctl reload exim4) ensures the MSA operates securely on port 587.
Client Configuration
Mail user agents (MUAs) such as Mozilla Thunderbird and Microsoft Outlook require specific configuration to connect to a message submission agent (MSA) for outbound email transmission, typically using the SMTP submission port 587 as defined in RFC 6409.[3] In Thunderbird, users access the account settings via the "Account Settings" menu, where they specify the outgoing server as "smtp.example.com" (replacing with the provider's MSA hostname), select port 587, enable connection security as STARTTLS, and require authentication.[31] Similarly, in Outlook, configuration occurs through the "File > Account Settings > Account Settings" dialog, entering the SMTP server (e.g., "smtp.office365.com"), port 587, encryption method as STARTTLS, and authentication enabled, ensuring the client logs in with valid credentials before submission.[32] Authentication setup in these MUAs involves providing a username (often the full email address) and password, or using OAuth 2.0 tokens for enhanced security, particularly with providers like Microsoft 365 or Google Workspace.[33] For accounts with two-factor authentication (2FA) enabled, users may need to generate and enter app-specific passwords as a fallback, which act as secure alternatives to the primary account password without compromising device-based 2FA. This aligns with mandatory SMTP-AUTH mechanisms like PLAIN or LOGIN for client verification during submission.[3] Common troubleshooting issues include port blocking by ISPs or firewalls, which prevents connections on port 587; users can verify connectivity using telnet with the commandtelnet smtp.[example.com](/page/Example.com) 587 to check if the server responds with a 220 greeting.[34] Certificate validation failures, often due to mismatched hostnames or expired certificates during STARTTLS negotiation, can be diagnosed by running openssl s_client -starttls smtp -connect smtp.[example.com](/page/Example.com):587 to inspect the TLS handshake and certificate chain for errors.[35] If the connection succeeds but authentication fails, rechecking credentials or switching to OAuth resolves most cases without altering server-side settings.