SMTP connectivity — reading the port 25 check

Cathedra opens a TCP connection to port 25 on the primary MX host, reads the banner, sends EHLO, and looks for STARTTLS in the response. The check produces between one and two findings depending on what it can reach.

This is the most-misread check in the Examen output. The status often says info when techs expect pass or error, and reading that finding correctly is what separates a confident audit from a tentative one.

What the check actually does

The relevant code in SmtpConnectivityCheck.php:

$socket = @fsockopen($mxHost, 25, $errno, $errstr, $timeout);  // 5s timeout

It is a raw TCP connection attempt to port 25 on the lowest-priority MX target. No SMTP-level authentication, no message delivery — only enough conversation to confirm the server is reachable and advertises TLS.

If the connection succeeds, Cathedra reads the SMTP banner, sends:

EHLO codex.isidoregroup.net

Reads the multi-line response, looks for the string STARTTLS, then sends QUIT and disconnects. Two checks emit findings.

The three possible outcomes

Outcome 1 — Connection succeeds, STARTTLS advertised

The clean state. Two findings emit:

SMTP Port 25 Connectivity:

Field	Value
status	pass
severity	—
finding	“Connected to {mxHost}:25. Banner: {first 120 chars of banner}”

STARTTLS Support:

Field	Value
status	pass
severity	—
finding	“STARTTLS is advertised by {mxHost}. TLS upgrades are supported.”

This is what M365, Google Workspace, and any other competently-run mail server will return. Two passes.

Outcome 2 — Connection succeeds, STARTTLS missing

The MX accepted the connection but did not advertise STARTTLS in the EHLO response.

SMTP Port 25 Connectivity: pass (same as above).

STARTTLS Support:

Field	Value
status	warning
severity	medium
finding	“STARTTLS is NOT advertised by {mxHost}. Email may be delivered without encryption.”
recommendation	“Enable STARTTLS on your mail server to support opportunistic TLS.”

This is rare for cloud-hosted mail. When it happens, it is almost always a misconfigured on-prem appliance or a legacy mail filter that the client routes through. Real remediation item.

Outcome 3 — Connection cannot be made

The 5-second connect times out, or the socket fails for any reason. One finding emits:

Field	Value
status	info
severity	—
finding	“Could not connect to {mxHost}:25 within 5s. This server may be firewalled or port 25 is blocked outbound.”
recommendation	—

Note the status: info, not error. This is the critical distinction.

Why outcome 3 is info, not error

Port 25 is increasingly blocked outbound from cloud infrastructure. The Cathedra service runs inside an environment that may have port 25 blocked at the cloud provider’s network edge — AWS, GCP, and Azure all do this by default for some classes of compute instance. Microsoft and Google block outbound port 25 for residential and small-business ranges as a spam-control measure.

When Cathedra reports “could not connect,” there are three real possibilities:

1. Cathedra’s host cannot reach port 25 on anyone, because the network it runs from blocks outbound 25.
2. The destination MX is blocking inbound 25 from cloud IP ranges because the destination mail provider has IP reputation filtering at the network layer.
3. The destination MX is genuinely down or unreachable.

The first two are not problems with the client’s mail. They are network-path artifacts. The third is a problem, but you cannot distinguish it from the first two using the Cathedra finding alone.

This is why the status is info. Cathedra is admitting it does not know whether the failure is meaningful. Your job is to confirm with a second source.

How to confirm a real connectivity issue

If Cathedra returns the info finding and you suspect a real problem (the client reports delivery failures, or the MX is on-prem and not a known cloud provider):

1. Try the connection from a different vantage point. A laptop on a residential network, a small VPS at a provider known to allow port 25 outbound, or a different cloud account.
   nc -v {mxHost} 25
   or
   openssl s_client -connect {mxHost}:25 -starttls smtp
2. Check the MX from a service. MXToolbox, dnschecker.org, or any external SMTP-test service. These run their checks from multiple locations and will tell you whether port 25 is reachable from at least one of them.
3. Check delivery directly. Send a test message to a known-good external address that delivers to the MX in question. If delivery succeeds, the MX is fine and Cathedra’s finding is a network-path artifact. If delivery fails, you have confirmed a real problem.

For a major cloud provider like M365 (*.mail.protection.outlook.com) or Google Workspace (aspmx.l.google.com.), the info finding is essentially always a Cathedra-side network limitation. The MX is reachable globally; Cathedra’s host can’t see it. Move on.

For a client running their own mail on-prem, or routing through a specialty filter (Proofpoint, Mimecast, Barracuda), the finding could be real. Confirm before flagging.

What the banner tells you

When connection succeeds, the banner is logged. Examples you will see:

220 mxa-002c5f01.gslb.pphosted.com ESMTP Proofpoint

220 mail-am6eur05on2138.outbound.protection.outlook.com Microsoft ESMTP MAIL Service

220 mail.acme.local ESMTP Postfix (Ubuntu)

The banner is informational but tells you what mail platform is on the other end. Useful for cross-checking against the provider-detection finding (Module 2) — if Cathedra detected the provider as “Microsoft 365” but the banner says “Proofpoint,” the client routes through Proofpoint to M365, which is good to know.

Reading the EHLO response

The raw EHLO response is stored in raw_value (capped at 500 chars). When you click into a finding in Cathedra’s UI, you can see something like:

250-mail.example.com Hello [203.0.113.45]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250 CHUNKING

STARTTLS on its own line in this response is what the check looks for. Other capabilities (AUTH, SIZE, DSN) are informational. The presence of AUTH on the inbound MX is sometimes a misconfiguration — most cloud MXes do not advertise AUTH on inbound connections.

Cheat sheet

Condition	SMTP Connectivity status	STARTTLS status
Connected, STARTTLS advertised	pass	pass
Connected, no STARTTLS	pass	warning / medium
Connection timeout or refused	info (single finding; STARTTLS check skipped)	—

What you should remember

• The check is TCP connect on port 25, banner read, EHLO, look for STARTTLS, then QUIT. Five-second timeout.
• “Could not connect” is info, not error. Cathedra is saying it cannot tell whether the failure is real.
• For cloud-hosted MX (M365, Google Workspace), the info finding is almost always a Cathedra network-path artifact. Confirm with an external test if needed.
• For on-prem or specialty-filter MX, the info finding may be a real reachability problem. Confirm with a second vantage point.
• “STARTTLS not advertised” is warning / medium and is real — opportunistic TLS will downgrade to plaintext. Fix at the mail server.

---

Cathedra alignment: SmtpConnectivityCheck.php — port 25 connection attempt, banner read, STARTTLS probe