[Spambayes] : Stopping spam at SMTP Level
Terrel Shumway
tshumway at jdiworks.net
Mon Feb 9 14:13:44 EST 2004
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 so.
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-)
> 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.
> 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 it.
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.
>>> 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.
More information about the Spambayes
mailing list