Subject: How I deal with (false positive) IP-address blacklists...

From: Theodore Tso <[email-masked]>
Date: Tue, 9 Dec 2008 01:18:29 -0500

This doesn't work for most people, but I had fun composing this
response, and coming just a few weeks after people claiming that
IP-based blacklists work well, and rarely result in false positives, I
felt I just had to share.   :-)

						- Ted

Subject: Blacklisted IP address
From: Theodore Tso <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Date: Tue, 9 Dec 2008 01:00:09 -0500

Hi there.  Your mailer appears to have my one of the addressed used by
primary mailhub, 69.25.196.31 (it reverse-resolves to
www.church-of-our-saviour.org.).  Its primary ip address and hostname
is thunk.org, 69.25.196.29.  You can see who I am here:

	http://thunk.org/tytso

If you use any amount of Linux on your systems, I am the first North
American Linux Kernel developer, and the maintainer of e2fsprogs, the
filesystem utilities for ext2/ext3/ext4.  This bounce took place
because I replied to some user who apparently has a mailbox on
gondor.apana.org.au, on the Linux Kernel Mailing List.

The way I see things, I provde *way* more services to your users than
you do to me, so I don't see any reason to place an international
phone call to get my IP address un-blacklisted.  If one of your users
or one of your staff members needs my help to fix a Linux kernel
problem, or to unscramble an ext2/3/4 filesystem, or an invite to the
some future Linux Kernel Summit, and they can't receive my e-mail,
that is *your* problem, not mine.

I've arranged to make sure this gets routed via an mit.edu mailhub,
but that's about all I plan to do to resolve this problem.

Your move.

Best regards,

Theodore Y. Ts'o
Linux Foundation Fellow and Chief Platform Strategist
STSM, IBM Linux Technology Center
Medford, Massachusetts
(617) 245-5616
(781) 391-2699 (fax)
(781) 526-0121 (cell)

Subject: Warning: message 1L9Ulw-0001Yz-O5 delayed 24 hours
From: Mail Delivery System <[email-masked]>
To: [email-masked]
Date: Mon, 08 Dec 2008 21:34:22 -0500

This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on thunker.thunk.org.

The message identifier is:     1L9Ulw-0001Yz-O5
The date of the message is:    Sun, 7 Dec 2008 20:18:51 -0500
The subject of the message is: Re: Runaway loop with the current git.

The address to which the message has not yet been delivered is:

  [email-masked]
    Delay reason: SMTP error from remote mailer after end of data:
    host rhun.apana.org.au [64.62.148.172]: 451-sender IP address 69.25.196.31 is locally blacklisted here. If you think
    451 this is wrong, please call +61289874478.

No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Dec 2008 17:49:02 +1100

> felt I just had to share.   :-)

	They didn't say why they had blacklisted that IP so there
	is no way to determine if it was a false positive or not.
	That also make the request to phone if the listing was in
	error pretty hard to determine.

	Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Theodore Tso <[email-masked]>
Date: Tue, 9 Dec 2008 02:03:51 -0500

> 	error pretty hard to determine.

Well, it blocked a legitimate e-mail message, so by definition the
rejection was false positive.  I've also checked a number of DNSBL's,
and no one else seems to have black-listed my IP address, except these
jokers.

						- Ted

---

From: Mark Andrews <[email-masked]>
Date: Tue, 09 Dec 2008 18:24:11 +1100

> and no one else seems to have black-listed my IP address, except these

	Define "legitimate".  One that conforms to the RFC's?  One
	that you send?  One not containing advertising material?
	One that does not contain unsolicted advertising material?
	One about the content of the soil on the moon?  One that
	doesn't discuss the content of the soil on the moon?

	The only one that can determine if it was a false positive
	or not is the person that added the entry.

	Mark

---

From: Theodore Tso <[email-masked]>
Date: Tue, 9 Dec 2008 02:58:27 -0500

> 	doesn't discuss the content of the soil on the moon?

Well, the intended recipient, is a Linux Kernel Developer.  He posted
a message on the Linux Kernel Mailing List, about Linux Kernel
Developement.  I responded, on-topic, with a message that had no
advertising material, soliticted, or unsolicited.  I think that meets
the definition of "legitimate e-mail", don't you think?  It seems
pretty clear the recipient probably wnated to receive it, and in this
case, an IP address-based blacklist is causing him not to receive the
e-mail.  It has been made unreliable for him.

I also happen to be the founder and program committee chair of the
Linyx Kernel Summit, which brings together the top 75 kernel
developers to the summit, and for which the competition to receive an
invitation based on merit is highly competitive.  Heck, some companies
pay $25,000 USD and up in order to receive a sponsored invite to the
Kernel Summit.  Occasionally, I will send an invite to a fellow kernel
developer, and it will get bounced due to some bogus false positive
spam filter (very often, it tends to be an IP-based filter).  If I'm
feeling nice, I'll try to route around the brain-damage.  If I'm
feeling really annoyed, I'll just drop the bounce on the floor, and
assume the developer in question didn't really want the invite, or was
too stupid to find a reliable ISP/mail handler, so they don't deserve
the invite.

This happens to be relatively unique position where I have far more
power than the recipient, and in many cases they are much more
interested in receive e-mails from me than I am in bothering to figure
out why some bogus IP-based address filter bounced my mail.
Basically, if they would badly want to receive it, and some bogus
technology has made e-mail unreliable, I'd consider that a false
positive rejection of a legitimate e-mail message --- and in general,
it's their problem, not mine.  Any attempt I might make to work around
the breakage is due to my charity, not any obligation on my part.

						- Ted

---

From: John Levine <[email-masked]>
Date: 9 Dec 2008 11:33:01 -0000

Nothing personal, but you could hardly ask for a better
illustration.

For one thing, this isn't a case of broken DNSBLs, it's a case of
getting what you asked for.

Rather than using shared DNSBLs, this tiny host on a non-profit public
access network is desperately trying to run its own spam filters.
Maybe you sent him blowback from spam with forged addresses, maybe he
just mistyped someone else's address.  Whatever it was, in the absence
of shared DNSBLs, the option isn't no filtering, it's a million local
filters on a million mail hosts with millions of mistakes that can
only be corrected one by one.  At least this one was competent enough
to let you know that he'd rejected your mail.  A lot of the million
mail admins aren't.

