rejecting spam at SMTP time (was Re: Postfix anti-antivirus (was Re: [linux-elitists] etc))
Thu Sep 23 11:56:32 PDT 2004
On Thu, Sep 23, 2004 at 11:15:55AM -0700, Don Marti wrote:
>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.)
>Good things about SMTP-time rejection:
>1. It saves you bandwidth.
>2. It saves you disk space.
>Bad things about SMTP-time rejection:
>1. It gives spammers information about messages that
> definitely aren't making it through.
>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 message.
>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 addresses.
Apparently there is more than one way to do SMTP-time rejection because:
1 How can you save bandwidth on content/header SMTP-time spam checks?
2 Just because you SMTP-time reject spam who's to say you don't also
archive it on disk to report and/or verify no false positives (saves no
1 While spammers may get to know what gets rejected with SMTP-time
filters, so do legitimate senders, which I take as a big positive vs
legitimate mail being dropped (or returned, which is likely to also mean
forged address are getting reject messages).
1b If spammers are testing every which way my relay accepts mail, you
can bet I'm taking action with their ISP.
2 If rejected messages are also queued, users can certainly review rejected
messages with webmail, I've not bothered to sort them by SMTP RCPT but
that's certainly possible too.
3 SMTP-time rejection doesn't save any spammers bandwidth, unless
you are talking about IP based filtering vs content based. Which is
certainly doable along with the primitive virus filtering I do before
content/header based filtering; both of which save me a hell of a lot of
bandwidth and host resources.
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:firstname.lastname@example.org
More information about the linux-elitists