You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2019/07/22 18:31:40 UTC
[Bug 7742] New: "delay delivery" threshold
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: dev@spamassassin.apache.org
Reporter: brian@interlinx.bc.ca
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.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
RW <rw...@googlemail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rwmaillists@googlemail.com
--- Comment #7 from RW <rw...@googlemail.com> ---
FWIW I deliver anything I want to delay to an IMAP sub-folder Junk.quarantine,
a shell script then scans each mail that's done its time and passes it to
dovecot-mda+sieve for final delivery. An advantage of this is that the delayed
mail is easily accessible from IMAP.
I use Bogofilter to do the initial triage, delaying anything not positively
identified as ham, but there's no reason SA couldn't be used for both stages
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billcole@apache.org
--- Comment #6 from Bill Cole <bi...@apache.org> ---
(In reply to Brian J. Murrell from comment #2)
> I can appreciate that it would be more ideal to push this up into the MTA,
> but I doubt how many MTAs could actually handle it or even gathering
> interest in having them handle it.
Not necessarily the MTA proper, but the 'glue' layer between an MTA and SA,
e.g. a milter, a script wrapping spamc that re-injects scanned mail or delivers
it, etc. For example, the Milter API includes a "quarantine" action reply from
the milter to the MTA and both Sendmail and Postfix will hold messages in a
special queue if a milter responds with that reply. Amavis and MIMEDefang both
support quarantine mechanisms based on SA scoring.
In other words: glue layers and MTAs already have quarantine implementations
which can be used to sideline messages based on SA scoring. Logic and tooling
for rescan and/or release from those existing facilities makes more sense than
building a whole new quarantine facility in SA.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |apache@hege.li
Resolution|--- |INVALID
--- Comment #1 from Henrik Krohns <ap...@hege.li> ---
Queueing is not something that SpamAssassin would do or even could do. What you
propose is the job of the MTA/glue that is calling SpamAssassin.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
--- Comment #3 from Henrik Krohns <ap...@hege.li> ---
(In reply to Brian J. Murrell from comment #2)
> I can appreciate that it would be more ideal to push this up into the MTA,
> but I doubt how many MTAs could actually handle it or even gathering
> interest in having them handle it.
There's nothing "ideal" about pushing it to MTA/MDA, SpamAssassin is simply not
a mail delivery agent, it's a content scanner, in a chain of possibly many
filters/milters. What you propose does not need any new code or features, one
can scan message as many times needed.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@apache.org
--- Comment #5 from Kevin A. McGrail <km...@apache.org> ---
If you want this, use greylisting at the MTA level. This is not something for
SA to implement.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
Brian J. Murrell <br...@interlinx.bc.ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |brian@interlinx.bc.ca
--- Comment #2 from Brian J. Murrell <br...@interlinx.bc.ca> ---
I can appreciate that it would be more ideal to push this up into the MTA, but
I doubt how many MTAs could actually handle it or even gathering interest in
having them handle it.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7742] "delay delivery" threshold
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7742
--- Comment #4 from Henrik Krohns <ap...@hege.li> ---
PS. People are very sensitive to mail delays anyway, greylisting is also not
very popular these days.
What one would do is simply deliver the mail as is, but scan it later from the
mailbox, and if it's unread and now spam, then it still can be
removed/quarantined. But also this has nothing do with SA itself.
--
You are receiving this mail because:
You are the assignee for the bug.