For another, "I'm too important to block" is not a winning long term
response.  We're all important in some areas and unimportant in
others.  Spam sucks, spam filtering sucks, DNSBLs suck, but in a world
where >95% of all mail is spam, not filtering spam sucks way more, and
it even sucks way more than filtering with occasional mistakes.

If, rather than trying to do his own filtering, this guy used some of
the popular reliable DNSBLs (none of which list 69.25.196.31) both he
and you would have avoided this screwup.

Much though we might wish otherwise, spam and spam filtering aren't
going away, and by their nature, spam filters make errors.  Anyone who
claims otherwise is way, way, out of touch.  Some of us would rather
try to figure out ways to improve the delivery of real mail and
minimize the errors than rant about it.

R's,
John

>    host rhun.apana.org.au [64.62.148.172]: 451-sender IP address
>69.25.196.31 is locally blacklisted here. If you think

---

From: SM <[email-masked]>
Date: Tue, 09 Dec 2008 05:23:40 -0800

>the definition of "legitimate e-mail", don't you think?  It seems

By that definition this message would be legitimate 
too.  Fortunately, this message is being sent through a service 
provider that does not add a message footer with advertising material.

>e-mail.  It has been made unreliable for him.

The mail server of the recipient rejected the message because the IP 
address of the sender is listed locally in a blacklist.  This doesn't 
seem like a mail rejection solely based on information provided by a 
third-party.

For classification purposes, this is a false positive if the 
recipient wants the message.  Obviously, the recipient must be aware 
that he/she was not able to receive the message for that to happen.

The rejection message contained a phone number.  That can be used to 
contact the postmaster of the site if the rejection was 
incorrect.  That may be adequate for people exchanging mail 
locally.  As you pointed out, it's not a convenient means of 
communication when the sender is in another country and he/she might 
not bother to make a long distance call to resolve the problem.  In 
this case, the message is of little value to the sender; it's the 
recipient that stands to benefit from it.

Sometimes the IP address of the sending mail server is blacklisted 
because it's from a country or a region commonly associated with 
"illegitimate e-mails".  Maybe that's the case here. :-)

Even if the postmaster of the receiving server takes all reasonable 
steps to avoid false positives, it can still happen.  The postmaster 
can either provide an alternative means of communication which is not 
a burden to the sender or else stick to the belief that his/her mail 
filtering is perfect and it's up to the sender to jump through hops 
to get his/her message through.

Regards,
-sm

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Dec 2008 08:00:11 -0800

>    451 this is wrong, please call +61289874478.

Why do you think that this is relevant to the earlier discussion? That local administrator could just as easily blocked your site by domain name.

As others have pointed out, if the site didn't feel the need to keep local blacklists and instead use more heavily vetted ones, your message would not have been blocked. What are you advocating here?

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Dambier <[email-masked]>
Date: Tue, 09 Dec 2008 17:54:41 +0100

That reminds me of no-ip.com.

name belong to them. typo belongs to a gangster.

I used to have a workstation myname.typo with their dynamic dns.

When a friend sent me an email to myname.typo a lot of peculiar
things happened.

I informed no-ip about that gangster abusing their name.

That is when I lost my account.

I did not know what happened until I sent a dig or a whois
about typo to somebody else.

I don't dare spelling that domain in an email again.

That is all you need to get yourself on a blacklist.

Kind regards
Peter

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Tue, 09 Dec 2008 09:39:49 -0800 (PST)

> Why do you think that this is relevant to the earlier discussion? That local
> administrator could just as easily blocked your site by domain name.

Sadly, it is no less relevant than many of the responses that were posted
in the earlier thread.

I was and continue to be somewhat appalled by the various types of sloppy
thinking that have manifested during this discussion.

First and foremost, personal anecdotes are not the best evidence. In fact
they are barely evidence at all.

For example, let me describe my latest blocked email episode. I run a small
server that hosts a few users and some small mailing lists - 1000 members or
thereabouts is about the largest list I have. I recently noted a bunch of
addresses failing on one of my lists. Investigation revealed that I had run
afoul of a local blacklist operated by a small ISP. I rarely bother to pursue
such things because good outcomes are rare, but checking out their web site I
thought they sounded reasonably clueful (references to rfc-ignorant.org and
such), so I decided it was worth pursuing.

I contacted them and was informed that while my address was clean, there was
another address close by that was emitting spam that they had had to block. I
asked them why they couldn't just block the specific address and was told they
can only block entire ranges. And the minimum range size for them appears to be
so large that the offending address isn't even associated with my ISP! Long
story short, I've been screwed by an incompetently implemented local blacklist.

Not to belabor the obvious, but this would not have happened had they opted to
use, say, an appropriate Spamhaus list. (I checked and found my addres is not
listed and the offending address is.) Nor would it have happened had they
followed the implementation practices described in the DNSBL documents - they
would have been able to block the offending address without blocking me as
well.

So does this personal experience mean that DNSBLs are a great idea? Of course
it doesn't - it's just one case and probably representative of nothing. But the
same hoids for all of the other personal anecdotes people have posted.

Second, the fact that 10 years ago you set up sendmail for the computer club at
your college doesn't make you an expert on modern large scale email systemms
administration. The operational concerns for large-scale email setups today are
very different from thost that would have applied to small scale setups a few
years back.

I'm not going to get into the insight real operational experience provides
because I also lack the necessary operational experience to have an informed
opinion.

There are, however, several folks who do have experience with large scale email
operations who have posted in this thread and others similar ones here. These
are opinions that should be valued, especially when that experience doesn't
jibe with your own. And yet the overall response to such postings has IMO been
fairly dismissive if not outright condescending.

