rejecting spam at SMTP time [linux-elitists]
Thu Sep 23 12:14:03 PDT 2004
* Don Marti <firstname.lastname@example.org> [2004-09-23 11:15-0700]
> begin Gerald Oskoboiny quotation of Tue, Feb 03, 2004 at 02:08:50AM -0500:
> > I recently started rejecting most incoming mail to my site, and
> > it feels great! (anything with SA score > 10 is rejected.)
I have since made a few changes: lowered the threshold to 6,
added some honeypots that feed SA's bayes db, started rejecting
> Good things about SMTP-time rejection:
> 1. It saves you bandwidth.
> 2. It saves you disk space.
3. senders of false positives know I didn't receive their message
(and won't be wondering why I didn't reply)
> Bad things about SMTP-time rejection:
> 1. It gives spammers information about messages that
> definitely aren't making it through.
yeah. At the MIT spam conference in Jan 2004, John Graham-Cummings'
presentation showed how he was able to figure out words that always
allow spam through to his mailbox, by sending himself thousands
of messages with random words and analyzing the results.
(ugh; powerpoint); from google's HTML conversion:
| How to get feedback
| When sending each message include a unique web bug
| Creates an effective feedback loop
| Spammer can use web bug to train their POPFile installation
| Bad news... this works:
| Tested against my POPFile installation
| Sent 10,000 emails containing 5 random
| words from /usr/share/dict/words
| Found my kryptonite
| Kryptonite Words
| accommodations, arrangements, berkshire, category, channel,
| checking, comment, currency, endless, entitled, flying, hills,
| independent, invoice, logging, marriott, occupancy, officer,
| operated, quantity, redeeming, rent, shared, silicon, touch,
| Adding just one of these words turns the spam into a ham!
I haven't found this to be a problem with rejecting spam at SMTP
time yet; I don't think most spammers go to this much trouble.
(I'm still delighted with my spam rejection setup.)
> 2. It makes it harder for users to deal with false positives.
> The user can't just point a browser at the webmail interface to
> the spam bucket when the SMTP server never accepted the
yup. But I was ignoring my thousands of filtered spams anyway.
I guess if you discover a false positive it might be nice to be
able to dig it up instead of asking the sender to resend; exim
has a "fakereject" that bounces the mail but also delivers it
(or does whatever you want done with it.)
> 3. (and this is the big one) It saves spammers bandwidth. Yes,
> some spammers get bandwidth at no charge, but only by criminal
> means, so its cost is in risk, not money.
> Sites that can afford the bandwidth and disk space should avoid
> SMTP-time rejection, especially if it would reveal
> site-specific spam-filtering information such as spamtrap
Gerald Oskoboiny <email@example.com>
More information about the linux-elitists