Daryl C. W. O'Shea writes: > Justin Mason wrote: > > Daryl C. W. O'Shea writes: > >> Justin Mason wrote: > >>> it hits 50% of your spam corpus with no FPs ;) > >>> > >>> http://ruleqa.spamassassin.org/20061109-r472811-n/T_HDR_ORDER_FTSDMCXX3/detail > >> f*#ckin' eh! Nice score-map too. > >> > >> Talk about short circuit capability... I could run that rule in my > >> milter before even passing the message off to SA. > > > > Save yourself the bother -- just load the Shortcircuit plugin, give it an > > early priority, and add "shortcircuit HDR_ORDER_FTSDMCXX3 spam" to your > > local.cf. er, well, you'd have to upgrade to svn trunk too I suppose ;) > > I'm not really in need of any short circuiting right now so I haven't > got around to looking at if it'd be usable for me... I need to be able > to disable short circuiting on a per user basis, much preferably without > having to set "shortcircuit lines" for each affected rule on a per user > basis. > > Basically, I haven't looked to see if a user can set something like this > in their user_prefs: > > shortcircuit_enabled (0 : 1) > > ...if there isn't such a feature, we should probably add it.
Yes, good point. > > It's pretty sweet -- entirely local, entirely header-based. that'd be > > _fast_. > > Even faster in the milter, before even accepting the message body. ;) Well, to be honest, I think the idea of needing to do stuff up-front in a milter, before SpamAssassin, is a bug ;) It should be possible for us to do efficient tests inside SpamAssassin, too. Having some way to start running shortcircuited header rules even before the body has been parsed is one key factor there. > > Funny that the spammer mails you so much, compared to the rest of us, > > though... the ways of spammers are mysterious indeed. > > I imagine it has a lot to do with me not using any DNSBLs in front of my > corpus accounts/traps (I wait for rcpt to: before rejecting on DNSBLs). ah, good idea. for what it's worth, I've turned off DNSBLs on my MX MTA configuration too.... --j.
