The Split Between Submission and Relay Ports

The same command language serves two jobs with incompatible trust models. A relay accepts mail from another server it does not control and forwards it toward a destination it does not own. A submission server accepts mail from a user it has authenticated and takes responsibility for that user’s identity. Running both on one port meant that every policy written for one job weakened the other, and the eventual answer was to separate them by port and treat the port number as a role declaration.

What the relay role actually promises

A receiving MTA on port 25 answers for a domain. It decides whether to accept a message for a recipient, and if it does, it accepts an obligation to deliver or to report failure. It has no relationship with the sending client beyond the connection, and it cannot assume the client is authorized to send as anyone. Historically it accepted mail for its own domains from anyone and relayed mail for anyone to anyone, an arrangement that lasted as long as the network was small and cooperative.

Open relay is the failure mode of that arrangement. A server that forwards mail for arbitrary senders to arbitrary recipients becomes a laundering point: the message’s final delivery comes from an IP with no relationship to the sender, so any reputation attached to the IP is meaningless. The countermeasure was to make relaying conditional: accept for local domains unconditionally, accept for remote domains only from clients that are authorized, and refuse everything else with a permanent error.

Authorization for a peer MTA cannot be based on user credentials, because an MTA forwarding mail on behalf of thousands of senders has none to offer. It is based on network position or on a shared trust arrangement between the two servers. That is a fundamentally different kind of proof from a username and password, and it is why the two roles cannot share one authentication policy.

What the submission role adds

RFC 6409 defines submission as a distinct service, historically on port 587, with several requirements that a relay does not carry.

The client must authenticate. The server must not accept a message from an unauthenticated client for relay to a remote domain, which removes the open-relay problem by construction rather than by configuration.

The envelope sender must be authorized. A submission server is expected to reject a MAIL FROM that the authenticated user has no right to use, rather than accepting it and letting the receiving side discover the mismatch. This is a policy check on the envelope, and it is the reason submission servers are the natural place to enforce outbound sender authorization.

The server may rewrite. Submission is allowed to add headers, fix malformed ones, and in some configurations rewrite the From header to a canonical address for the authenticated account. A relay must not do this: it has no authority over the message’s content, and rewriting at a hop that did not author the message breaks signatures and misattributes the sender.

Message format checking is stricter. A submission server can reject a message that lacks a Date or Message-ID and add them itself, because it is the point of origin for that message and can legitimately fill in what the client omitted. A relay receiving a message with no Date must pass it along, since adding one would claim a timestamp it did not observe.

The port number is the only signal a client gets about which policy applies, and the separation is load-bearing: the same software, on the same host, behaves differently on 25 and 587. Deployed submission servers often listen on port 25 as well, for clients that cannot reach 587, in which case the distinction is made by authentication state rather than by port number. That fallback is the source of most of the ambiguity in real configurations.

Telling a user from a peer

A server that listens on both ports and applies one policy must classify each session. The available signals are weak individually.

Authentication state is the strongest. A session that has completed AUTH is a user; a session that has not is either an unauthenticated user or a peer. But AUTH is only available if the server advertises it, and deployed servers commonly advertise it only after STARTTLS completes, because the plaintext mechanisms send credentials in the clear. The first commands of a session therefore arrive before any identity is known.

Network position is the second signal. A connection from a known outbound relay’s address range is a peer; a connection from a residential address range is a user. This works until a user roams onto a network that looks like a peer, or a peer sends from an address that is not in the expected range. The classification is a heuristic and it fails at the edges.

The EHLO argument is a third, and it is worthless as a trust signal. A client identifies itself with a domain name, which is unauthenticated text. A spam client can send any name. Some servers use the absence of a plausible name as a negative signal, which is only a small amount of information and is easy to forge in the other direction.

Because none of these is sufficient alone, deployed policy is usually a conjunction: accept relay to remote domains only if the session authenticated successfully and the envelope sender is within the authorized set; otherwise accept only for local recipients. A message from an unauthenticated client to a local recipient is a legitimate case, since that is how mail from the outside arrives, and it must be distinguished from an unauthenticated client trying to relay outward.

Policy for a session, evaluated at RCPT TO:

  recipient domain is local            -> accept (subject to recipient existence)
  recipient domain is remote:
      session authenticated as user U  -> accept only if MAIL FROM is in U's allowed set
      session is a trusted peer (IP)   -> accept (relay)
      otherwise                        -> 550 5.7.1 Relaying denied

The third branch is where misconfiguration becomes an open relay. A trust rule written as an IP range that is too broad, or a peer check that consults a header rather than the connection, turns the server into a forwarder for anyone who can reach it.

Consequences of the split for clients and for mail flow

The submission port changed client behaviour in ways that are visible in the protocol. Clients that once sent directly to the recipient’s MX now send to their own provider’s submission server, which means the first hop of nearly all mail is authenticated and the provider can apply outbound policy. That is the architecture that makes sender authentication at the domain level enforceable at all: the provider knows which account sent a message, so it can sign for the domain that account belongs to.

It also created a class of failure that did not exist before. A client configured with the wrong port gets a policy error that looks like a protocol error. Connecting to port 25 and attempting AUTH fails if the server does not offer it there; connecting to 587 and attempting to relay without authentication produces a 5xx that the client may report as a credentials problem. The error codes are the only diagnostic, and they are frequently misread.

The split also interacts with the delivery chain downstream. A message accepted at submission enters a queue with an obligation to deliver or bounce, which is the same obligation a relay carries, and the queue behaviour is described in Queue Management and Retry Scheduling in MTAs. The difference is that the submission server knows who submitted the message, so a permanent failure can be reported to a real mailbox rather than to a forged return path.

Finally, the port distinction is a security boundary that is only as good as the listener configuration. A submission server exposed to the whole internet with no authentication requirement is an open relay with a different port number. The policy is not in the port; the port is a label that tells the client which policy to expect, and the server has to enforce the policy independently.

Where the two roles meet the same protocol extensions, the differences matter too. A submission client can use CHUNKING and PIPELINING freely because it controls the whole message; a relay must handle whatever the previous hop sent, including features the next hop does not support. Extension negotiation is covered in ESMTP Extension Negotiation and Its Failure Modes.