Issue Description
Domains listed in the Blocked-Doman list aren’t blocked during the MTA process.
Expected Behavior
Add a domain to the Block Domain list and the domain will be rejected during the EHLO stage.
Actual Behavior
Mail is accepted for delivery even if the EHLO domain is listed in the Block Domain list.
Reproduction Steps
Add a domain to the Block Domain list, and send an inbound e-mail from the blocked domain. The e-mail will be received for delivery and delivered to the local receiver.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
Additional Context
It appears that blocking e-mails based on Domain requires adding Sieve scripts, and than configuring the correct stage to use those Sieve scripts to block the receipt of mail from domains added to the Block Domain list. Meaning simply adding to the list does nothing, and additional manual configuration has to be put in place to render the Block Domain list as useful. I believe this to be true for several other configuration options that have to do with blocking mail. For example it appears though is not well documented that you need to manually add Sieve scripts to block mail if it does not align with DMARC / SPF. There doesn’t seem to be a setting already established in the User Interface to accomplish this.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
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
This confirms the user’s report is accurate as documented: the Block Domain list is a lookup list, not an active enforcement rule by itself. It only takes effect if a Sieve script explicitly checks the EHLO/HELO domain against it (e.g. :list "${env.helo_domain}" "list/blocked-domains") and rejects, and that script is then wired into the MTA stage (EHLO stage via MtaStageEhlo).
This confirms the reporter’s observation: this is expected behavior, not a bug, per the current docs.
Adding a domain to the Block Domain list only creates an entry in that list; it does not automatically enforce rejection at any SMTP stage. To actually reject mail from listed domains you must write a trusted Sieve script that checks the list (e.g. if string :list "${env.helo_domain}" "list/blocked-domains" { reject ... }) and then wire that script into the relevant SMTP stage’s script field, such as MtaStageEhlo for HELO/EHLO domain checks, or MtaStageRcpt for the RCPT/sender domain. The docs give exactly this example script for HELO domain blocklisting.
The same applies to DMARC/SPF-based rejection: Stalwart evaluates and reports these results, but whether to reject is determined by Sieve logic bound to an SMTP stage, not by a standalone toggle in the WebUI. There currently isn’t a UI setting that automatically wires “Block Domain list” entries into rejection at EHLO/RCPT; you need to add the Sieve script yourself as shown in the Trusted Interpreter docs and the Sieve examples page.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
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]”