Re: email and spam (was: Re: namedroppers, continued)

jfcm <info@utel.net> Mon, 13 January 2003 16:33 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15980; Mon, 13 Jan 2003 11:33:23 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Y7TP-0002JJ-00 for ietf-list@ran.ietf.org; Mon, 13 Jan 2003 11:30:03 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18Y7LJ-00029z-00 for ietf@ran.ietf.org; Mon, 13 Jan 2003 11:21:41 -0500
Received: from hosting.altserver.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15550 for <ietf@ietf.org>; Mon, 13 Jan 2003 11:17:36 -0500 (EST)
Received: from lns18m-11-202.w.club-internet.fr ([212.195.146.202] helo=mine.utel.net) by hosting.altserver.com with esmtp (Exim 3.36 #1) id 18Y7KS-0007S5-00 for ietf@ietf.org; Mon, 13 Jan 2003 08:20:48 -0800
Message-Id: <5.1.0.14.0.20030113171348.02c3f8c0@mail.utel.net>
X-Sender: info+utel.net@mail.utel.net
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 Jan 2003 17:23:44 +0100
To: ietf@ietf.org
From: jfcm <info@utel.net>
Subject: Re: email and spam (was: Re: namedroppers, continued)
In-Reply-To: <33549559.1041963726@P2>
References: <009e01c2b67b$45926590$0701a8c0@nailed.org> <009e01c2b67b$45926590$0701a8c0@nailed.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; x-avg-checked="avg-ok-3175290A"; boundary="=======13C61120======="
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - hosting.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - utel.net
Sender: owner-ietf@ietf.org
Precedence: bulk

Dear John,
I am afraid that at this stage (e-mail + 40 or so years) telling someone to 
read the archives has no meaning. And telling him to post if he has a 
_new_idea either.

Could we not think of an FPS (frequently proposed solutions) where each 
defeated "solutions" would be listed and quickly discussed. There would be 
two good reasons:

1. to provide a true list of what has been proposed. It would save time to 
all and provide a good negative check list for those with an idea. At least 
it would be new to the FPS: it would be added or used.

2. very often the roots of the true solution is something which has been 
half thought and overlooked. Or something triggered in someone's mind by 
another idea.

jfc

PS. From what you quote, you seem to consider that SPAM=spoofing? Are there 
statistics and trends about that?



On 00:22 08/01/03, John C Klensin said:

>--On Tuesday, 07 January, 2003 13:33 -0500 Doug
><Dougxx2@carolina.rr.com> wrote:
>
> >> Doug has rediscovered the idea of closing open mail relays to
> > prevent
> >> unauthorised use by outsiders sending to outsiders. This was
> >> a big thing in the early 90s when email became popular.
> >
> > This may seem to be a bit basic for some of the people who
> > have worked on this problem for years. My intention was not to
> > prove that I had the latest and greatest solution to the spam
> > problem. It was to get the ball rolling in an open discussion
> > forum and present my ideas on the topic in the hopes that
> > someone who knew more than me on the topic would as well.
> >...
>
>Ok, Doug.  Let me take a shot at simultaneously explaining the
>problem here and  why your suggested solutions are getting such
>resistance.  Perhaps a different approach may succeed where
>Lloyd's didn't (not his fault, I'm sure).
>
>Almost all of the measures you have suggested have serious
>side-effects or critical prerequisites.  In the last analysis,
>most of us would rather put up with a little spam than pay the
>prices involved.  Others are sufficiently fed up with spam that
>they are willing to consider some very radical changes to how we
>use email.  But, regardless of how that comes out, the decisions
>have been fairly explicit: people have thought of your
>suggestions, and others, and their impact, and have made fairly
>explicit decisions about preferences.  My comment about X.400 of
>a few weeks ago was intended to address those issues, but
>apparently made a reference too far in the past, or too subtle,
>for some of the people who have been participating in the
>discussion.
>
>The people who have been through it are reluctant to start the
>discussion again because the dead horse has been kicked into an
>unrecognizable pulp. There has been a good deal of discussion,
>in many archives, that it would be good for you to read.  If you
>then come up with a _new_ idea that doesn't revisit the old
>problems, many of us would be enthused about listening.  It is
>only the old and discredited proposals that are met with
>intolerance.
>
>Let me take a closely-related pair of examples from your note.
>As I understand it, you would like ISPs (really email providers)
>to take responsibility for authenticating their customers.  And
>you would like IP addresses shown in mail header traces to be
>reliable.  Ok.  Those two things turn out to be much more about
>trust relationships than they are about protocols: one can make
>major changes to protocols without changing the trust
>relationships at all, and can accomplish those things without
>any changes in the protocols.  But, assuming that you aren't
>willing to trust anyone who can operate a mail-sending protocol,
>there are only a few ways that you can trust the source and
>origins of email.
>
>For example, we could, as a society, start licensing email
>providers, require each licensed provider to accept mail only
>from other licensed providers and from users they can
>authenticate (with severe penalties for violating those rules).
>That would make folks who would like to go back to business
>models in which they charge for every item of mail very happy.
>It would make many of the rest of us unhappy.  But it would
>work... and, while some protocol enhancements might make it
>easier to support, nothing is really required beyond SMTP as it
>exists today.
>
>Similarly, you could decide to work with an email mailbox
>provider who would refuse to accept mail from any site with
>which it didn't have an agreement about user authentication and
>traffic and which, were relaying permitted, would insist that
>any site from which it accepted a relayed message impose the
>same requirements on its users.  With some prototype agreement
>forms, this could be a way to build up a trust web similar to
>the licensing one, using a web of bilateral agreements rather
>than governmental action.
>
>But either of those approaches would result in less legitimate
>mail getting through.  For instance, I run my own mail servers
>and, as far as I know, can authenticate anyone who originates
>mail here.  But I have neither the resources nor the inclination
>to participate in a large collection of bilateral contractual
>agreements, nor to start applying for licenses.
>
>The issues with those bad IP addresses are similar.  Most are
>spoofed.  You can trust the information in Received headers only
>as far back as the last mail host you trust to report
>information accurately.  If there is a spammer deliberately
>deciding to deceive you, anything earlier is likely to be trash,
>not because the wrong information is in the Whois tables, but
>because the data in the Received fields is being made up (either
>at random or in the hope of pinning the spam on someone else).
>And, again, formalizing  the trust relationships through
>contracts or licenses would help a great deal, and might be the
>only solution, but those options carry a high price in terms of
>generally accessibility and usability of email.
>
>regards,
>     john
>
>p.s.
>
> > Asking questions, presenting possible solutions, and learning
> > from mistakes is how we get solutions.
>
>And learning what has been done and discussed in the past,
>before asking your questions of thousands of people, is usually
>considered, at least, polite.
>
>
>
>
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/02