ietf
[Top] [All Lists]

Re: "Principles" of "Spam-abatement"

2004-03-17 16:46:14
From: "Robert G. Brown" <rgb(_at_)phy(_dot_)duke(_dot_)edu>

From diamond(_at_)juno(_dot_)com  Sun Mar 14 15:28:51 2004
Return-Path: <diamond(_at_)juno(_dot_)com>
Delivered-To: rgb(_at_)phy(_dot_)duke(_dot_)edu
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(_at_)phy(_dot_)duke(_dot_)edu>; 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(_at_)NIC(_dot_)BR,
      abuse(_at_)NIC(_dot_)BR, and/or postmaster(_at_)NIC(_dot_)BR(_dot_)  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(_at_)rhyolite(_dot_)com