[Bug 5896] RFE: rules for enemieslist

[bu...@bugzilla.spamassassin.org]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5896


Steven Champeon <sc...@hesketh.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schampeo@hesketh.com




--- Comment #7 from Steven Champeon <sc...@hesketh.com>  2008-09-03 14:33:36 PST ---
(In reply to comment #6)
> Sorry to the listeners for the triple post, but just so it is documented as
> well, when looking at this regex pattern inclusion idea, there should be
> multiple sets of regex patterns.  Some will be guaranteed to be spam sources,
> some guaranteed to be dialup, and some regexes need to test it this is a
> customer relaying outbound, vs MTA -> MTA expected traffic etc.. Some regexes
> may even be confirmed by the network operator, and all should be treated
> differently.. Possibly we need to have separate static regex files for
> different classes, along with contrib/testing/approved seperate files for each
> class.

I'm working on a ruleset, though what I have at present requires modifications
to
DNSEval.pm to support the way the enemieslist DNSBL works (pre-pend a hostname
or HELO string to a zone, an A record lookup returns 127.0.x.x showing how
we've
classified the naming convention, a TXT record lookup returns a string showing
what else we know about the technology in use). I'll also look at doing a
separate
plugin so as not to require mods to DNSEval.pm, and submit it for testing. 

With respect to your comments above:

1) the DNSBL has three mirrors and is a slightly modified rbldnsd; it should
be relatively easy to get more mirrors if needed (and I have no illusions about
need
should this ruleset be incorporated into SpamAssassin)

2) I'd prefer not to incorporate the actual patterns themselves into
SpamAssassin;
licensing the patterns to corporate users is how we sustain the project, so if
we
were to require the patterns be distributed as part of SpamAssassin we'd also
have to discuss licensing terms, etc. So let's stick with the DNSBL for now.

3) EL doesn't list "spam sources", it classifies hosts based on their PTR
naming
and is not to be used in deep header inspection (except possibly to frown on 
possible forged hostnames within a given domain, but that's more complex than
the ruleset I've got right now). I've found that listing spammers with static
naming
using regexes is worse than useless, due to the high rate of change and
turnover.

4) I don't have a problem with SA coming up with a community-based scheme for
maintenance on a superset of patterns, as long as it's compatible with my
current
DNSBL return codes, but I doubt there'd be much interest beyond people
submitting
hostnames and expecting someone else to do the regexes (based on ~5 years 
experience with my project). 

5) We use a DNSBL primarily because distribution and updating of large regex
files
to multiple users was an annoying pain the in butt. 

So, lots of questions, about reliability, licensing, and distribution. But
let's keep
this discussion going.


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.