rejecting spam at SMTP time (was Re: Postfix anti-antivirus (was Re: [linux-elitists] etc))
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
> 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. http://greylisting.org/
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