SMTP capabilities

After the greeting, the probe sends EHLO, records the capability list the server answers with, and quits. It is reported as information: there is no pass or fail here, only what the server says it can do.

The list is more useful than it looks. STARTTLS gets its own check. SIZE declares the largest message the server will accept, which is the answer to most "why did this bounce" questions involving attachments. 8BITMIME, SMTPUTF8 and CHUNKING describe what it will accept inside the message. PIPELINING and ENHANCEDSTATUSCODES are about efficiency and error reporting.

The one worth looking at twice is AUTH. Advertising authentication on port 25 before TLS is negotiated means credentials can be offered over a plaintext link, and it tells the internet this host is worth trying passwords against. Inbound mail from other servers never authenticates, so there is rarely a reason for it to be there at all.

What the probe deliberately does not do is send MAIL FROM or RCPT TO. Those are what a mailbox validator sends, and this is not one — the capability list is everything that can be learned without asking the server about a person.

Move user submission to port 587 and take AUTH off the port 25 listener. RFC 6409 exists for that split, and mixing them is how a mail server ends up in credential-stuffing target lists.

Make SIZE reflect reality. A declared limit larger than what the storage backend or the filtering layer will accept turns a clean rejection during the SMTP conversation into a bounce generated after acceptance, which is slower and much harder to explain to the sender.

Beyond that, read the list against what you believe you configured. A capability you did not expect, and one you expected and cannot see, are both worth a look at the configuration — and this is the only view of it available from outside.