Third, while it may be the case that large ISPs and MSPs appear to many to
large, utterly impersonal edifices, the fact of the matter is that people do
complain to them when they believe their email has been lost or even delayed.
And the cost of handling complaints is considerable, which means that
considerable effort goes into trying to minimize the amount of lost mail. (I
have responded to or commmented on so many RFPs for improved filtering that
cite "reduce customer complaints about false positives" that I feel entirely
justified in making these assertions.) Mechanisms that have high false negative
or positive rates are quickly abanndoned in practice, so the fact that many if
not most large ISps and MSPS use DNSBLs really does count for something.

So the next time you decide to post a message about how your poor Saintly Aunt
Millie had a problem sending email to Uncle Harry a few years back and as a
result DNSBLs (or whatever the email topic du hour is) suck ass now and
forevermore, please do us all a favor and repurpose those electrons and instead
send an email to the person you know who took a job at <randomlargeisp> and now
runs their email setup asking for his or her opinion. You might even be
surprised at what you hear.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Dec 2008 11:23:10 -0800

> felt I just had to share.   :-)

Ted,

Evidently you believe that the anecdote you posted proves something, but I am 
not sure what.

Some others have suggested that it proves something which, I strongly suspect, 
is not what you had in mind.

Perhaps you can clarify the purpose of your note.  How should it be incorporated 
into the IETF's deliberations?

If you believe that it demonstrates that blacklists do not work well and/or do 
not rarely result in false positives, perhaps you can document the basis for 
that assessment.

I feel confident that you do not intend a single anecdote, about minor email 
service participants, to serve as the basis for such a global conclusion about a 
mechanism that is implemented and relied on by virtually every 
professionally-run email receiving service on the planet.

Thanks.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Tue, 9 Dec 2008 19:49:30 -0000

> Second, the fact that 10 years ago you set up sendmail for 
> the computer club at your college doesn't make you an expert 
> on modern large scale email systemms administration. The 
> operational concerns for large-scale email setups today are 
> very different from thost that would have applied to small 
> scale setups a few years back.
> 
> I'm not going to get into the insight real operational 
> experience provides because I also lack the necessary 
> operational experience to have an informed opinion.

To make good standards you need a broad selection of
informed opinion from different viewpoints. Why should
it not be as simple to set up an IETF standard email
system for a small organization as it was 10 years ago?

Definitely there are issues of scale that have to be 
considered, but if the IETF really wanted to have large
scale email operators drive new Internet email standards
then we would hand the job over to MAAWG. 

You are right that the quality of the discussion about
DNSBLs has not been too good. But the underlying problem
seems to be that dissenting voices did not participate in
the drafting of the DNSBL document, and therefore the document
writers had not found the right level of compromise to get
the dissenters on board. Anyone can claim to be a great expert
and write a standards document, but the real hard work is in
getting a group of people with differing backgrounds and
experience to agree with that standards document.
 
--Michael Dillon

---

From: [email-masked]
Date: Tue, 09 Dec 2008 11:57:08 -0800 (PST)

> system for a small organization as it was 10 years ago?

You can lament the present-day realities until the cows come home, but the fact
of the matter is that it is harder - much harder.

I should know, because I was running such a system then, just as I do now. Just
as one example - there are many others - back in 1998 there was no need for
mandatory spam filtering (I first imposed mandatory filtering on all users on
my systems back in 2002), That right there ups the complexity, not to mention
the overhead, of operation by about an order of magnitude, and can easily have
the effect of pushing the operational issues past what a local IT person with
many other responsibilities is able to handle.

> then we would hand the job over to MAAWG.

You're completely missing the point. This issue isn't knowing how to build a
large scale email system and I never said it was. Rather, the issue is whether
or not people's opinions about the effectiveness of various antispam mechanisms
are valid when all they have is a small amount of experience, often quite
dated.

Maybe it's just me, but I'll take the evidence presented by  someone who has
access to the operational statistics for a mail system that services 10s of
millions of end users and handles thousands of  outsourced email setups over
someone like myself who runs a tiny little setup any day.

> DNSBLs has not been too good.

That is far too kind.

> But the underlying problem
 
You might want to review the actual discussion before making such claims. And
while you're at it you might also want to explain how it would be possible to
get views that are, to a close first approximation,  summed up as "DNSBLs are
evil incarnate" on board.

				Ned

---

From: Peter Dambier <[email-masked]>
Date: Tue, 09 Dec 2008 21:12:19 +0100

There is one thing I could proof when counting the emails going
through the mailer I am responsible for.

When we started blocking emails from dynamic addresses we
reduced spam by 50%.

The gurus would not believe but I could show thenm, when we
blocked all but the dynamic addresses we could reduce spam
by 50% too.

The bad side, we could not show how many legitimate mails
did not come through in either case. They were lost.

Mailblockers maintained by humans are never perfect. spamhause
proofed that when they knowingly blocked atnic.at allthough
atnic.at had never sent spam.

There is little difference between a mailblocker maintained
by humans and a greylist maintained by your own computer
except you can correct problems yourself.

When I see mailblockers usually blocking all dynamic addresses
then I can conlude from my observations that they have at
least 50% false positives.

There is a minor annoyance with greylists - broken mailers
and people with 50 outgoing mailers.

Broken mailers are mostly spammers, more than 50%.

People with more than 50 outgoing mailers are mostly the
source of all that spam. So the greylist is no worse than
a mailblocker and it always gives you a second chance.
A mailblocker does not.

Looking into my exim4 log I can see more than 90% of spam
gets lost when some bot on a hitch-hiked machine tries to
imitate a mailer.

When you try TLS on an incoming mail they all get lost.

So why do they setup expensive machines in a colo to run
a mailblocker?

Money!

And you can put those few people with 50 outgoing mailers
on your whitelist.

Kind regards
Peter

Dave CROCKER wrote:
> Evidently you believe that the anecdote you posted proves something, but
> I am not sure what.
> 
> Some others have suggested that it proves something which, I strongly
> suspect, is not what you had in mind.
> 
> Perhaps you can clarify the purpose of your note.  How should it be
> incorporated into the IETF's deliberations?
> 
> If you believe that it demonstrates that blacklists do not work well
> and/or do not rarely result in false positives, perhaps you can document
> the basis for that assessment.
> 
> I feel confident that you do not intend a single anecdote, about minor
> email service participants, to serve as the basis for such a global
> conclusion about a mechanism that is implemented and relied on by
> virtually every professionally-run email receiving service on the planet.
> 
> Thanks.
> 
> d/
>

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Dec 2008 14:12:40 -0800

