On Wed, Nov 22, 2000 at 09:09:24PM -0800, Mary Smith wrote:
<<I only get uptight about the spams that get through my
defences - and those, it takes just a minute or two to pull
a mostly canned response from a template file in the return
email which is forwarded to each of the appropriate
addresses for the message (abuse@ and ARIN/RIPE/APNIC
contacts for IP blocks).>>
It takes a hell of a lot more time than a minute or two,
like an hour per spam.
Not if you know what you're doing. There are simple unix tools to find the
contacts (whois) for the IP block.
[andrew(_at_)redlance andrew]$ dig lists.RWTH-Aachen.DE any
<snipped>
nets5.rz.RWTH-Aachen.DE. 9m13s IN A 137.226.144.13
Urmel.Informatik.RWTH-Aachen.DE. 29m41s IN A 137.226.112.21
nets1.rz.RWTH-Aachen.DE. 29m41s IN A 137.226.144.3
deneb.dfn.DE. 9h34m13s IN A 192.76.176.9
ws-was.win-ip.dfn.DE. 8h50m7s IN A 193.174.75.110
[andrew(_at_)redlance andrew]$ whois
137(_dot_)226(_dot_)144(_dot_)13(_at_)whois(_dot_)arin(_dot_)net
<snipped>
Coordinator:
Schellbach-Mattay, Gert (GS199-ARIN)
ACNET%DACTH51(_dot_)BITNET(_at_)CUNYVM(_dot_)CUNY(_dot_)EDU
+49 241 80 4882
Took maybe 5 seconds. Of course, that's 5 seconds more than I'd spend, per
spam...
Although it's possible for some mailer to spoof the IP number within an
address block, listening on an ethernet for IP numbers that don't really
belong to it, it's not possible
You're trying to filter at the wrong network layer there. But that's beyond
the scope of this list...
11 sl-internap-47-0-0.sprintlink.net (160.81.36.26) 35.795 ms 23.042 ms
23.212 ms
12 border16s.ge2-0-bbnet1.sea.pnap.net (206.253.192.140) 23.930 ms 46.947
ms 36.128 ms
13 usei-2-gw.h2-0-0.border13s.pnap.net (206.191.144.166) 215.042 ms
186.570 ms 195.687 ms
14 206.191.144.154 (206.191.144.154) 739.883 ms 764.379 ms 770.690 ms
15 203.93.3.253 (203.93.3.253) 1149.664 ms 1116.608 ms 1079.595 ms
16 203.93.7.52 (203.93.7.52) 1110.708 ms 971.443 ms 892.602 ms
17 210.12.51.6 (210.12.51.6) 903.726 ms 906.680 ms 872.867 ms
18 210.14.227.5 (210.14.227.5) 889.887 ms 933.171 ms 933.477 ms
19 210.14.227.4 (210.14.227.4) 935.398 ms 934.330 ms 960.068 ms
20 192.168.1.10 (192.168.1.10) 967.852 ms 1161.408 ms 1203.296 ms
21 public.guangzhou.cngb.com (203.93.58.3) 1195.746 ms 1219.334 ms
1351.489 ms
so it looks like all those IP numbers that don't have any
reverse DNS lookup are deliberately making it hard to report
their spammers, so I'd like pnap.net to pull the plug on
206.191.144.154, so if I were to complain manually I'd do
Except that all those numbers that don't have host names are probably routers.
It's not uncommon for router IP addresses to not have PTR records. And in your
case, it looks like DNS was simply timing out on the reverse lookups on those
IP addresses as you did the trace. 210.14.227.4, for instance, is
sl-gw11-sea-8-0.sprintlink.net. The likelihood that pnap.net has any
association with the owners of 203.93.58.3, on the other side of Sprint, is
very, very small. I suppose you could ask sprint to dump 203.93.58.3. Good
luck. It belongs to China.
Basically it boils down to you're wasting your time complaining to the owner
of the next nearer IP address of the machine that originated the spam.
1> They probably have no affiliation with the entity that owns the spamming
host beyond a network connection.
2> The host that originated the spam to you is probably not the spammer.
They're just an open relay the spammer tracked down.
3> Spammers don't even need to waste the time to create bogus PTR records for
their IP addresses. There's just too many open relays for them to use instead.
Open relays are easier to use, and far better at hiding your origin.
whois on pnap.net and complain to their admin contact and
let them figure out why all those IP numbers don't have
reverse DNS and who is responsible for them. But the point
is that while cngb.com is probably either forged or owned by
the spammer, pnap.net is probably non-forged and not owned
by spammer, right? By the way, can you guess why I hate Sprint?
Pnap.net doesn't care why routers that don't belong to them don't appear to
have PTR records in your traceroute. postmaster(_at_)pnap(_dot_)net is going to
bit-bucket your complaint about spam coming out of china. Complaining to
pnap.net about spam from China will get you about as far as complaining to
your local Baby Bell about telemarketers calling from Brazil.
That's why having their disk fill up with spam that hasn't
yet been delivered is the best thing to do to them, and I
wish it were possible. Presumably whoever sold them their
Except the only disk that will fill up is the open relay. And contrary to what
you appear to be thinking, the amount of disk space a message consumes in a
mail queue does not grow exponentially with each failed delivery attempt. It
doesn't grow at all.
It takes five minutes to do that and collect the relevant IP
numbers,
If it really takes you five minutes at each step, I suggest that maybe you
need to work on your typing skills. All of the steps you mentioned should take
no more than 2 minutes. And even at that you're wasting your time.
Yes, and procmail seems to be totally useless to fight
against it, despite people leading me down the garden path
to believe it might help.
Procmail is about the only method of fighting it, and it's quite effective. It
just isn't going to do what you want to do: kill the spammers
machines/accounts. You can give up on that, because at a user level there's
just no way to do that. The only way to do that is through community activism
to lobby against the most blatant spam-friendly sites. There is no software
that can do that for you.
Fuck you! I already spent many many hours doing that and all
I can find out now is that my time was wasted because
procmail can't help me.
Calm down. Procmail probably won't do what you want to do, for the above
mentioned reasons. However it is VERY effective at causing spam to go into the
bit-bucket. If you never see the spam, and it doesn't cost you money[1], why
do you care? Sure, in principal I'd like to see all spammers burn in hell too.
But at the user level, the only thing you can do is set things up so the spam
just goes away. Let the spammers waste time sending you mail you'll never see.
If you don't see it, don't worry about it.
Damn, that made me miss the first minute of StarTrek Voyager,
so I don't know the plot.
Damn, if procmail sent that spam to /dev/null instead of your screen, you
could be warming the couch right now, instead of complaing that procmail can't
help you...
--
Andrew Edelstein http://andrew.pure-chaos.com
"A third factor is the not uncommon attitude on the part of upper management
that because a project must be completed by a certain date, therefore it can
and will be completed by that date, and information to the contrary is not
welcome."
Pitfalls of Object-Oriented Development
Chapter 3
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail