[Spambayes] : Stopping spam at SMTP Level
cej at intech.com
Mon Feb 9 03:05:52 EST 2004
I'm a bit of a pessimist, but that's because I'm getting things ready
for a class I'm teaching tomorrow, and it's 11:50 PM my time, and I'm
waiting for a Solaris install to finish. So, pardon the grimness. I
also just finished a marathon run with a failing mail server, but that's
dont bother wrote:
> Here is a couple of another questions. They may sound
> People have been implementing filters such as bayesian
> etc etc on the mailservers to stop spam which has come
> all the way and used up all the bandwidth.
> I am so surprised that no one has ever thought of
> finding out a solution that does not allow the f***ing
> spammers to send so many mass emails, porn etc. I
> have come across a few like some payment solutions but
> none of that has yet been implemented.
Well, I've seen one solution that I really really like. It works like
this: mail is handled by a third party. You sign up for an email
address from that party, and they give you one for $20/year or so.
Everyone who sends an email gets a bounce saying "Please follow this
link and answer the question to send mail to this person." At the link
you will find a simple question like: "Choose the red square" or "one
plus one equals ?". Answering the question adds the sender to the
database of "humans," and mail will be allowed from that address. Kinda
neat, and it will be what I set up eventually.
> Why not to modify the exisiting SMTP Applications
> which incorporate prevention of the abuse of email?
> Is int the http protocol has been modified to https
> where security is needed and SSL 1.0, SSL 2.0 has all
> been replaced by SSL 3.0 and TLS?
Mail doesn't really fit that model. With mail, you have a small packet
of information that gets moved across several computers (say, 15 to
20). HTTP is an immediate connection, whereas SMTP is not. HTTP can be
secured, but every mail server must be able to see the contents of every
mail message in order to forward it. Thus, SSL doesn't really work.
Although you could set up a filter that would only accept PGP or GPG
signed messages. Unfortunately, the number of people using email
encryption is appallingly small.
> Another vague question is that if you are implementing
> the Spam Filtering Business at the Mailserver of the
> Receiver why not to implement that at the Mailserver
> of the Sender? How about implemeting them at Routers?
> too expensive? Routers may be busy doing other than
> their usual business
Good idea. Excellent idea. Except that there are too many damnable
ISPs around the world with no interest in closing down open mail relays
on their networks. ISPs should adopt a zero-tolerance policy for open
mail relays. Unfortunately, that won't happen because their userbase
would evaporate overnight. Why? Because most ISPs have a clueless
userbase with no concept of IE and Outlook worms that set up mail
servers. If ISPs start terminating accounts based on spam sending,
they'd go out of business.
So, it sucks. Any other ideas I can shoot down? Maybe I should just
shoot myself and get it all over with...
Believe me, spending two solid days coaxing a mail server through
obscene spam-loading is a taxing experience, both mentally and
physically. Also hard on the people around me, since I tend to resort
to cursing, crying, pleading, and other melodramic displays of
overwrought emotional distress. (I tend to take these things a little
The best idea I've seen is RBL. (Realtime Blackhole List) An RBL is a
list of known spam-sending networks. Administrators subscribed to an
RBL agree to completely drop all traffic originating from or going to
said spam-sending networks. Nice system, and it works quite well
because ISPs realize that it hurts their business to allow spam on their
networks. Unfortunately, one must have a very flexible and
understanding boss to pull this one off, and not many IT administrators
have that luxury.
Hope this helps,
>> Yeah, basically, we're a bunch of neutered
>> impotents. The problem is not bandwidth so much as processing
>> time. Somebody has to take the mail apart, analyize it, and classify
>> it. The
>> further up the chain that processing is done, the more processing
>> must be
>> done, and the more expensive it is in terms of CPU time (and yes, CPU
>> time can still be expensive). Ideally, it should be done on the
>> spammer's ISP side, but that seems to be rare (judging by the amount of
>> email that comes into our network).
>> My solution works like this:
>> 1) Postfix accepts the mail, checks to see if it's
>> sent to a valid user
>> 2) If it is, run it through spambayes via
>> content_filter, which re-injects the mail into the system. That "run it
>> through spambayes" script looks at the "to: " mail header and uses the
>> appropriate user-specific database accordingly.
>> 3) Postfix hands it off to Cyrus, which delivers via
>> POP3 or IMAP.
>> Could it get any higher-level? I don't think so.
>> A lot of the spam we get is bounces from remote mail
>> servers. Spammers spoof our domain, and we get the "invalid-user"
>> bounces. Sick. I've been just discarding everything that's from
>> mailer-daemon and not to a valid local user.
>> Chris Jastram
>> Spambayes at python.org
>> Check the FAQ before asking:
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
More information about the Spambayes