Charlie Brady wrote:
It's not as though there are any SMTP clients out there which will try again with a different helo host. Unless there is a spambot tuned for this qpsmtpd plugin.
There are plenty of bots that do that.
I don't understand your statement here. In what way would any client be better off with a connection help open following the DENY, than having DENY_DISCONNECT?
It would be better for qpsmtpd in the long run for ALL of the "filter decision" plugins to note what they found in ->notes(), and always issue DECLINED. Leave it up to a single meta-plugin run last in every SMTP phase to decide how to change the SMTP state (deny, deny_disconnect, score, etc).
The reaction to a plugin filter hit should be orthogonal to setting a filter hit. Meaning: a filter hit doesn't change SMTP protocol state, that's another plugin's job.
In this way, you retain the flexibility to set the engine's behaviour - whether it be "deny immediately", "deny at RCPT TO", "deny after DATA", "score", "whitelist", etc _independently_ of the plugin rule hit.
By doing this you don't have to add "what to do when you get a hit" configuration to every plugin - they don't have to know about whitelisting mechanisms or what state to go to. Simplifying the filtering plugins greatly.
I had to rewrite (usually from scratch) every one of the qpsmtpd plugins to make that happen in our implementation.
