Marvin RE: Best Way Blocking Spams
adamm at sihope.com
Tue Apr 29 07:14:18 PDT 2003
> 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
> 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.
More information about the freebsd-isp