> From: "Robert G. Brown" <rgb@xxxxxxxxxxxx>
> >From diamond@xxxxxxxx Sun Mar 14 15:28:51 2004
> Return-Path: <diamond@xxxxxxxx>
> Delivered-To: rgb@xxxxxxxxxxxx
> Received: from pohl.acpub.duke.edu (pohl.acpub.duke.edu [152.3.233.64])
> by mail.phy.duke.edu (Postfix) with ESMTP id B5A33A77F7
> for <rgb@xxxxxxxxxxxx>; Sun, 14 Mar 2004 15:28:51 -0500 (EST)
> Received: from 152.3.233.64 ([200.215.92.74])
> by pohl.acpub.duke.edu (8.12.10/8.12.10/Duke-5.0.0) with SMTP id
> i2EK4b0
> 3030509;
> Sun, 14 Mar 2004 15:04:57 -0500
> Received: from [7.197.76.17] by 152.3.233.64; Mon, 15 Mar 2004 02:01:00
> +0600
>
> Here I'm pretty sure that pohl.acpub.duke.edu (also 152.3.233.64) is
> telling the truth about where it received the message from and isn't
> forging the previous hop because its administrator(s) are local and
> accountable and their address resolves. This particular example is
> interesting in that as far as I can tell from registry information,
> 7.197.76.17 doesn't exist and there is no route to it. The
> 200.215.92.74 address is a relay in brazil. Neither of them seems
> promising in terms of being able to report the spam.
I disagree:
1. pohl.acpub.duke.edu is not an external relay for you. It is your
system, even if you don't have a root password or any account on it.
2. 200.215.92.74 is not just a misconfigured relay, because it used the
spam trick of using the IP address of its target for its HELO value.
It might be an "owned" box with a trojan or it might be worse.
3. the Received line pointing to 7.197.76.17 is obviously silly
nosnense for more than one reason. Let's not educate the
listening spammers on the details.
4. you don't need to know why I claim #2 or #3 to properly report
that spam. All you need is a tool that will pick out the only
IP address that matters from the only Received header you can
trust, the top one, and send a report. There are several common
tools that do exactly that. Some involve commands lines, but
most are point-and-click. Their defects are mostly that they try
to do more, such as detecting hosts of spamvertised URLs.
5. #2-#4 are irrelevant. Whether Comite Gestor da Internet no Brasil
hears about the spam fountain at 200.215.92.74 is none of your
concern unless you have an unhealthy obsession with spam. All
you should care is that by hosting that spam fountain, all hosts
in 200.128/9 are less likely to be able to send mail to
pohl.acpub.duke.edu and mailqueue1.duke.edu
6. Yes, I am a certifiable expert on at least some unhealthy obsessions
with spam.
> To even START to "fix" this problem, postmaster has to work on the relay
> and be responsive. The relay host manager has to know that their access
> to the entire Internet will be effectively terminated if they don't have
> a working postmaster address and are not responsive to spam. The
> communication mechanism that reports spam has to both include the key
> information about times, addresses, and so forth AND has to function
> independent of knowledge and degree of expertise of the user. I know
> what I'm doing (at least, to a point:-) and I'm daunted by the prospect.
> Most users wouldn't even know what all those words I just used mean...
NO! Nothing significant has changed since Steve Wolfe stopped being
the bogyman we used to frighten lusers into not being naughty.
- all that is needed to fix this problem is for the operators of
mailqueue1.duke.edu and pohl.acpub.duke.edu to have reasonable
counts of the spam from 200.128/9 and take action, or to delegate
those actions to the SMTP trust vendor of their choice (currently
DNS blacklists).
- If Comite Gestor da Internet no Brasil is a reputable outfit,
then it will do as bazillions of other repubutable outfits,
including Duke University, have long done, and detect and deal
with its spam problem, without your let, leave, hindrance,
assistence, notice, help, or nagging.
- Purely for extra credit, someone might try to forward an unmodifed
copy of that spam with complete headers to blkadm@xxxxxx,
abuse@xxxxxx, and/or postmaster@xxxxxxx If the recipient can't
figure out purely from the copy of spam what to do, then that's
not our problem. At most 200.128/9 we should disconnnected from
the Internet that we use by adding to our blacklists. If someone
at Duke finds a need to receive mail from 200.128/9, you might
review that blacklist entry or punch a hole in the blacklist.
Apologists for spam friendly ISPs including those who claim to believe
that $360/year is a fair price for a fundamental human right will say
that ISPs can't stop spam unless everyone reports it. That claim is
nonsense. When it comes from ISPs, it is a bald faced lie; it is
possible even for a raw IP bandwidth ISP to detect spam.
> So I have to say again -- there may be IETF work that could be done
> here. It shouldn't be this difficult, and there needs to be a whole
> structure erected to make mail administrators accountable at some level.
> And ultimately, we may all have to be willing to pull the plug on
No, simply forwarding completely and faithful copies is more than sufficient.
> 17.76.215.200.in-addr.arpa domain name pointer BrT-S4-1-2-22-bnuce300.brasiltelecom.net.br.
I can't get a PTR RR for 17.76.215.200.in-addr.arpa. Whether you use
reverse-DNS and whois or whois on the IP address is a minor, irrelevant
technical detail. (Yes, I know Ralsky and others play games with PTR RRs.)
> and effectively cut them off from the Internet if they don't police
> their relays and e.g. refuse to accept mail from unregistered hosts.
> Only thus can we forge a chain of responsibility back to the SPs that
> they cannot easily evade.
We don't need any "chains of responsibility." EIther Brasiltelecom
deals with its spam or it doesn't, just like the zillions of other
outfits that do not have the reputation of a Brasiltelecom, Comcast,
or UUnet. How Brasiltelecom manages that trick is none of our business,
unless we are customers or employees.
> I just don't think that the idea has been fully tested yet. To properly
> test it, a certain amount of infrastructure would have to be built --
> not a horrible lot, actually, but some. And the process of complaining
> in a standardized way would need to be made "one click easy". ...
NO! If Duke or AOL want to do that for its users, then fine. If not,
that's also fine. All that matters is that you accept responsibility
for your own incoming spam and deal with it by cutting off the sources.
You don't need any "infrastructure" to add to a sendmail access_db
or a router firewall. (I've heard that AOL has a "this-is-spam" button.)
> > The first part is nonsense spread by spammers and dishonest, spam-friendly
> > ISP spokeslime. ISPs have no problems terminating customers with less
> > than minimal evidence.
> Yes, I don't quite understand why people keep talking about suits and
> such.
We all know why people go on about suits and such. It is because they
have something personal to lose if spammers are routinely terminated.
That is variously cheap services subsidized by the lack of an abuse
desk at their ISP, services subsidized by revenue from spammers, a
desire to get rich or at least famous by flogging a Final Ultimate
Solution to the Spam Problem (FUSSP), a job at a spam haus of an ISP,
or a job at a spammer.
I realize this observation is impolitic, but it's past time to be
honest about the motives for the persistent nosense about spam.
Vernon Schryver vjs@xxxxxxxxxxxx