On 12/11, Marc Andre Selig wrote: > I used to think that the problem was that many masscheck > submitters don't clean out old messages (spam must be younger
The main problem, currently, is that masscheck very recently started taking much longer to run. On or just before this past Saturday. > than 6 months and ham younger than 18 months according to > <https://wiki.apache.org/spamassassin/CorpusCleaning>), so the numbers I believe that is out of date, and the thresholds for inclusion in re-scoring and ruleqa are both 6 years(!) for ham and 2 months for spam: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6557 (I just updated the wiki.) > So is the problem that axb's messages are reported too late? Basically, yes, I believe that is correct. Due to masscheck taking too long to run. > I understand that the alternative approach of having mass-check > verify that the age of a message is acceptable before actually > processing it would be a lot of work as mass-check currently uses > Mail::SpamAssassin::parse to find out the age of the message. Mass-check supports: --after=N only test mails received after time_t N (negative values are an offset from current time, e.g. -86400 = last day) or after date as parsed by Time::ParseDate (e.g. '-6 months') We could easily do the 6 year limit, but I guess doing a different limit for spam would be harder. But feasible. But also not our main problem. > (However, <http://rsync.spamassassin.org> shows that spam-axb-foo.log > has a timestamp of 12:05, just 3:15 hours after nightly-versions.txt. > As my version of auto-mass-check.sh does not use the -t or -a options with > rsync, this seems to suggest that axb already uses some such modification, > in which case I still don't understand where exactly the problem is.) Yep, that's weird. -- "Let's just say that if complete and utter chaos was lightning, then he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'." - The Color of Magic http://www.ChaosReigns.com
