Date: Tue, 29 Apr 2003 09:14:16 -0500 (CDT) From: Adam Maloney <adamm@sihope.com> To: Wolfpaw - Dale Corse <admin-lists@wolfpaw.net> Cc: freebsd-isp@freebsd.org Subject: RE: Marvin RE: Best Way Blocking Spams Message-ID: <Pine.BSI.4.05L.10304290810330.15037-100000@unix1.sihope.com> In-Reply-To: <AJENJFOLCLAHHIIGCCHNEEGFGEAA.admin-lists@wolfpaw.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> As far as the retrieval and all that is concerned, why is it > your problem? We block the mail before it gets to the destination server, or the customer's machine. ISP's like it because they no longer have to take the dictionary attacks head-on. Customer's like it because they don't have to download and process mail that they didn't want in the first place. I don't know about OE, but I've watched Eudora spend hours passing a few hundred messages through 30 filters. > What we do is this.. in the header of all mails is a > X-Spam-Status: > Let the user use their mail program to decide what happens to > spam with header filters (outlook does it very well), then you This approach certainly works, but again, SA is only 1 tool. We are already seeing spammers checking their messages with SA to try and get the score down. And everyone has seen the serialized subjects and bodies, to get around the checksum-based filters. Most of the current DNS-based blacklists are listing open relays, but the spammers have been moving away from using them, since direct-to-MX is much more efficient. More than anything Marvin is a framework, and an abstraction layer. The framework side allows me to plug in anti-spam modules (the SA module took only a couple of hours of compiling SA, coding and testing). The abstraction piece means that I only have to write the Marvin module, and let the framework handle the nitty-gritty of playing nice with the other tools, getting user configurations, etc. With our way, we only have to write code to wrap around the tool, and we can quickly add new modules, and provide users a consistent interface for working with them. Since most of the wrapper code is generic, it's very easy to implement a new program. And with the Marvin framework, I can put a new module in place and test it live without worrying about it destroying customer's mail accidentally. The design makes it safer and easier to implement a change that could be felt by thousands of customers. Also, we never modify the message contents. The original Sendmail queue files are preserved through the entire process, so the conversation with the customer that calls and says our program changed the From line, or our program added some header that broke Exchange, is a lot easier to deal with - the qf and df are never altered. (I hope this doesn't spawn the dreaded sendmail/qmail/postfix thread...) So like I said, SA is a great tool, and it's very effective - 46% in the last 10 minutes by my stats. But we wanted to give our customers more, and not have a fight to shoe-horn in "just one more spam tool" into the sendmail config every time the spammers defeated another system. Thanks to everyone for sharing their experiences - even though I didn't initiate the thread, I've gotten a lot out of it. Adam Maloney Systems Administrator Sihope Communications
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.4.05L.10304290810330.15037-100000>