My inbound gateway (currently running v16) appears to use this processing sequence:
Inbound SMTP module
- Process the HELO/EHLO
- Check IP blocklists
- Verify Recipients (v17 and later)
- Accept message
- Invoke Declude (or presumably any other external filter)
- Wait for Declude pass-back
- Invoke Antispam rules
- Check SPF
- Check Antivirurs
- Check DMARC
Deliver message if not blocked or quarantined.
This means that there are many reasons why a message might be rejected, but SM cannot notify the sender that the message has been rejected. I have been in discussion with Support about the importance of avoiding Non-Delivery Reports for incoming messages, and these issues have been addressed in the most recent releases. This means that most rejected messages will be silently discarded.
The best process would be to defer message acceptance until a final decision is made to reject or deliver. Since Declude handles deletes by failing to return the message, this would need a timeout smaller than the SMTP timeout values.
The SMTP timeout minimums are actually quite large, as defined here:
which leaves plenty of time for most validation checks to occur. So there is no need to accept the message at the time that it occurs.
This probably creates no small disruption to the current design, but it should be evaluated for the long haul.