Re: SPAM: dealing with it

From: Christian Weisgerber (naddy@mips.inka.de)
Date: Mon May 20 2002 - 13:52:13 MDT


Robert J. Bradbury <bradbury@aeiveos.com> wrote:

> As I understand it -- if sendmail is sending to procmail and
> the procmail fails (due to the SpamBouncer restrictions) it notifies
> the sender immediately (during the send process) and they receive
> a transmission failure notice in the error 500/501 class.

This assumes
* a flat topology, i.e. the spammer directly talks to the MTA which also
  does the final delivery,
* synchronous delivery, i.e. the MTA attempts final delivery as soon
  as it picks the message off the wire.

Given these assumptions, your model works. However, many setups
don't follow this scheme. For example, a hierarchical store-and-forward
model isn't uncommon: all mail external mail is delivered to a
central company/university/etc server, which forwards it to department
servers, which forward it to workgroup servers, where final delivery
takes place. I've seen people pride themselves with using procmail
to bounce spam mail in such environments. A bounce message will
be generated and travel back up the tree like a ricochet. Chances
are it will just end up undeliverable, but there are more sinister
possibilities.

> So a "bounce" is different from a "return" to the return
> address (which they ignore).

Don't say "bounce" when you mean that your MTA refused to accept a
message.

Note that the envelope sender address ("return address") is entirely
under the control of the sender. A spammer can put anything
whatsoever in there. A spammer can send out a million messages
with MAIL FROM:<bradbury@aeiveos.com>. If a few percent are bounced
back to you, you'll likely appreciate the problem.

> If spamers are "intelligent" (no assertions that that is the case)
> then they should cease sending to systems that bounce at this level
> because it is a waste of their resources.

Alas, a good many don't seem to realize this.

The Story of "Nadine"
http://www.spamresource.com/nadine/

Also, that's another reason spammers are so fond of abusing open
relay servers rather than spamming from their own machines. Apart
from making them somewhat more difficult to track down, it is more
convenient to just dump _one_ message at the relay with a hundred
RCPT TO addresses. Let the relay do the work of actually attempting
delivery. The spammer will never even see your MTA refusing the
message.

> > Similar caution needs to be exercised when identifying the point
> > of origin for further action. [...]
>
> I understand this. I can only presume that SpamBouncer has
> got this right. I haven't gone through the code in detail.

Then I suggest you FUCKING GO AND LOOK. Everything else is plain
irresponsible. Sheesh.

There is probably more damage done by ill-conceived anti-spam
measures than by spam itself. Somebody picked your pocket? Just
whip out a submachine gun and blast away at the nearest bystanders.
Might get the pickpocket, and anyway it makes you feel good.

> Yes, I noticed that your reply showed up as being from a news list
> that doesn't exist on my machine. As a result figuring out how to
> answer the Pine questions regarding how to respond took at least
> 3 trys on my part. :-(

Hmm? A message such as this one goes to the submission address of
the extropians list and is sent out again from there. It bears all
the markings of a list message. Feel free to point me to any headers
you consider problematical...

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de


This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 09:14:14 MST