[email-masked] wrote:
>       Why should

If you go back far enough, New York City was small and friendly.  Not much 
required to build a satisfactory home there.

Things have changed.  No matter the size of the home, things have changed.

Environmental pressures are ignored only at one's serious risk.

d/

-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Tue, 9 Dec 2008 22:22:22 -0000

> Maybe it's just me, but I'll take the evidence presented by  
> someone who has access to the operational statistics for a 
> mail system that services 10s of millions of end users and 
> handles thousands of  outsourced email setups over someone 
> like myself who runs a tiny little setup any day.

Then the IETF is the wrong place to look for help. The IETF
does not give a lot of priority to documenting operational
practices. You really should be looking here 
<http://www.maawg.org/about/publishedDocuments>
And given that MAAWG exists and does a good job of
publishing email operational best practices, I wonder
why people are so worried that the IETF does not do so.

> You might want to review the actual discussion before making 
> such claims. And while you're at it you might also want to 
> explain how it would be possible to get views that are, to a 
> close first approximation,  summed up as "DNSBLs are evil 
> incarnate" on board.

To begin with, the draft authors could have tried to incorporate
those views into the Security Considerations section, since when
you scratch the surface of the "DNSBLs are evil" opinions you
will most often find anecodtes about lost or blocked email. 
Simply ignoring those views will not get you to consensus.

--Michael Dillon

---

From: <[email-masked]>
Date: Tue, 9 Dec 2008 22:26:26 -0000

> >       Why should
> > it not be as simple to set up an IETF standard email system for a 
> > small organization as it was 10 years ago?
> 
> 
> If you go back far enough, New York City was small and 
> friendly.  Not much required to build a satisfactory home there.
> 

I agree with all of your points. But I also believe that it should
be possible to encapsulate the neccessary security features into
an Internet email architecture so that people can set up an email
server for a small organization in an afternoon, and it will pretty
much run on its own. The fact that the current Internet email
architecture
does not allow for this, and therefore disenfranchises small 
organizations from running their own email services, does not 
dissuade me from believing that we could fix the problem if we
put some effort into doing so.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Tue, 09 Dec 2008 17:42:05 -0500

> are valid when all they have is a small amount of experience, often quite

Granted that it's always dangerous to extrapolate from a small sample.

But is anybody's experience valid, then?

>From my perspective, the guys who run these large email systems
generally seem to believe that they have to do whatever they're doing,
regardless of how much the filtering criteria that they're using have
any thing to do with the desirability of the mail to the recipient, and
regardless of any particular sender's or recipient's actual experience
with having their mail filtered.

IOW, It's very easy for both the individual and the mail system operator
to find reasons to disregard the other's experience.   Who is to say who
is right?

I certainly don't think that a mail system operator's actions to filter
mail without the recipient's consent are inherently justified just
because they happen operating a mail system.  They do bear some
responsibility for their role in this process and in their selection of
filtering criteria.

--

As for Ted's message, I just thought it was an interesting anecdote, and
(as others have pointed out) not particularly relevant to the DNSBL
discussion.  I didn't see anything wrong with him posting it, and don't
understand why it's provoked such a reaction.

--

And as for DNSBLs - clearly, there are both good and bad aspects to
using third party reputation services as opposed to sites using their
own filtering criteria.  e.g.:

benefits of third party reputation services:
- when the number of "customers" of a reputation service helps defray
the cost of maintaining a current and accurate list, and of improving
their criteria over time
- when the high visibility of a popular reputation service helps keep it
honest

drawbacks of third party reputation services:
- when a widely used reputation service is wrong in a way that affects a
large number of sites, whereas when a single site's criteria are wrong
it only affects that site's recipients (and arguably the single site is
more accountable for its actions).
- when the reputation is based on something (like an address or address
block) that isn't sufficiently fine-grained to reliably distinguish spam
from ham, as compared to a site filter which has access to more criteria
and can use the larger set of criteria to filter more accurately.

Once again, the crucial issues seem to be transparency, accountability,
granularity rather than the reputation reporting mechanism.  Which is
not to say that the mechanism doesn't also warrant improvement.

Keith

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Dec 2008 15:00:24 -0800

[email-masked] wrote:
>    But I also believe that it should
> architecture does not allow for this, 

I think you are confusing architecture with implementation.

You need to talk with product vendors, not protocol architects.

d/
-- 

   Dave Crocker

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 9 Dec 2008 15:00:50 -0800

[email-masked] wrote:
> ...
> Maybe it's just me, but I'll take the evidence presented by  someone
> who has access to the operational statistics for a mail system
> that services 10s of millions of end users and handles thousands of  
> outsourced email setups over someone like myself who runs
> a tiny little setup any day.

While large scale is important, small scale setups must not be sacrificed
along the way. We must not create a system where a small cartel of players
hold the keys to 'interoperability' at the deployment level. Current
filtering practice creates way too many false positives already because the
large organizations can't afford to bother with identifying the source. My
lowly server just handles my wife, myself, and my daughter's business, and
way too often I hear complaints about bounces because largeispmailer.com is
refusing to accept mail from an insignificant non-member-of-the-club server.

By no means do I claim enough knowledge about mail services to offer
anything more than the viewpoint of an amateur trying to run a small server.
I would agree with the comments along the way that the current
state-of-the-art is way too hard, and I am sure my configuration is not
correct or complete because I get mail from the process every few hours
stating -- error: gpg required but not found!   yet every time I try to
resolve that I can't figure out what is wrong or if a symbolic link is
missing. Even with help from example configs at jck & psg, it took a fair
amount of time and experimentation to cut over from the previous mta that
was being crushed by the spam load. Life is better now, and as of a few
hours ago mail from the ietf list is flowing over IPv6, but I know the MX
record still needs work because the IPv6 path is being locally redirected.

Tony

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 09 Dec 2008 15:19:34 -0800

Tony,

