Summary

  • RFC 5383 records that hotels and other access providers sometimes intercepted outbound port-25 connections regardless of the destination host, potentially delivering sensitive mail to an unknown third-party server without the user's awareness.
  • Port 587 gives message submission its own service and policy boundary, but a port number is not an identity credential. Intended endpoint, observed peer, TLS identity, authenticated principal, submission acceptance, relay and recipient outcome need separate evidence.

The successful connection that changed the counterparty

The disturbing feature of interception is not that the connection fails. Failure is visible. A timeout, reset or policy error tells the user and operator that the intended path did not complete. Interception can produce the opposite signal: the socket opens, an SMTP banner arrives and the application proceeds.

RFC 5383 section 3 describes exactly this risk. Message user agents had historically used port 25 for submission. At the same time, access providers increasingly restricted outbound port 25. Some hotels and other public accommodations went further and intercepted port-25 connections irrespective of the destination host. A user who believed the client was contacting the configured mail service could instead be speaking to an unknown, untrusted third party.

That is not merely a routing oddity. It is a substitution of the operational counterparty. The access network ceases to be only a carrier and silently chooses an application endpoint. The user sees connectivity where the important fact is discontinuity between the destination named and the party that answered.

The standards record does not establish how often this occurs today, which operators did it or whether any named message or credential was exposed. Its value is architectural. It shows why a green connection indicator cannot be allowed to testify about destination fidelity.

Why submission needed its own door

Internet mail has several stages. A message user agent creates and posts a message. A submission service applies policy, may authenticate the user, repairs or rejects defects within its authority and accepts the message into the mail handling environment. Transfer agents then relay it. A destination system may place it in a mailbox. A reader may or may not retrieve, display or act on it.

RFC 2476 created Message Submission as a distinct service. RFC 4409 revised that design, and RFC 6409 is its current successor. Port 587 gave the posting relationship a conventional rendezvous separate from port 25's transfer role. RFC 5383 therefore required Lemonade clients to be able to reach port 587 and stressed that clients should use it by default.

The separation is institutional as much as technical. It gives operators a place to define client authentication, submission policy, extension support, rate controls and accountability without pretending that every relay-facing decision belongs in the same surface. It also makes blocking or permitting the service more legible to a firewall team.

But the number 587 is not a certificate. A packet reaching that port does not prove which organization owns the service, whether the intended hostname survived the path, whether encryption is active or whether the authenticated account has permission to submit this message. The separate door makes the decision reviewable. It does not decide the case.

A port is a coordination label, not a security principal

Port numbers help two implementations agree on which service is expected. IANA's registry preserves that shared vocabulary. The label reduces ambiguity at the rendezvous layer; it does not authenticate the process listening there.

That distinction matters because several claims are easy to collapse. DNS resolution may show which address was returned. Routing may show where packets travelled from one vantage point. A TCP handshake may show that something answered. An SMTP greeting may identify software or announce a name. TLS may authenticate an identity if the client validates the correct reference identity against a trustworthy certificate path. SMTP authentication may establish an account under the answering server's policy. None of those receipts automatically proves the next one.

RFC 8314 later recommended TLS for email submission and access and documented the registered submissions service on port 465, while recognizing the established STARTTLS path on 587. That later guidance sharpens the present lesson. Moving away from cleartext improves confidentiality and endpoint authentication only when the client actually negotiates and validates the protected channel correctly. Renumbering alone cannot repair a trust failure.

The minimum evidence record must therefore preserve the intended hostname, resolved address, observed peer, destination port, TLS mode, certificate identity, validation result, negotiated SMTP capabilities, authenticated principal, submission response and later message status separately. A single “connected” boolean destroys the distinction RFC 5383 asks operators to see.

Interception is more dangerous than an honest block

Organizations may have legitimate reasons to restrict port 25: spam control, abuse containment, compromised-host policy or protection of internal infrastructure. RFC 5383 does not deny that operators can make security decisions. It objects to a particular opacity: traffic aimed at one host can be accepted by another without the user understanding the substitution.

An honest block preserves agency. It tells the client that the selected route is unavailable, allowing fallback, support escalation or a conscious policy decision. A transparent refusal can be logged and tested. Silent interception creates false progress. The user may disclose message content, credentials or metadata to a party that was never selected, while the operator's dashboard records success.

Application-level firewalls introduce a related risk. RFC 5383 notes that some intercept SMTP and permit only a subset of the protocol. If one side sees an extension negotiation that the middlebox only partly understands, the session can drift out of synchronization and fail later. The transport surface looks open, yet the application contract has been rewritten in flight.

This Article does not take over the broader firewall-transparency thesis already covered in BTW's RFC 2979 analysis, nor the HTTP-tunnelling boundaries owned by RFC 3093 and RFC 3205 coverage. The narrower point is counterparty evidence: a path device must not be mistaken for the submission service the user chose merely because it can answer on a familiar port.

Acceptance is not delivery

Even when the correct submission server is reached and authenticated, a successful SMTP response has bounded meaning. It can show that the service accepted responsibility under the current transaction and policy. It does not prove every later relay, destination mailbox commit, notification, rendering or human read.

This matters during incident review. Suppose a client log says “sent,” the submission service has a queue identifier and the recipient reports nothing. The investigation should not argue over one global success flag. It should join a chain: endpoint selection; protected-channel identity; authenticated submission principal; envelope and message acceptance; queue custody; relay attempts; destination response; mailbox placement; and reader-facing state.

Interception damages the chain at its beginning. If the answering server was substituted, later identifiers may belong to the wrong administrative system. A plausible banner or 250 reply can make the record look more complete while actually disconnecting it from the intended service.

The correct response is not to claim that all port-25 use is hostile or that port 587 guarantees delivery. It is to insist that every layer state only what it observed.

A practical conformance and incident test

Start with a controlled client configured for a known submission hostname. Record the DNS answer and the expected certificate identities. Exercise the path from several access networks. Compare the destination selected by the application with the peer reached on the wire. Test port 25 only as a negative or legacy case; test the intended submission service on 587 and, where policy requires it, the protected submission service on 465.

On every path preserve TCP peer addresses, SMTP banner and capabilities, TLS negotiation, certificate chain, reference-identity check, authentication mechanism, principal, response codes and timestamps. Inject controlled failures: wrong certificate, missing STARTTLS, unexpected banner, capability removal, redirecting address and explicit port block. The client must fail in ways that are visible and attributable. It must not silently downgrade endpoint identity to preserve a green status light.

Then test the later stages independently. A successful submission should produce a service-owned receipt, but the relay and destination canaries must establish their own outcomes. The objective is not a theatrical end-to-end badge. It is a ledger in which no component can borrow authority from another.

Sources