-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Quinlan writes: > Matthew Cline <[EMAIL PROTECTED]> writes: > > > I thought the purpose of plugins was to allow for custom eval-rules > > that didn't have to be re-insterted into SA code after each upgrade. > > So then, why is URIDNSBL implemented as a plugin? I feel like I'm > > completely missing the point here. > > It is a useful example, but I kinda agree. Redesigning the DNS code > vs. integrating the URIDNSBL code and hoping it's not a > drain... laziness and simplicity should win here. ;-) The issues are (a) the over-monolithic nature of SpamAssassin, compared to a more flexible model where spam-detection techniques can be "plugged in" and "plugged out" as admins desire. E.g. in a future rev we could make plugins out of more parts of SpamAssassin, and an admin could turn off Razor, Pyzor, or DNS tests without affecting others easily, by tweaking their plugin config. Bear in mind that the URIBL lookups are quite slow, since they consist of a minimum of 3 packet round-trips per lookup (NS lookup, A lookup, DNSBL A lookup). So allowing people to turn those off easily is a big win. Currently all of our supported subsystems are monolithically linked right into the core code. It's not even like comparing traditional BSD kernel config to Linux/Solaris-ish kernel modules, since even in BSDland you can change #defines to turn off parts of the code, we can't even do that in current SpamAssassin ;) (b) as a test of extensibility and the plugin API. Designing this as a plugin gave me some good pointers as to what hooks we needed in the check() process. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFAS+ySQTcbUG5Y7woRAo2IAKCRI5N6/uQmVZ6gF6yBmPNfscq3RgCfcX6B 2FNjWTVoU5yzPr7bJmyW5i4= =MOEJ -----END PGP SIGNATURE-----