Please re-read what Ned wrote.  It was about evidence based on extensive 
experience, as opposed to evidence based on far less experience.

His note had nothing to do with "sacrificing" smaller operators.  It had to do 
with smaller operators who are more likely to have much less expertise.

The thread is about the problem with basing strategic protocol decisions on tiny 
sample sizes, often numbering one datum.

As for the reason for false positives, they are numerous.  But the underlying 
issue is with the inherent requirement for heuristics.  That's not due to some 
operators being big or small and/or insensitive or incompetent.  It's the nature 
of the technical and operational realities.  Heuristics produce statistical 
results and statistics invite a trade-off between Type I and Type II errors.  A 
tradeoff means you can't get either perfect.

Some operators (big or small) choose to deal with that fact badly.  Others deal 
with it well.

The tenor of the topic, on this list, is that vagaries in operational skill 
concerning email abuse are somehow different from the vagaries we see with 
routing, reliability, user interface design problems, and all other manner of 
real-world uncertainty.

It isn't.

d/

-- 

   Dave Crocker

---

From: [email-masked]
Date: Tue, 09 Dec 2008 17:30:03 -0800 (PST)

> generally seem to believe that they have to do whatever they're doing,

Keith, with all due respect, I haven't exactly seen a flood of well-designed
proposals for viable alternatives. Perhaps instead of simply reiterating over
and over that these  beliefs are false you should instead try coming up with an
alternative that demonstrate their falseness.

> any thing to do with the desirability of the mail to the recipient,

Schemes that attempt to assess the desirability of the email to the recipient
have been tried - personal whitelists, personal Bayesian filters, etc. etc. In
practice they haven't worked all that well, perhaps due to the average user's
inability to capably and consistently perform such assessments.

> and

Well, sure. When you have a million users it's not only difficult to focus on
an individual user's needs, it's also totally inappropriate.

> to find reasons to disregard the other's experience.   Who is to say who

Absent a working crystal ball there is of course no way to *know* who's right.
But consider this: If you have cancer, would you be more comfortable taking
that quack nostrum that one guy says cured him or the medication with proven
efficacy in a bunch of double blind clinical trials? That one guy *could* be
right. But is this a chance you want to take?

Like it or not, sample size reallly does matter. But if you really do prefer
individual anecdotal evidence, I'll point out that in practically every bogus
blocking incident I've seen of late, the fault lies not with an operation like
Spamhaus, but with some local yokel who thinks he's come up with the FUSSP.

> responsibility for their role in this process and in their selection of

And from what I've seen most of the ones I deal with - these folks are our main
customers - take those responsibilities extremely seriously, if for no other
reason than large numbers of complaints are very costly to deal with and will
end up getting them fired.

And I've seen such firings happen, so please don't bother trying to convince me
they don't.

> understand why it's provoked such a reaction.

It provoked a strong reaction from me because it both reminded me of the
appallingly  low quality of the previous discourse and seemed like an
indication of the resumption of same. And I simply couldn't take another round
of it.

> not to say that the mechanism doesn't also warrant improvement.

On this we agree, more or less. But it seems to me that these goals  are far
more likely to be met with a set of standardized mechanisms than without.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Tue, 09 Dec 2008 22:21:26 -0500

> alternative that demonstrate their falseness.

Well, at the risk of over-extrapolating from scant data again, there
does seem to be some variation in both practice and and the quality of
user experience among mail system operators.  So maybe they don't all
"have" to be doing exactly what they're doing now.

> inability to capably and consistently perform such assessments.

I think we're saying slightly different things.

It's one thing to say that attempts to use recipient feedback to tune
spam filters on an individual basis has so far not worked well (which is
what I take you to be saying, and which also corresponds to my
understanding).

It's quite another thing to say that the recipient's experience of
existing spam filtering systems (however they are tuned) is irrelevant.

> an individual user's needs, it's also totally inappropriate.

Mumble.  It's those millions of individual users' experiences that
fundamentally matter.  If the test cases don't accurately predict their
experiences, then the test cases are wrong.

A more defensible statement is that it's not economically feasible to
pay staff to deal with each of those individual users on an individual
basis, understand their individual problems, and try to fix them on an
individual basis.

> right. But is this a chance you want to take?

It's an interesting analogy, because the medical profession (at least in
the US) also seems to have lost its ability to consider the individual
situation of each patient - assuming that individual patients' success
rates will closely correspond to those predicted by aggregate
statistics, and for which typically, only a small number of variables
were considered.

> more likely to be met with a set of standardized mechanisms than without.

That's my assumption also.

Keith

---

From: Peter Dambier <[email-masked]>
Date: Wed, 10 Dec 2008 09:05:21 +0100

> Spamhaus, but with some local yokel who thinks he's come up with the FUSSP.

In the case government of austria contra spamhaus that local yokel must have
been  Bundeskanzler Gusenbauer  ?

Neither the austrian government nor their atnic.at is or has been sending
spam nor are they selling domains.

But spamhaus blocked them.

All mailblockers are primarily mailblockers and sometimes they do hit spam.

But it is in this list like in real spam live.

One party believes in the holy blacklist also there are different cults who
believe in their very own blacklist -

and the other party knows all mailblockers are run by the devil and they
can proof it. But a proof is nothing against a belief.

Kind regards
Peter

---

From: <[email-masked]>
Date: Wed, 10 Dec 2008 08:30:24 -0000

> Schemes that attempt to assess the desirability of the email 
> to the recipient have been tried - personal whitelists, 
> personal Bayesian filters, etc. etc. In practice they haven't 
> worked all that well, perhaps due to the average user's 

You are talking about the operational imperative. In ops
you have to work with what you have and make the best of
things.

> Well, sure. When you have a million users it's not only 
> difficult to focus on an individual user's needs, it's also 
> totally inappropriate.

In ops, yes. But in design its the other way around. The needs
of a single user form a use-case which guides the designers.
In this forum there are some who believe that the Internet
email architecture can be reformed so that it does not have
the same weakenesses which allow the flood of spam to produce
a positive statistical result for the spammers.

DNSBLs may be needed today in email operations, but if the
IETF steps up and does the work to fix the root of the
problem, perhaps they won't be needed at all in the 
future.

> And from what I've seen most of the ones I deal with - these 
> folks are our main customers - take those responsibilities 
> extremely seriously, if for no other reason than large 
> numbers of complaints are very costly to deal with and will 

Again you are talking about email operations which is
dealt with very well by MAAWG. 

> It provoked a strong reaction from me because it both 
> reminded me of the appallingly  low quality of the previous 
> discourse and seemed like an indication of the resumption of 
> same. And I simply couldn't take another round of it.

So how do you and Ted reach consensus? What is it that
you and he have failed to understand which causes you
to have such emotionally opposite reactions? I suspect
that you are thinking like an email operator who has the 
position that you can't change what is being thrown at
you so you just have to deal with it and live with the 
damage. And Ted is thinking like a user who wishes that
Internet email would just work, like his TV and his web
browser. Neither of you are wrong.

--Michael Dillon

---

From: [email-masked]
Date: Wed, 10 Dec 2008 07:42:22 -0800 (PST)

(While Dave's response to this is exactly correct - notihng in my original
note had anything to do with sacrificing small scale setups - our failure
to discuss these matters sensibly has some very important implications for
small operators that deserve further comment.)

> along the way.

Of course not. But that's precisely the effect our current approach - or
rather, non-approach, is having.

> We must not create a system where a small cartel of players
> hold the keys to 'interoperability' at the deployment level.

We're not creating much of anything - we seem to prefer endless religious
arguments and discussions of irrelevanyt anecdotes to actually getting stuff
done. And one of the results of this is that the big players, who would very
much like to see the development of standards for accessing reputation systems,
standards for so-called feedback loops, and so on and so forth, get tired of
waiting and simply roll their own. And when that happens the little guys have
no place at the table.

> Current

Exactly. You and I are not able to play because the standards for the
reputation systems and other antispam measure these guys are using are designed
in private with no consideration given to open access.

The way you change that is by, you know, codifying ways to do these things in
openly available standards. But we don't seem to be able to do that.

				Ned

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 9 Dec 2008 21:52:52 -0500

On Tue, Dec 09, 2008 at 02:03:51AM -0500, Theodore Tso wrote:
> rejection was false positive.  

That's incorrect.  Determining whether the rejection was a false positive
or true positive is the sole prerogative of the recipient, never the sender.

Why?  Well, first, because it is the recipient who is generously furnishing
the privilege of access to a service to the sender.  And second, because
were it otherwise, we would of course be told by every spammer on the
planet that rejection of their abuse constituted a FP.  (We already *have*
been told this by a substantial number of them.)

Of source, the sender may wish to report the incident to the recipient,
or suggest to the recipient that this may be a FP, but the final decision is
still that of the recipient.

For example, I've blocked all the IP allocations of several countries
in some of the mail servers that I run.  (After years of non-stop spam and
precisely zero non-spam messages.)  Those rules are doing precisely what
I intend them to do, and unless the IP allocations are changed, will
never cause a FP.  (That is: suppose a block is reassigned to another
country that I do not wish to block, and that an incoming message from it
subsequently is presented and rejected.  That would be a FP.)

---Rsk

---

From: Theodore Tso <[email-masked]>
Date: Wed, 10 Dec 2008 11:57:10 -0500

> incorporated into the IETF's deliberations?

The point I was trying to make is that there seems to be an inherent
assumption by some people, perhaps because the people who make these
assumptions run large mail servers, that the problem with someone who
is wrongly blocked rests solely with the sender, and not with the
utimate recipient, or with the mailer operator.  It's essentially an
attitude of you have no _right_ to send us e-mail, and if we make an
(inevitable) mistake, and blacklist list you incorrectly, it is up to
**you** (the sender) to go to us on bended knee and prove tht you are
not an evil spammer, or an incompentent Windows desktop owner who has
let their machine be taken over by a botnet.

I'm sure they feel magnaminous when they offer some method of
approaching them on bended knee, hoping that that they will give you
permissionto send e-mail --- whether it is via a phone number or
whether it is via placing an international phone call and paying $$$
to some Austrialian PTT to beg and plead to be removed from some IP
blacklist --- and I am still not convinced it is the best indetifier
when deciding whether or not blocking *all* mail from a particular IP
address.  You may be trying to place the burden on me, but consider
that we are merely getting assertions from the other side of the aisle
as well.

My main point, though, is that in some cases, the ultimate recipient
may have a much greater interest in receiving the e-mail than the
sender, and so the model of requiring the sender to assume the burden
of proof and go on bended knee to the mailserver administrator to let
their e-mails through may not be a particularly good model to use as
the basis for making recommendations for best practice.

Regards,

						- Ted

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 10 Dec 2008 10:23:30 -0800

Theodore Tso wrote:
> is wrongly blocked 
...
> may have a much greater interest in receiving the e-mail 

Ted,

I asked how your comments were relevant to current IETF deliberations and you 
responded by re-asserting your complaints.

We have all suffered slights from one service provider or another.  Shall we all 
burden the IETF list with recitations of them?

To the extent that you believe there is a larger issue, as you appear to, based 
on your saying "inherent assumption by some people" you provide no documentation 
that it is pervasive or significantly problematic for email operation, nor that 
it is a matter the IETF can do anything about.

Email abuse is extremely frustrating.  We all understand that.  Some of us put 
quite a bit of effort trying to find ways to counter it.  But I fail to see how 
it helps to use the IETF list for venting one's favorite, latest example of a 
problem with getting something resolved.

Really:  If there is a larger issue that the IETF can and should tackle, then 
let's talk about it.  But I'm still not seeing how the thread you started qualifies.

d/
-- 

   Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Dec 2008 10:54:58 -0800

At 11:57 AM -0500 12/10/08, Theodore Tso wrote:
>utimate recipient, or with the mailer operator.

"seems" ... "perhaps" ...

I know of no one on this list who makes those assumptions. In my discussions with people who "run large mail servers", none of them have made that assumption.

Who do you think are making those assumptions?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 10 Dec 2008 11:30:09 -0800

Hi -

