Summary

  • SMTP AUTH let a client and server negotiate a SASL mechanism before a mail transaction, so a submission server could grant relay rights to an authenticated and authorized identity rather than to any host that could reach port 25.
  • Its strongest rule was a limit: successful authentication concerned submission at one session boundary. The envelope sender, the asserted original submitter, the header author and the message content remained separate claims.

The old gate knew the connection, not the traveler

SMTP was built to move mail between cooperating machines. A server could inspect the connecting address, accept mail for local recipients and decide whether to relay elsewhere. That was adequate while trust followed a small network or a protected site. It became dangerous when a public server treated mere reachability as permission to send onward.

Source-address rules were also a poor answer for a mobile user. A traveler could possess a valid account while appearing from an unfamiliar network. Conversely, a machine inside an allowed address range was not necessarily the person entitled to use a sender identity. POP-before-SMTP tried to borrow a recent login from another protocol, but joined two sessions through an address and a timer rather than through the act of submission itself.

The 1999 SMTP Authentication extension, later replaced by RFC 4954, moved the question into SMTP. A server advertised AUTH in its EHLO reply together with a list of SASL mechanisms. A client selected one mechanism and completed its challenge-and-response exchange before beginning a mail transaction. Success produced a session fact: the server had accepted an authentication exchange and derived an authorization identity under local policy.

That fact could justify relay access. It did not say who wrote the message.

Authentication and authorization were different names

SASL supplied the essential distinction. The authentication identity belongs to the credentials: the account, certificate or other principal the server verifies. The authorization identity is the identity the client requests permission to act as. The server must decide whether the credential-bearing identity may assume the requested role.

The split is not ceremonial. One administrator may operate a shared service account. One mail queue may authenticate as a server while relaying messages originally submitted by many users. A delegated assistant may be allowed to submit for one mailbox but not another. A compromised credential may authenticate correctly while requesting an action it was never meant to perform.

SMTP therefore did not make a login string equivalent to MAIL FROM, the visible From header or a human author. It made the authorization decision explicit enough for the receiving server to enforce. The credential answers “who established this session under this mechanism?” Local policy answers “what may that identity do here?” The envelope and content pose later questions.

Submission became its own boundary

RFC 6409 turned this logic into a distinct service. Port 587 identifies message submission from a Mail User Agent to a Message Submission Agent. The MSA accepts a new message from a user-facing client, corrects or rejects certain local errors, and then delivers it or relays it into the MTA network. Public transfer between MTAs remains a different relationship.

By default, an MSA must reject the MAIL command with authentication-required status when the session lacks SMTP AUTH or another independently established authorization, such as a protected subnet. This is narrower than requiring every mail relay on the Internet to authenticate every upstream peer as a user. It places strong admission policy where the provider and submitting client have a direct relationship.

The boundary made roaming practical. A client no longer needed to appear from its provider's access network to prove entitlement. It could authenticate over the submission service and receive only the relay rights attached to that account. At the same time, an inbound MTA could continue accepting mail for its own domains without becoming an open relay for arbitrary destinations.

The authority belongs to the MSA's policy. IANA's registry can assign the AUTH keyword and SASL mechanism names. It cannot decide whether a credential may send as a finance mailbox, operate a mailing list or relay to the whole Internet.

One session could carry several sender identities

RFC 4954 added a second use of the word AUTH: an optional parameter on MAIL FROM. The AUTH command authenticates a session. The AUTH= envelope parameter associates one message with the identity said to have submitted it to the delivery system.

These values need not be the same. The standard explicitly allows one authenticated identity to carry messages for many authorized identities; a queue-processing server is the clearest example. The relay logs in as itself, but each message may retain a different original submitter. That is delegation, not contradiction.

The rule also gives uncertainty a representation. AUTH=<> means that the original submitter is unknown or insufficiently authenticated. A receiving server must not fill that gap by pretending the current authenticated relay was the original author. If an upstream assertion is not trusted, the safe value is unknown, even though the upstream connection authenticated successfully.

Among cooperating agents in a trusted environment, a server may preserve the supplied submitter mailbox when it relays onward. Outside that relationship, the syntax does not create trust. A mailbox inside AUTH= is an assertion whose authority comes from the authenticated upstream and the receiver's configured policy, not from the angle brackets.

Encryption protected the exchange, not the meaning

Authentication mechanisms do not all protect credentials in the same way. RFC 4954 requires servers to support a configuration that withholds plaintext-password mechanisms unless TLS or another protective layer is active. The advertised mechanism list may change after STARTTLS because a mechanism unsafe in cleartext can become acceptable inside a protected channel.

Modern submission guidance recommends TLS for all traffic between user agents and submission servers. Port 587 commonly combines submission with STARTTLS; port 465 begins implicit TLS before SMTP commands. Correct certificate validation helps a client know which server receives the credential, while encryption prevents a passive observer from reading it.

Those properties are substantial, but bounded. TLS can protect one connection. SASL can verify a credential and sometimes negotiate its own security layer. Neither proves that the person named in the visible header wrote the text, that the message remained unchanged after the submission boundary, or that every later relay used encryption. RFC 4954 says the distinction directly: SMTP AUTH authenticates submission, not authorship of message content.

The trace recorded a hop, not a biography

After successful authentication, a server can use registered Received transmission tokens such as ESMTPA or ESMTPSA. They record that SMTP AUTH, or SMTP AUTH plus TLS, applied when that server accepted that hop. This is valuable operational evidence. It can separate an authenticated submission path from unauthenticated inbound transfer and help diagnose abuse or policy failure.

A trace token does not make previous lines trustworthy or future hops secure. It records what one server says happened at its boundary. The consumer still needs to know which server produced the field and whether that server is inside the administrative trust domain. Hop evidence becomes dangerous when a filter promotes it into a universal identity claim.

The same restraint applies to status codes. A 235 reply records successful authentication. A 530 refusal says the requested action requires authentication. A 535 reply says the presented credentials were invalid or insufficient. None says that a header address is true or that a message deserves delivery. Admission, sender authorization, content authenticity and recipient policy remain separate decisions.

A registry could standardize choices without choosing accounts

SMTP AUTH used two registries to keep extension growth interoperable. The SMTP registry records the AUTH extension and its command and parameter surfaces. The SASL registry records mechanism names with references and usage status. A server can advertise a list a client understands without embedding one permanent password method into SMTP.

Replaceability was a security feature. A mechanism can become limited or obsolete while the SMTP extension remains. A stronger mechanism can be registered without redesigning every application protocol that uses SASL. The common layer names the choice; local operators decide what to offer, clients decide what to accept, and both sides bear the consequences of stale configuration.

The registries do not run an account database. They do not grant relay rights, map credentials to mailboxes or certify the person behind a message. Their authority ends at common vocabulary and references. Running systems retain the final authorization decision.

The useful login was the one that stopped at the gate

SMTP AUTH helped close a structural gap. Mail submission needed a portable way to recognize a client without treating its current network address as its identity. SASL supplied replaceable authentication mechanisms and a distinction between credentials and permitted action. The submission protocol placed that relationship at a provider-controlled boundary. The per-message parameter preserved an asserted submitter only when trust justified it and preserved uncertainty when it did not.

The design works because a successful login remains smaller than a signature. It can open relay access, select a policy set and create auditable hop evidence. It cannot certify every sender field, human intention, content byte or later relay. The credential did not sign the message. It proved enough for one server to decide whether to let the message enter.

Sources