https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
Bug ID: 7742
Summary: "delay delivery" threshold
Product: Spamassassin
Version: 3.4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: spamc/spamd
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
So, it seems that the root cause of #7739 was in fact that I seem to be getting
spam slightly before it's sources have hit the BLs. I know for a fact this was
the case for PSBL in #7739 and suspect as much for spamhaus.org's BLs, but
since their lookup service doesn't provide "date listed", I can only assume.
But that had me to thinking... this must be a general problem and could become
more prevalent if/when spammers are able to amass such distributed resources as
to spam just about everybody within a very short period of time.
A defence against this would be to have a "might be spam" threshold below the
"is spam" threshold, and when an item of e-mail is between those values, SA
puts it into a queue and reruns (perhaps only previously failed) tests on it to
see if it has become more spam-looking than when last tried.
At this point several things could happen. If the score didn't increase any
more since the last try, release it to deliver. If it exceeded the "is spam"
threshold, treat as spam per usual. If it's still between the two thresholds,
hold on to it a little longer and repeat previously failed tests again. Rinse,
repeat, until it's no longer increasing in value, a (hold) time-limit has been
met (and it's still not spam), and which point release it for delivery.
--
You are receiving this mail because:
You are the assignee for the bug.