> From: "Dave CROCKER" <[email-masked]>
> To: "Theodore Tso" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, December 10, 2008 10:23 AM
> Subject: Re: How I deal with (false positive) IP-address blacklists...
...
...

The problem is a mis-match between the protocol model (and
the points for spam blocking it affords) and the economics of
actual use.

The debate about sender-vs-recipient responsibility for dealing
with false positives misses the point that the party usually
responsible for the blocking is under the control of neither
the sender nor the recipient.  I've spent enough time on hold to
far-away lands to be skeptical of claims that ISPs are really
that interested in resolving false positives, but I recognize that
the experience of individual users isn't considered valid data.

Ted's core point seems to be that that the "delivery value"
economic argument does not always align with the "sender
assumes responsibility for out-of-band-delivery when
blocked" model, particularly when the cost of out-of-band
delivery is far greater than the value of delivery to the sender,
no matter how badly the intended recipient who requested the
information might want it.

By looking only at the SMPT protocol exchange, rather than
the next-layer-up request-for-info followed by response, the
real use case is distorted.

Randy

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Dec 2008 15:30:08 -0500

> I know of no one on this list who makes those assumptions. In my
> discussions with people who "run large mail servers", none of them have
> made that assumption.

My experiences are similar to Ted's.

They may not realize that they're making such assumptions.  But such
assumptions are implicit in the notion that the sender should jump
through some additional hoop in order to get his name off of a blacklist
or to get his mail accepted.

(One hoop that I was recently asked to jump through was to change the
PTR record for the source address of my outgoing mail server so that it
contained a label of the form "mail" or "mx#".)

The emphaiss on operators of "large mail servers" may be missing the
point.  A significant amount of mail is not sent via "large mail
servers". And I don't think that many of us want effective email to be
limited to "large mail servers".

And maybe there are some good guys out there who don't expect senders
(or their mail systems) to jump through arbitrary hoops in order to get
mail through.  But unless there are clear and effective guidelines for
what all operators should do regarding spam (and most operators follow
them), mail will continue to be unreliable.   Simply saying "use a
trustworthy blacklist" is not sufficient - it's just deferring the
problem to a third party with even less accountability to the endpoints
and less transparency.

Keith

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Dec 2008 10:24:36 -0800

On Dec 9, 2008, at 2:42 PM, Keith Moore wrote:

> when the reputation is based on something (like an address or  
> address block) that isn't sufficiently fine-grained to reliably  
> distinguish spam from ham, as compared to a site filter which has  
> access to more criteria and can use the larger set of criteria to  
> filter more accurately.

Email systems resources must be defended when confronting millions of  
compromised systems and infiltrated providers slow at removing abusive  
accounts.  Resources are best preserved when acceptance is decided  
prior to the exchange of message data.  Mapping regions known to host  
compromised systems or having been frequently hijacked is typically  
done by IP address.  As Ned mentioned, some systems block ranges that  
span across announced routes.  Although there is no reason for this,  
the growing size of the problem and the address space requires  
negative assessments be done by CIDR.

Rather than depending upon knowing the location of specific abusive  
sources, the Internet needs a registry of legitimate sources which  
includes contacts and IP address ranges.  Such a list should reduce  
the scale of the problem, and allow safer exclusions.  Normal defenses  
using Turing tests fail as the state of the art advances.  Even if  
there was a registry, what egalitarian identifier can be used to  
defend the registration process?  Receipt of text messages or faxes?   
Postal mail?  What can replace the typical Turing test?

-Doug

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Dec 2008 16:51:22 -0500

--On Thursday, 11 December, 2008 10:24 -0800 Douglas Otis
<[email-masked]> wrote:

>...
> Rather than depending upon knowing the location of specific
> abusive sources, the Internet needs a registry of legitimate
> sources which includes contacts and IP address ranges.  Such a
> list should reduce the scale of the problem, and allow safer
> exclusions.  
>...

Doug,

Independent of much of the rest of this discussion (and a lot of
its tone, which I both sympathize with and deplore), that
suggestion takes us down exactly the path some of us most fear
and which some of the folks who have been posting read into the
use of blacklists in practice (whether that reading is
reasonable or not).

As soon as one starts talking about a registry of "legitimate"
sources, one opens up the question of how "legitimate" is
determined.  I can think of a whole range of possibilities --
you, the ITU Secretary-General, anyone who claims to have the
FUSSP, governments (for their own countries by licensing or more
generally), ICANN or something ICANN-like, "large email
providers", and so on.  Those options have two things in common.
Most (but not all) of them would actually  be dumb enough to
take the job on and they are all unacceptable if we want to
continue to have a distributed-administration email environment
in which smaller servers are permitted to play and people get to
send mail without higher-level authorization and certification.

While I freely admit that I have not had hands-on involvement in
managing very large email systems in a large number of years
now, I mostly agree with Ned that some serious standards and
documentation of clues would be useful in this general area.
But I see those as useful if they are voluntary standards, not
licensing or external determination of what is legitimate.  And
they must be the result of real consensus processes in which
anyone interested, materially concerned, and with skin in the
game gets to participate in development and review/evaluation,
not specifications developed by groups driven by any single
variety of industry interests and then presented to the IETF (or
some other body) on the grounds that they must be accepted
because anyone who was not part of the development group is
obviously an incompetent idiot who doesn't have an opinion worth
listening to.  

That has been my main problem with this discussion, and its
variants, all along.  While I've got my own share of anecdotes,
I don't see them as directly useful other than as refutations of
hyperbolic claims about things that "never" or "always" happen.
But, when the IETF effectively says to a group "ok, that is a
research problem, go off and do the research and then come back
and organize a WG", it ought to be safe for someone who is
interested in the problem and affected by it --but whose primary
work or interests lie elsewhere-- to more or less trust the RG
to produce a report and then to re-engage when that WG charter
proposal actually appears.  Here, the RG produced
standards-track proposals, contrary to that agreement, and then
several of its participants took the position that those
proposals already represented consensus among everyone who
counted or was likely to count.  Independent of the actual
content of the proposal(s), that is not how I think we do things
around here... nor is laying the groundwork for an official
determination of who is "legitimate" and who is not.

    john

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Dec 2008 16:36:43 -0800

