One thing, though. It seems to me as a Java programmer that I could put together a mailet that contained much more sophisticated analysis than just a reverse-dns lookup. If I were to write a mailet that could reliably figure out spam based on more than just the sending host then it seems like there should be a way to allow replication of this knowledge to other instances of James as well.
keep in mind that dns is only used here to query sites that have *already* performed some level of analysis. that said, there are indeed many things that you can do that are more sophisticated than what can be practically managed by mailets (but if i told you what they are i would have to kill you :o) given the desire to make the contents of these lists accessible to as many people/platforms as possible, it is awfully hard to beat.
Not that I have time to develop this, but it seems like an opportunity to develop something more robust then rbl. If you can get the open source community to work on developing/improving the mailets that analyze incoming messages, then who knows where it may lead...
more robust in terms of analysis? yes. accessible as universally? i don't think so. the problem is that as you create more complex evaluation environments specificity of the rule sets (polices in my neck of the woods) increase dramatically. in other words passing around "answers" has its limits, what you want to pass around are the processes that allow you to derive answers that are pertinent to your environment (the 'beysian movement' is an excellent example of this).
I'm thinking in general here. If there were a Java interface that people could write to and a way to plug these things (maybe call them 'business rules' or 'spam rules') into James, I'd bet you'd find a lot of people sharing code and ideas. They could be called 'real-time blackout rules' (rbr) instead. Instead of pulling back lists of hosts you could pull back encoded business rules (or even just class files).
if there were a common *policy* language and an engine to consume them then you would have the opportunity to establish 'rule libraries' where users could shop around for predefined polices and use/modify them to suit their needs. XACML goes a long ways in creating the lingua franc, but you are going to have to do some heavy lifting to get a full blown policy engine in place to take advantage of it (trust me on that one :o). sun is taking steps in this direction, but i think that you will find that its work to date is slanted towards class/bean protection. still it may be worth a look if you are so inclined: http://sourceforge.net/projects/sunxacml/
however, i think that your best bet right now is to adopt one or more of the popular filtering methodologies (like beysian analysis, etc.) and try to swap filtering techniques/recipes (oops, a little procmail lingo slipped in there; which is a good example of a common toolset--albeit somewhat arcane--in the sendmail, et al. arenas) manually with other afficianados, such as those on this list.
that's my 2 cents anyway...
b
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
