http://bugzilla.spamassassin.org/show_bug.cgi?id=3998
------- Additional Comments From [EMAIL PROTECTED] 2005-03-28 21:56 ------- Subject: Re: Add support for Habeas v2 >>I don't really see how a DNSWL is much different from a DNSBL which we >>currently implement via a plugin (URIDNSBL). > > The URIDNSBL plugin contains its own logic for scanning the body and a > dispatcher for multiple concurrent DNS requests. It's quite a different animal > from a wrapper that examines two header fields and then calls > check_rbl_backend(). For that matter, is it even possible for a plugin to call > check_rbl_backend()? Without looking at the code, I assume there wouldn't be a problem calling it. I don't believe it's a public API, but the plugin would be part of the distribution so we don't have to worry about it breaking. >>A Habeas, or Accreditor, plugin would still be included, and enabled, >>with the distribution just like URIDNSBL, SPF, SpamCop, etc. > > SPF is a plugin because it includes a heavy library and needs to issue its own > (possibly unbounded) set of resolver requests. The SpamCop plugin is for > *sending* complaint mail; checking the SpamCop DNSBL is a simple rule that > invokes check_rbl() in EvalTests.pm. Yeah, they weren't great examples -- implementation wise. I'm actually thinking that any rules/evals that depend on third parties should be in plugins. I know there was talk about thinning out EvalTests.pm... > I think the Habeas Accreditor code is more comparable to checking Sender Base, > which is in Dns.pm. Well, Dns.pm needs to be worked on too (either Net::DNS needs to support single socket background queries or we need to implement it ourselves -- I've got some code to do it but haven't tested it across different platforms). I'm thinking that Sender Base should also be in some sort of Accreditor plugin too. Maybe I'm alone on that. > There's another issue, which I should have pointed out in my first reply: In > the > presence of an accreditor, I need to disable the old Habeas "haiku" code. If I > didn't, senders who are in transition between the "haiku" and the Accreditor > style would get a -16 bonus. I don't think that's possible from a plugin. If the 'new Habeas' code was going to be moved to a plugin I'd think that the 'old Habeas' code would be moved to the same plugin, so that wouldn't be an issue. Of course, even if the code was kept separate, we could always use a meta rule for the old code (with a !NEW_HABEAS conditional) and take the penalty of needlessly running the test. I wouldn't recommend it, but it's one way. Daryl ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
