I like this approach, but it's had its complications for us because we
don't want to make the compromise of doing the rest of the checks at a
given stage needlessly; e.g. if our RBL plugin hits, we don't want to
bother doing RDNS and SPF lookups only to say 'sorry, you were on an
RBL' afterward. Have you come up with an intuitive way to deal with
this sort of thing? We have come up with some ways, but I don't know
that I'd call it intuitive, yet :)
One thing we've done that dealt with the problem somewhat was to expand
the idea of the DSN object to be more customizable and to specify all
the information we need for logging, and for deciding what to do when a
particular filter hits. It hasn't really addressed the issue
completely, we've got three or four different methods in place dealing
with variations on the same problem right now...
-Jared
On 06/19/2009 12:12 PM, Chris Lewis wrote:
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.
