[Spambayes] : Stopping spam at SMTP Level

[Christopher Jastram]

Yo,

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 
another story...

dont bother wrote:

> Hey,
>
> Here is a couple of another questions. They may sound
> vague.
>
> 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 
too seriously)

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,

Christopher Jastram

>
> Thanks,
> Dont
>
>
>  
>
>> 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
>> http://mail.python.org/mailman/listinfo/spambayes
>> Check the FAQ before asking:
>>   
>
> http://spambayes.sf.net/faq.html
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
> http://taxes.yahoo.com/filing.html
>
>  
>