rejecting spam at SMTP time (was Re: Postfix anti-antivirus (was Re: [linux-elitists] etc))

Rob McGee
Fri Sep 24 05:40:38 PDT 2004

> On Thu, Sep 23, 2004 at 11:15:55AM -0700, Don Marti wrote:
> >Sites that can afford the bandwidth and disk space
> >should avoid SMTP-time rejection, especially if it

I don't agree with this for reasons as detailed below.

On Thursday 23 September 2004 13:56, George Georgalis wrote:
> 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?

Received: (qmail 17434 invoked by uid 1010); 23 Sep 2004 18:56:32 -0000

You must be a qmail operator. Postfix rejects a great deal of spam
(RBL, HELO/EHLO and envelope checks) before the DATA is transferred.
The message itself is never received.

> 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

That which was not received cannot be saved on disk.

> 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).

Forged messages become the sending MTA's problem. This is the biggest 
problem I see in qmail: accepting all that mail and all those problems, 
which rightfully belong with the sending MTA.

> 1b If spammers are testing every which way my relay accepts mail, you
> can bet I'm taking action with their ISP.

Greylisting might be of interest to you.

It's a minor sin in that legitimate MTA's have to retry their 
transmissions, but if implemented correctly this only happens one time. 
Some people (there is a big debate on the postfix-users mailing list 
right now) say it's too much of a hassle because of some brain-dead, 
but legitimate, mailers out there, whilst others happily report 
dramatic reductions in spam for little administrative cost.

It likely will take out most of the Windows worms' spams, though: at 
least the few that made it through your RBL checks.

> 2 If rejected messages are also queued, users can certainly review
> rejected messages with webmail, I've not bothered to sort them by

I barely have time for real mail and lists as it is! IMO the best thing 
to do is to provide informative rejection messages and a Web contact 
form, so legitimate non-automated senders have a way of telling you 
they were rejected.

The one mildly persuasive argument I see is that acceptance of the DATA 
payload proportionally costs spammers more bandwidth than it costs you. 
Seeing as time is an inherent part of bandwidth, you can do just as 
well if not better by implementing delays in giving the spammer his 
55x. You still win and spammers still lose.
    Rob - /dev/rob0

More information about the linux-elitists mailing list