On Dec 11, 2008, at 1:51 PM, John C Klensin wrote:
> determined.  I can think of a whole range of possibilities -- you,  
> the ITU Secretary-General, anyone who claims to have the FUSSP,  
> governments (for their own countries by licensing or more  
> generally), ICANN or something ICANN-like, "large email providers",  
> and so on.  Those options have two things in common. Most (but not  
> all) of them would actually  be dumb enough to take the job on and  
> they are all unacceptable if we want to continue to have a  
> distributed-administration email environment in which smaller  
> servers are permitted to play and people get to send mail without  
> higher-level authorization and certification.

Perhaps I should not have used the word legitimate.  The concept of  
registry should engender a concept of accountability.

Once one considers IPv6, just the network portion covers 2^32 times as  
many IP addresses as are present in IPv4.  In this quantity, IPv6  
addresses do not offer a scalable means upon which a server is able to  
impose a defense against abuse.  The server will handle addresses in  
rather large groups as the only method left available.  The  
consolidation of addresses into large groups will be the enemy of an  
egalitarian effort wanting to ensure access to all players.

Counter to this, much of the email abuse has been squelched by third- 
parties who allow network providers a means to indicate what traffic  
of which they are accountable.  This is done in part by the assignment  
of address ranges as belonging to dynamically assigned users.  It does  
seem as though a more formalized method though a registry support by  
provider fees would prove extremely beneficial at reducing the scale  
of the IP address range problem raised by IPv6.  By formalizing a  
registration of accountable use, along with some type of reporting  
structure or clearinghouse, IPv6 would have a better chance of gaining  
acceptance.  It would also empower providers to say what potentially  
abused uses they which to support.

> managing very large email systems in a large number of years now, I  
> mostly agree with Ned that some serious standards and  documentation  
> of clues would be useful in this general area.  But I see those as  
> useful if they are voluntary standards, not licensing or external  
> determination of what is legitimate.  And they must be the result of  
> real consensus processes in which anyone interested, materially  
> concerned, and with skin in the game gets to participate in  
> development and review/evaluation, not specifications developed by  
> groups driven by any single variety of industry interests and then  
> presented to the IETF (or some other body) on the grounds that they  
> must be accepted because anyone who was not part of the development  
> group is obviously an incompetent idiot who doesn't have an opinion  
> worth listening to.

Agreed.

> variants, all along.  While I've got my own share of anecdotes, I  
> don't see them as directly useful other than as refutations of  
> hyperbolic claims about things that "never" or "always" happen. But,  
> when the IETF effectively says to a group "ok, that is a research  
> problem, go off and do the research and then come back and organize  
> a WG", it ought to be safe for someone who is interested in the  
> problem and affected by it --but whose primary work or interests lie  
> elsewhere-- to more or less trust the RG to produce a report and  
> then to re-engage when that WG charter proposal actually appears.   
> Here, the RG produced standards-track proposals, contrary to that  
> agreement, and then several of its participants took the position  
> that those proposals already represented consensus among everyone  
> who counted or was likely to count.  Independent of the actual  

A registry of accountable use in conjunction with some type of  
reporting structure seems a necessity if one hopes to ensure a player  
can obtain the access that they expect.  In other words, not all  
things will be possible from just any IP address.  Providers should  
first assure the Internet what they are willing to monitor for abuse,  
where trust can be established upon this promise.  Not all providers  
will be making the same promise of stewardship.  Those providers that  
provide the necessary stewardship for the desired use should find both  
greater acceptance and demand.  Such demand may help avoid an  
inevitable race to the bottom.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Fri, 12 Dec 2008 08:38:42 -0500

--On Thursday, 11 December, 2008 16:36 -0800 Douglas Otis
<[email-masked]> wrote:

>> As soon as one starts talking about a registry of
>> "legitimate"   sources, one opens up the question of how
>...
> Perhaps I should not have used the word legitimate.  The
> concept of registry should engender a concept of
> accountability.
>...
> Counter to this, much of the email abuse has been squelched by
> third-parties who allow network providers a means to indicate
> what traffic of which they are accountable.  This is done in
> part by the assignment of address ranges as belonging to
> dynamically assigned users.  It does seem as though a more
> formalized method though a registry support by provider fees
> would prove extremely beneficial at reducing the scale of the
> IP address range problem raised by IPv6.  By formalizing a
> registration of accountable use, along with some type of
> reporting structure or clearinghouse, IPv6 would have a better
> chance of gaining acceptance.  It would also empower providers
> to say what potentially abused uses they which to support.

Again, while it is possibly that we are using different
vocabularies or not communicating for other reasons, as soon as
you say "support by provider fees", I hear "purchase a license
to be able to send mail".  I can imagine a number of
organizations who would be happy to operate such a system and
collect those fees.  None of them make me very happy, especially
if they are unregulated, and some would raise grave privacy
concerns.

> reporting structure seems a necessity if one hopes to ensure a
> player can obtain the access that they expect.  In other
> words, not all things will be possible from just any IP
> address.  Providers should first assure the Internet what they
> are willing to monitor for abuse, where trust can be
> established upon this promise.  Not all providers will be
> making the same promise of stewardship.  Those providers that
> provide the necessary stewardship for the desired use should
> find both greater acceptance and demand.  Such demand may help
> avoid an inevitable race to the bottom.

Doug, we've got a worked example of a system that was intended
to provide protection against abuse by qualifying and certifying
providers in return for a fee.   The system was developed as the
result of a consensus process among those who could convince
others that they were stakeholders, not merely by a few
providers making rules for others, so it should have been off to
a good start.  That system is ICANN's registrar accreditation
process.  It has been, IMO, effective at two things: (i)
fattening ICANN's coffers and (ii) encouraging and developing a
whole new industry of bottom-feeders, including many of those
who contribute to the spam problem by supplying domain names to
phishers and promoters of other kinds of fraud and helping to
hide to ownership of those names.

Unless you have a plausible theory about how a registration
system can be run without falling victim to ICANN-like problems,
I can't consider the idea very credible.

   john