b-sub-564...@rope.net wrote:
I have a routine that I'm working on that is still rather imperfect.
Ideally, it would identify a particular type of spam and then reject it,
as other modules do. However, since there are too many false positives, I
have been rejecting, but also sidelining a copy of it to inspect manually,
and re-inject, if necessary.
I would rather tell the sender it was accepted, instead of rejected,
because legitimate senders who have their stuff sidelined end up getting a
bounce, and think their message didn't get through. Since the message has
already been accepted for testing, it probably doesn't matter if a spammer
thinks his message got through, as much as it matters to a legitimate
sender that his message may not have.
Clear as mud?
What I am thinking of doing is to have my routine return DECLINED after
identifying something to sideline, then set a note. The note would be read
by queue/qmail-queue and, if set, just silently drop it. Hopefully a minor
kludge to qmail-queue.
Or is it possible to tell the sender, at this point, that the message was
accepted, but not pass it on to qmail-queue?
This is approximately what we do:
Each of our filtering plugins, if they fire, set a "reason" transaction
note. They _always_ return DECLINED, hit or otherwise.
Each plugin in turn also decides whether to analyse the email at all if
a previous plugin has set the "reason" note. Returning DECLINED if so.
(hence subsequent more expensive tests can be skipped).
The queuing plugins as distributed have what I believe is a defect.
They all return "OK" if they manage to "deliver". What if you want to
do something different?
So, instead, we have a modified "queue/file" plugin ("quarantine") that
saves a copy of the email and always returns DECLINED, and next, we have
a forwarding plugin that forwards the email if no "reason" is set.
Then a final queue phase plugin that simply returns OK or a DSN
depending on reason setting (and other configuration).
The long and the short of this is that filtering is independent of
disposition (quarantine and/or forward), and is also independent of
reject or accept. Each of the plugins responsible for those bits make
their own decision based on configuration and what's gone before.
The end result being that we can, for example, quarantine and reject
based on filter hit. Quarantine and accept based on filter hit.
Whitelisting plugins that override filtering (by unsetting reason).
Etc. etc. etc.
We can also have filtering do "early rejects" (eg: on 100% reliable
DNSBL hits) without waiting for the body, but, we have the capacity to
quarantine everything, and it's useful for research.
Since we arrange to have a reject message that permits the sender to
resolve the problem AND the quarantine that the end users can see, we
don't do "accept and don't forward" except in unusual non-spam related
situations.
