RE: [IMail Forum] Spam

[Marc A. Funaro]

After it's a stable, stand-alone application (with a local backend database as it has now, for application functionality/extensibility and reporting... planning on supporting both Access and MSSQL on initial release), and only after I hear more ideas (primarily from this list!) on whether it's overall a "Pretty Good Idea", I would probably release it for a Very Low Price (say $50 or less).   It's a pretty specialized solution -- not sure if it would even be necessary if someone had iMail 8 or higher (I need to become familiar with the features of that version), and I know that the IPSec filter addition wouldn't work on anything less than Windows 2003 server (because of IPSec scripting limitations on older versions of windows, which is why I want to be able to provide multiple output formats for other scriptable firewalls... perhaps ones that are not even on the iMail machine itself... envision an iMail machine telling it's upstream firewall what to do).   If I can use it, probably someone else could too, but the cost has to remain low because above a certain price point, it would be better to use Declude or some other technology.  It would be a small app for small servers, to help abate the spam problem for them.   This has been a way to get around the limitations of our version of iMail, where we cannot script the entries in the CONTROL ACCESS button of the SMTP security tab.  Had that been scriptable, I probably would have built this app to do that... but again, there may actually be a benefit of rejecting the packets at the IPSec level, with regards to actually taking a jab back at the spamming server.  (Again, I don't know if this is a real or perceived benefit, to keep the spamming server queuing spam it can't deliver to us because it just thinks we're temporarily "offline".)   I don't think mxGuard is looking to implement actual IPSec filter scripting... that's just not an intended use of the product. However, I have requested an mxGuard feature that will create a log file containing the IP Address, contents of the FROM field, and a couple other fields for all messages that have over x number of blacklist hits (configurable), so that I can just parse the log file instead of picking up and parsing spam headers themselves... and I think that might be in a near-future mxGuard release.   It is my hope that if this idea grows, it could actually accept input from any source, and auto-script or auto-update blocking filters for IPSec and other packet filters/firewalls.  When ported to java, it could run on any machine, accept headers OR log/csv files containing spam IPs, and output in several formats to create an "auto-learning" packet filtering system.  Who knows...!   The short answer is "yes", I do have "plans" for it.  If they don't pan out, I'll certainly announce why.  If they do pan out, I'll make sure it's a low-cost, properly positioned application!   Again, apologies for the rambling.  This probably barely belongs on this list now :) -----Original Message----- From: isp-lists [at] beachcomp.com [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 10:12 AM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Spam Marc   Sounds like a very clever idea! Do you know if David has any plans on implementing it into MX? Do you have plans for mxblock, or do you think you'll be able to share it? I'd be very interested.   Thanks! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc A. Funaro Sent: Friday, March 19, 2004 10:02 AM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Spam We're using mxGuard with some aggressive settings, and I've written a custom application ( "mxBlock?" :) that takes the most hardcore spam (those on two or more blacklists, as determined by mxGuard), parses the mxGuard headers, and creates a 15-day IPSec filter to block the IP address of a delivering mail server that has sent three or more, 2+ blacklisted, messages to our box.  The IPSec filters are recreated every two hours, to contain all the most recent IPs that we've received.   The IPSec filter seems to be working great, and unless I've got this wrong, actually has the net effect of bogging down the spamming server somewhat... because instead of being outright rejected, the sending server simply believes that our machine is unreachable, and keeps the spam in its smtp queue for up to three days (someone correct me if I'm wrong here!).  I wonder, if everyone dropped packets from the really offensive sending servers, if those servers would end up queuing lots of undeliverable spam (?).    We're working on whitelisting at the filter level now, as are the mxGuard folks for the processing level. Regardless of the effect on the sending server of our dropping their packets without response, we've seen a reduction in delivery from the greatly-blacklisted spam servers overall, and mxGuard has been very accurate with regards to the rest that we do have to process.  There's still a pretty even ratio of spam to legit messages being PROCESSED, but when a message is on two or more blacklists, the subject modifier becomes [block] and goes into our IPSec filters.  All others have a subject modifier of [spam!] or [spam?], and our users set up iMail rules to block/move those messages.   As the list of IPSec-blocked IPs grows, we will see less spam overall, so it's a cumulative thing.  After 15 days, if we receive even ONE two-or-more-blacklisted messages from an IP address we had blocked, it is automatically reblocked.  Our IPSec blocked IP filter list is now over 1000 IPs and growing, and there's been no performance hit on the machine at all.  (My only concern is whether there is a programmatic limit on how many filters a windows 2003 server IPSec filter list can have!!)   It's been an interesting system to design, overall, and we couldn't have done it without mxGuard... but i've enjoyed building it and I'm hoping to port it from the current solution to a fully java-based add-on, right on the mxGuard-enabled mail server... and add filter output for other types of filters like pktFilter and perhaps other scriptable firewalls, AND take direct-log input instead of/in addition to the slower parsing-of-spam-headers routine already in place.   Our above solution came out of the shortcomings of iMail 7.1x, which we are still using because of budgetary constraints.  And mxGuard has been an excellent low-cost solution for handling spam AND viruses.   I just realized how long and rambling this is... sorry!   Marc       -----Original Message----- From: KathyJ [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:22 AM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Spam  I too am losing the spam war, although my troops have been pushing forward while I try to configure declude on a 30 trial basis.  If I can make it work well, my boss will buy it.   I have basically been told my job rides on this L  I think I will go back to fixing PC’s for a living.. or maybe waitressing.       -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Bullion Sent: Friday, March 19, 2004 9:06 AM To: IMail_Forum (E-mail) Subject: [IMail Forum] Spam   Just wanted to bring up a topic we've all talked about endlessly.  I wanted to see how you guys handled spam on your Imail server.  I'm using a small set of DNS blacklists, content filtering, and a semi large kill.lst file.  How about you guys?  It seems like I'm losing the war badly though.