In response to Noel: Hi, I'm intrigued by the quick response. It appears you understand my intentions perfectly... to short circuit undesirable traffic ASAP.
I desire the ability to use any filter conceivable, programmable, and available to me in order to block unwanted traffic. In order to respond to various threats in a timely fashion, I also wish it to be dynamically configurable. I am not sure if there's a way or plan to have the james VM reread it's configuration or enable and configure filters on the fly, but I can always restart the process. Personally I wish Julian Haight at Spamcop.net would code up a nice mailet that sends incredibly nasty legal notices to the originator's ISP on spam detection. I might have to think about that one. Concerning the 'acceptOnlyLocal' option, this functionality exists in other mail services, and I hate leaving out options. It does sound as if you've got better mechanism for it planned. It sends the immediate message that non-local mail is not accepted. If disabled per default, the mail client program knows that the message did go into the system even if it doesn't get relayed. This will not send a brain-dead kiddie-script operator the message that he shouldn't bother thwacking that server with a further 50K messages. Sending back a 503 on RCPT will cause that error message, and he'll skip me for the next server on his hit list. The 'doReverseLookups' is just another tool, and you are quite correct, one of limited usefulness. Perhaps a much more verbose and explanatory text description of the option is in order, as it will indeed cause false positives and undetected negatives. For the undetected negatives, hopefully another filter or the 'acceptOnlyLocal' option will catch and kill them. As for false positives, clearly this option should not be used for larger or more public servers where this could occur. However, for a more private server or one with less traffic, or where the majority of the traffic comes from known locations, this can be useful. This still leaves open a source for public email input as opposed to a private AUTHed system. A matcher which would be interesting would be the reverse of the InSpammerBlacklist, accessing a whitelist DNS server which contains only those servers from which we will accept traffic. Does not require AUTH, but affords limited acceptibility. The Habeas Users List would also fit this category ( InSpammerBlacklist supports the Habeas Infringers List very well ). Rename InSpammerBlacklist and reverse the two return conditions. This also sounds like a candidate for the new filtering in v3. Chroot'ing a bind server and adding these whitelisted hosts is not difficult, but could be done within the code as well. On the Firewall block mailet: the mailet I have is getting older by the word as I realize more clearly what needs to be done... a configurable command line string with replaceable token parameters for the desired IP to block, timeout in seconds, and any other pertinent data. I'm using a small shell script to add iptables rules, and a daemonized perl script to time out the rules. I didn't think this mailet was particularly limited to use on Linux... although I don't know of other firewall mechanisms which permit rule addition/deletion via command line. I would only be able to provide the Linux iptables example, not sure why ipchains wouldn't be extremely similar. This is still limited to Linux, can someone suggest a Windows possibility? PATCH script in next email, but still available on http://www.mdve.net/jakarta- james/jakarta-james-cvsdiff.txt Thank you again for your response, it has helped me a great deal. Roger Venable [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
