From: Robert J. Bradbury (bradbury@aeiveos.com)
Date: Wed Apr 10 2002 - 17:01:51 MDT
On Wed, 10 Apr 2002, Amara Graps wrote:
> Please take a closer look at the docs at www.spambouncer.org
> They are responding to your wishes.
Only to some extent (I believe).
The normal configuration on my Linux box is:
sendmail --> procmail --> user mailbox
I'm under the impression that what Amara is suggesting is:
sendmail --> procmail --> spambouncer --> user mailbox
My point was that after the sendmail step, you have "received"
the SPAM, and are simply determining how to dispose of it.
In contrast, the support for the MAPS Realtime Black Hole List
and Relay Spam Stopper (which were free before Aug. 1, 2001)
could be "built into" the "sendmail" step which would allow
it to reject the messages as they were received.
I'd have to go through the sendmail configs in a little more
detail to be sure. It may be true that the sendmail filtering
may not have been much better than the spambouncer filtering
(in that it still may have "accepted" the message). What one
really wants is a real-time filter that recognizes spam on
packet-by-packet basis as it is received from the sender (as
well as recognizes known SPAM senders up-front and rejects
them before they can even send packets).
The filtering mechanism needs to be pushed as far
upstream as possible (ultimately one wants to push
it back to "responsible" backbones providers).
The spam messages should be recognized on a source
basis or a content basis and rejected with a harsh
message (indicating that spam filters are in place
and further attempts will be rejected) or presented
with DoS attacks to reduce the amount of spam such
systems can contribute to the net.
> SPAMREPLY=BOTH #SILENT tells the Spam Bouncer to filter spam,
> #but not attempt to autocomplain about it.
> #BOUNCE tells the Spam Bouncer to send a
> #"MAILER-DAEMON" bounce message to the spammer.
The problem is that the local post office has already "accepted"
the message at this point. It is likely that the reply-to: or
From: address have been "forged" or are dummy accounts on free
systems (yahoo, excite, etc.). So the bounce message is ignored.
(The bounce message actually contributes to useless network
overhead in this situation.)
> #COMPLAIN tells the Spam Bouncer to send an
> #autocomplaint to the spammer's postmaster and
> #upstream sites. BOTH tells the Spam Bouncer to
> #send both a bounce to the sender and complain
> #to the spammer's postmaster.
Again, if the originating system is an intentional spammer then
complaints to that system's postmaster will be ignored. I'd have
to look in detail at whether the "upstream" sites complaint
process is useful. If they use the transmission path contained
in the headers of the email message it is probably of less use
than if they do an actual traceroute back to the originating
system (some providers now block these) so they can complain
to everyone along the chain of transmission.
Robert
This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 09:13:23 MST