big-nothing-to-do-with-procmail response follows.
To filter, I'd examine the other messages and look for a common pattern -
perhaps the "for" addresses claimed in one of the headers?
At 23:31 2002-10-05 -0400, Matthew G. Saroff wrote:
I've been getting a lot of stuff from someone who has a bone to
pick about the situation in the middle east. The individual appears to be
hijacking open relays
If they're actually doing this with DIFFERENT open relays, and it's the
same person, you should be able to pick out a pattern from there.
Received: from terrin.com (mail.terrin.com [63.193.139.180])
by fellspt.charm.net (8.12.2/8.12.2/LNSG+ORDB+OSS+SCOP) with ESMTP
id g95N8hvg018637
for <msaroff(_at_)fellspt(_dot_)charm(_dot_)net>; Sat, 5 Oct 2002
19:08:47 -0400 (EDT)
Received: from 63.193.139.180 [4.46.79.27] by terrin.com
(SMTPD32-5.05) id A0C720000B6; Fri, 04 Oct 2002 08:16:23 -0700
Received: from 209.10.150.70 by 4.46.79.27 (8.8.5/8.6.5) with SMTP id
GAA02001 for <"Vectress" <tw5u-7y60(_at_)xemaps(_dot_)com>,
freepalestine(_at_)yahoogroups(_dot_)com>; Fri, 04 Oct 2002 07:07:26 -0600
(EST)
mail.terrin.com is the most likely open relay here. The bottommost
received header violates the standard structure of a valid sendmail config
(and yea, if it WAS that old of a version, it probably would be an open relay).
A valid mail server would rather unlikely be claiming one (invalid) IP for
itself in one header when relaying mail outwards using a different header,
and the middle received header provides a clue here: *WHY* would a
legitimate email server connect to a remote machine and identify ITSELF
with the IP of the machine it was connecting to???
Further, even an open host would relay the message outward to the
appropriate mail host(s) for the message - so WTF with the two addresses in
the "for" bit on the bottommost ("first") header? In fact, have you EVER
seen MULTIPLE addresses conveyed in this fashion, INCLUDING name
tokens? That makes the bottommost received header rather suspect as a forgery.
FTR, 'host -t MX xemaps.com' (from that bottommost header) returns
smtp.spamex.com. I hit <http://www.spamex.com/>. I've never used them,
but they're listed as a disposable forwarding email service in the NANAE FAQ.
spamex.com is registered to "clickvu.com", which is the hostname of the
presumed originating host (see below), which appears to be some banner ad
services company. I've got some issues with the basic premise of what they
claim to do (and how they do it), but at a glance, it sure doesn't look
like they'd be sending spam (certainly not if they're the registrants of
spamex.com). Chances are good the spammer is trying to direct grief to
these guys through a forgery of that bottommost received line.
One thought was that 4.46.79.27 host could be a mailserver on a dialup (or
at least dynamic IP, seeing as it is a DSL line) - but then it would be
VERY unlikely that a spammer just "happened" across it.
If it's a valid mailserver (and esp. one which is an open relay), you
should be able to telnet to port 25 at that address and expect to be
greeted with an SMTP greeting corresponding to the sendmail version in that
received header.
4.46.79.27 is part of a class-B network belonging to GTE (Verizon). If you
look up the IP addr using 'host 4.46.79.27', you'll find the hostname
incorporates a DSL name reference. Some (but not all) of the IP addresses
in the address vicinity of it do respond, and at least from where I'm
sitting, they appear to have low latency.
SMTP response: (dead air, doesn't ping or traceroute either)
From the "for" header (revealing TWO addresses!?), this host had no
business passing it along to terrin.com, and in fact, if the mail really
came FROM the host that the bottommost header claims it did, then the first
of those two addresses shouldn't have been listed because the host that
SENT the message should have been
209.10.150.70 belongs to globix. The host identifies as ns1.clicvu.com via
DNS.
SMTP response: 220 admin01-nyc.clicvu.com ESMTP server (Post.Office v3.5.3
release 223 ID# 0-64039U1000L100S0V35) ready Sun, 6 Oct 2002 03:21:04 -0400
This clearly doesn't appear to have been involved in the transport, unless
the server host itself was use to relay the message, and that doesn't
explain why the verizon host would have relayed the message to the next hop
claiming its own hostname to be the receipient computer IP.
63.193.139.180 belongs to pacbell internet, part of a /12 CIDR. It's the
one host that actually _does_ identify as the domain associated with it in
the two received headers associated with it. DNS identifies as
'mail.terrin.com' (which correlates to the DNS resolution shown in the
final (topmost) received header), but the primary local host obviously
doesn't include the 'mail' hostname portion, as confirmed by the SMTP
response (not uncommon):
220 X1 NT-ESMTP Server terrin.com (IMail 5.05 2190-1)
(note the 5.05 version in the SMTP response appears in the SMTPD blurb in
the second header as well).
Hitting the webserver for this host <http://www.terrin.com> reveals some
"practice pages" for a CS course. Oh, gawd, I hope this guy flunks - his
JS code is sheer crap.
Given that it's a windows box, and obviously run by someone "new" to this
whole picture, it's clear that the terrin.com host is the open relay, if
not the actual ORIGIN of the spam:
Terrincom (TERRIN-DOM)
819 S. Curson
Los Angeles, CA 90036
US
Domain Name: TERRIN.COM
Administrative Contact:
Dooley Joe (DJ580-ORG) terrincom(_at_)HOTMAIL(_dot_)COM
Terrincom
819 S. Curson
Los Angeles , CA 90036
UNITED STATES
323-936-1651
Fax- 323-938-0398
I want to complain to the appropriate sysop.
Chances are, it's the terrin.com outfit, and the spammer has a verizon DSL
account.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail