Filters That Fight Back

[Peter Bishop]

> However, unlike the spamvertized website spidering idea to which this
> was a response, sending bounces (even cautiously) would be both
> automated and instantaneous, representing a pretty decent advantage over
> the former method which would require manual editing of blacklists.  It
> would also be better targeted to the spammers rather than their payload.

The bouncing directly attacks the sender, which sounds a good idea if it 
can be done properly. Another idea in the same vein is Tarproxy, see:

http://www.martiansoftware.com/tarproxy/

In this case, a spammy sender is identified and the transmission of the 
email from that source is slowed  (by delaying protocol responses) - so the 
connection becomes a "tarpit" that slows the transmission rate based on 
message spamicity. This is guraranteed to hurt the actual sender but still 
lets all messages through (eventually).

But I am not too convinced of this really hurts the spammer as he could 
just open up more connections in parallel and get the same throughput. 
Bouncing has the advantage that a real extra load is placed on the sender. 

It would be important to get it right though. Would it be possible the 
identify the sender machine unambiguously at the IP level (i,e, the base IP 
address such as 158.166.12.345) and bounce to the postmaster? (e.g  bounce 
to postmaster at 158.166.12.345)
If the postmaster is the spammer then he suffers directly. If he is not, 
the postmaster can thow him off the system/ 

I think it would also be advisable to set a high spamicity trigger point 
for bouncing to postmaster to ensure that bounced spam really is spam.
-- 
Peter Bishop 
pgb at adelard.com
pgb at csr.city.ac.uk