Your question
I need to ask about the setting “Reject Non-FQDN” in the MTA → Session → EHLO Stage. If this is configured in the Web UI as ‘true’ is a Sieve Script required in order to enable this blocking to occur?
I currently have the setting Reject Non-FQDN configured to ‘true’, however I am seeing entries in my logs showing IP addresses being accepted at the EHLO stage.
Log Entry:
listenerId = “smtp”, localPort = 25, remoteIp = 172.94.9.203, remotePort = 12264, domain = “[100.27.4.110]”
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
No, “Reject Non-FQDN” is a built-in check performed by the EHLO stage itself and does not require a Sieve script. When rejectNonFqdn is enabled, Stalwart rejects the EHLO/HELO command directly with 550 5.5.0 Invalid EHLO domain. before any Sieve script for that stage even runs (the script field is a separate, optional field that runs only after a successful EHLO).
That said, the check itself is intentionally simple: it only verifies that the EHLO/HELO parameter contains at least one dot in its labels (has_valid_labels), it isn’t a strict FQDN/PTR validation. An address literal like [100.27.4.110] still contains dots, so it passes this naive check and is accepted even though it isn’t really a fully-qualified hostname. That’s consistent with what you’re seeing in your logs; the connection with domain = "[100.27.4.110]" is being treated as having “valid labels” because of the embedded dots in the IP literal, so rejectNonFqdn doesn’t reject it.
If you want to also block bracketed IP-literal EHLO greetings, you would need to add a Sieve script on the script field of MtaStageEhlo that inspects the helo_domain variable and rejects patterns like [...] explicitly.
Reference: EHLO stage docs
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.