[Spambayes] : Stopping spam at SMTP Level
cej at intech.com
Mon Feb 9 23:02:02 EST 2004
Terrel Shumway wrote:
> Christopher Jastram wrote:
>> 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
> Why is this necessary? 5000 users*$20/year = $100,000/year. Nice
> pocket change. Would you like to make a donation to my favorite
> charity? 8-)
Nah... I've just seen the commercial offerings, and they range from
$5/year to $20/year. I've considered signing up for my own use, but
then I say -- "why not start my own??" As if I didn't have enough to do
>> 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.
> This addresses a very small part of the problem with a very expensive
> (usability-wise) solution.
True. It's also easy to foil. The only reason it works is because the
mail-proxy sites remain fairly small.
>> 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.
> RBL, of course, also has its drawbacks, which have been thoroughly
> discussed elsewhere. The two-camp approach is a good evolution of
> RBLs, but won't help us today.
>>>> 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.
> Using spambayes (step 2) on the wire (i.e. instead of step 1) may not
> save bandwidth, but can save disk space and give priority to non-spam.
> 1) a message looks like spam: 553 it and you're done. Include a URL
> in the response text so a human can get whitelisted and resend a false
> positive. 2) If a message is "unsure", 553 it but store it for 7
> days so the human user can redeem it from quarantine without resending
> 3) tar-pit the spam-sending IP/network so it will take them three
> hours to send a single message.
> Now you have a good 80% solution that will save your CPU and push ham
> to the front of the queue.
Good ideas. Thank you very much -- I've been racking my brain for
ideas, and input is much appreciated.
>>>> 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.
> not a bad idea.
Thanks! It works quite well. Delivery works out to about 400 messages
/ day with this system, and I'm dropping 30,000-35,000 messages without
processing. Nobody has complained, and everybody gets their daily quota
of spam. I'm thinking of re-integrating the spambayes filtering, but
that will have to wait (busy teaching Intro to VBA this week).
Is there some web site that has tips for battling spam? Tried-and-true
practices gleaned from bitter mouths of hard-pressed sysadmins?
More information about the Spambayes