Subject: Re: The utilitiy of IP is at stake here

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 1 Jun 2003 22:56:52 +0200

On zaterdag, mei 31, 2003, at 17:32 Europe/Amsterdam, Paul Hoffman / 
IMC wrote:

> To bludgeon the point a bit:

> - Big ISPs and other mail service providers know how much spam is 
> costing them.

Ah, but how much does spam earn them? I assume spammers pay for their 
bandwidth. Then there are all the anti-spam products. I'm not accusing 
anyone here, but if we're going to run the numbers we have to run ALL 
the numbers.

> - For some ISPs, the amount is in the millions of dollars.

If you have an 8 digit customer base pretty much any per-customer 
action is going to cost you millions. In and of itself that doesn't 
meany anything. A few years ago doing public key crypto for each 
incoming message would have been impossible, or at least more expensive 
than dealing with spam the traditional way. Today it's probably not 
even very hard.

> - Even an expensive team of consultants could devise a trust-based or 
> work-based protocol and shepherd it through the IETF for less than one 
> tenth the annual cost for a single ISP.

> Given the above, the reason that the people who are most financially 
> hurt by the spam problem have not done anything about it from a 
> protocol level is either that they are financially stupid or that 
> their research into the solutions didn't result in a solution that 
> would cost them more. I believe it is the latter.

Based on what I've seen here people are almost eager to pronounce the 
spam problem unsolvable. I think that means the problem scope is 
defined too narrow. Using current SMTP, we can't stop spam. One ISP or 
a small group of them can't change SMTP. Ergo, the problem is 
unsolvable. But the IETF _can_ create new protocols and does so as a 
matter of routine. A good number of them are even deployed.

So I'll repeat myself: let's have an anti-spam BOF and hopefully and 
anti-spam wg. First order of business for this wg: analyze the spam 
problem and then see if mechanisms can be found to reduce the amount of 
spam by 1 - 2 orders of magnitude. After that, we can decide if it's 
worth it to write a protocol and try to have it deployed.

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 1 Jun 2003 15:48:43 -0600 (MDT)

> From: Iljitsch van Beijnum <[email-masked]>

> ...
> So I'll repeat myself: let's have an anti-spam BOF 

Face to face talk is likely to be of even lower quality than this
thread.  With email with a broad audience like this, people can
squelch obvious nonsense with data or pointers to real data and
independent reports.
(e.g. http://www.google.com/search?q=spammer+%22dictionary+attack%22 )

BOFs are transient committees and so are even worse than most committees
for creating things.  All you might do in a BOF is discover whether
anyone is interested is dealing with spam.

>                                                    and hopefully and 

That sounds more like research than protocol documentation and
standardization.  Why have you rejected the repeated pointers to
the IRTF/IETF ASRG research group?  In case you didn't intend to
reject them but just missed them, please consider:

 http://irtf.org/
 http://irtf.org/groups.html
 http://irtf.org/charters/asrg.html
 https://www1.ietf.org/mail-archive/working-groups/asrg/current/maillist.html

or

 http://www.google.com/search?q=%22Major+Internet+Standards%22+spam

Vernon Schryver    [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 2 Jun 2003 00:42:12 +0200

On zondag, jun 1, 2003, at 23:48 Europe/Amsterdam, Vernon Schryver 

> thread.

But aren't you supposed to have a BOF first before you can have a wg?

> anyone is interested is dealing with spam.

Seems a worthwhile thing to do, although better results than just an 
answer to that question wouldn't be a bad thing.

> the IRTF/IETF ASRG research group?

Because I'm not interested in researching the problem; I'm interested 
in solving the problem. (I've been doing "spam research" for several 
minutes a day for many years now.) I believe the IETF is capable of 
creating new protocols that would move the spam problem from something 
that is completely out of control to something that is easily 
manageable. If this turns out impossible after all, documenting why 
would be a very good thing. Then the researchers can have another go at 
it.

> In case you didn't intend to

I'll look over the mail archives when I have some time.

---

From: Spencer Dawkins <[email-masked]>
Date: Sun, 1 Jun 2003 18:39:30 -0700 (PDT)

My comment below is offered honestly (unlike the snippy comments
I posted earlier today)...

--- Iljitsch van Beijnum <[email-masked]> wrote:
> >>                                                    and
> hopefully and
> >> problem and then see if mechanisms can be found to reduce
> the amount 
> >> of

If you (not just Iljitsch, but anyone else as well) care AT ALL
about dealing with spam via protocols in your lifetime, you
really SHOULD be following the ASRG in IRTF. I've been somewhat
disoriented because we've been discussing an SMTP replacement in
the IETF while the ASRG in IRTF has been heavily focused on
mechanisms that work within an SMTP framework - seems backwards
to ME, but that's the way it's working.

ASRG isn't perfect, but the signal-to-noise ratio is a lot
higher, the "research" focus is a lot nearer-term than some of
the other IETF RGs, and it does have the advantage that
discussion of spam is ON TOPIC for that list. Vern Paxson may
hunt me down in Vienna for diverting traffic to ASRG, but ASRG
really DOES look like a place where something MIGHT happen.

As distinct from the IETG main discussion list. Oh, my bad, I'm
back to snippy again...

Spencer Dawkins

p.s. Anyone CAN request a BoF, you know. And I would think that
ASRG would be a reasonable place to look for accomplices for a
BoF, and for an eventual IETF WG. I'm not the Genius of IETF
Processes, but I have done two BoFs - if you still have
questions after reading
http://www.ietf.org/ietf/1bof-procedures.txt, please contact me
via private e-mail and I'd be glad to help.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 2 Jun 2003 14:15:03 -0700

> worth it to write a protocol and try to have it deployed.

I agree with the idea of a BOF, but 'anti-spam' is the wrong focus. Spam
is a social problem, not an engineering one. I contend that is why we
already have a research group dealing with it (social problems are
inherently difficult for engineers, thus requiring research to figure
out). Focus the group on a tangible engineering problem, deployable
authenticated email. Or as Vixie labeled the more generic, interpersonal
batch communication system. 

Tony

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 02 Jun 2003 17:19:17 -0500

> batch communication system. 

I agree that this is the right approach to pursue. In fact, I think we
could probably skip the BoF and start talking about that particular topic
immediately ("secure mail", not "anti-spam technologies", which is an
interesting research topic but is a dead-end outside negotiated usage
domains). All we probably need to get started is a mailing list, if
anybody feels like setting one up.

I would also _still_ like to see the I*** leadership fill the necessary
jurisdictional roles of liason, so that the current and future technical
mechanisms can be presented as hooks for the anti-spam legislation that is
needed to actually solve the social problem of spam.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Keith Moore <[email-masked]>
Date: Mon, 2 Jun 2003 18:35:44 -0400

> is a social problem, not an engineering one. 

If by "social problem" you mean that it is a problem that results from human
behavior, like lack of a widespread social contract or failure to adhere to a
social contract for how to use email, I might agree.  But applying that term
doesn't help much.  Nor should it be taken to imply that there is not a
technical solution, or part of a solution, to the problem.  Traffic signals,
speed measuring radar, lojack, airport metal detectors, turnstiles, locks on
doors, and alarm systems are all technical approaches to social problems. 

Clearly, a lot of spam can be eliminated via technical mechanisms.  Social
and/or legal mechanisms might also help especially if they have technical
mechanisms to back make them more feasible (e.g. by making senders tracable
with less effort, and perhaps, by reducing the number of complaints that have
to be investigated).  Technical, social, and legal mechanisms all have
disadvantages and costs.  Often addressing a problem with a combination of
mechanisms yields a more acceptable solution than insisting on a single kind
of mechanism. 

> I contend that is why we

If we are trying to solve the spam problem, we'll be disappointed if
'deployable authenticated mail' or 'interpersonal batch communication system'
doesn't solve that problem.   And as far as I can tell, neither one will.  We
need to understand the benefits and limitations of these approaches before we
invest a lot of work into them. 

What users seem to want is to be able to accept mail from anyone without much
or any sender-specific prior arrangement (because we want to avoid the hassles
of making such arrangements, and because sometimes it really is useful to get
mail from people we don't know yet), to send mail for free or extremely low
cost, and to not have our mailboxes cluttered up with messages we don't want
to see (or for that matter, viruses).  There are a lot of other constraints,
but these are the big ones.  It may not be possible to completely satisfy this
set of constraints, but it might be that a slightly different set of
constraints would be acceptable.  It might also be that different constraints
(with different results) are acceptable to different people.

---

From: David Morris <[email-masked]>
Date: Mon, 2 Jun 2003 16:04:12 -0700 (PDT)

...

> immediately ("secure mail", not "anti-spam technologies", which is an

Anti-spam may be a tar baby and there is a demonstrated lack of ability on
the part of the recent participants in this discussion to even agree that
Spam is a serious problem, BUT without the mantra of being able to
evaluate all technology proposals in terms of how the proposal will help
reduce unsolicited bulk mail, the effort isn't worth pursuing.

Unless the result can be demonstrated to provide features which directly
reduce the ability of the spammers to send mail, Dave Crocker's prediction
of slow/non deployment will come to pass.

There will also be (a lot?) less interest in working on the protocols.

Dave Morris

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Jun 2003 18:14:02 -0700

Tony,

TH> I agree with the idea of a BOF, but 'anti-spam' is the wrong focus. Spam
TH> is a social problem, not an engineering one. I contend that is why we
TH> already have a research group dealing with it (social problems are
TH> inherently difficult for engineers, thus requiring research to figure
TH> out). Focus the group on a tangible engineering problem, deployable
TH> authenticated email. Or as Vixie labeled the more generic, interpersonal
TH> batch communication system. 

The example of theft vs. locks provides a good perspective on both the
truth of your observation and the necessity that we take (appropriate)
action.

The key insight that comes from saying "social problem" is not that we
should do nothing, but that we need to have a shared agreement on the
details of the problem and the level of protection required.  And we
need to respond to it with appropriate, but limited, changes.

We are all quite comfortable making a distinction between the protection
needed for a home vs. protection for a facility holding a nuclear bomb.
We even are reasonably comfortable distinguishing what is needed for a
home in a idyllic "safe" environment versus one in a strife-torn
hell-hole.

No one believes that a house lock keeps out all intruders, and indeed
some do get in. But we *do* believe that house locks reduce the threat
to a socially acceptable level.

We have no such clarity or consensus about spam.

Worse, we *all* are seriously ignorant about solutions. Anyone who says
that they know the magic fix is blowing smoke.

First of all, there is not yet any existence proof for the reduction of
spam. Some interventions have reduced some aspects of spam, but the
total size of the beast has only been growing, and rapidly. There is a
key lesson here and it is mostly missed. The lesson is that spammers are
adaptable and -- as is true for all security threats -- raising the bar
keeps out the riff-raff but the truly serious attackers will develop a
different technique. In the case of spam, those serious attackers have
disproportionate leverage, because their software can be used by
less-serious drones.

More importantly, by saying "social problem" we are correctly implying
social *complexity*. Messaging touches core aspects of social processes.

No one knows how to "engineer" one property of a complex social process
without accidentally impacting others. And they key import of the word
"accidentally" is that these unintended consequences are typically
undesired.

This does not mean we should do nothing. Nor does it mean that there
should be no technical interventions.

It *does* mean that we need to treat this as an incremental systems
change process.

It *does* mean that we will need multiple types of changes, not just one
cure-all.

It *does* mean that we should approach those changes very cautiously,
even experimentally.

The place to start is with a modest, objective, operationalizable
definition of the thing we all agree needs to be handled differently.
So, let's not worry about the all-encompassing definition of spam. Let's
just -- hah! "just" he said -- target a single type of spam that is
massive and is massively offensive.

My personal favorite definition, these days, is

   Unsolicited Bulk Mail (UBE)
   
("Commercial" is too constrained, for me. I do not care whether the
message asks me for money, my vote, my religious affiliation, or simply
wants to share a bit of personal silliness with me.  In other words, the
detail of the content is irrelevant to me.  It does not even need to be
soliciting.)

Not all unsolicited mail is bad.  Not all bulk mail is bad.  But the
combination is universally reviled.

So we then need to define unsolicited properly. We must make sure to
permit me to make contact with someone for the first time. Not all cold
calls are bad; in fact they are essential to many desirable aspects of
social intercourse. We need to make sure that we define "permission"
properly -- as a kind of opposite to unsolicited -- and so we can then
enjoy wonderful debates about details such as double opt-in. And so on.
Still, I think the question of "unsolicited" is well-enough understood
to make it possible to get community rough consensus on a technical
definition that the engineering community can work with.

And we need to define bulk properly. This will be difficult. If I send
an unsolicited message to 2 people, does it qualify? What about 10
people, 100, 1000? Why? Why not?

The problem, here, is that I believe the qualifier "bulk" captures an
essential aspect of the problematic mail, so we can't simply drop the
term or say "anything greater than one".  Worse, the instant we choose a
number, the spammers will simply send batches that are one addressee
fewer than that maximum.

For that matter, the number of addressees per message might not be a
useful attribute, as marketeers have become good at tailoring content to
individual recipients, thereby producing one addressee per message. So
"bulk" requires considering behavior across multiple postings. Oh boy...

And that's why this is a research topic, no matter how essential it is
to to engineer some mechanisms sooner rather than latter. Let's do the
engineering and deployment, and let's do it quickly, but let's
appreciate that it is really research.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Jun 2003 11:16:41 +0200

On dinsdag, jun 3, 2003, at 03:14 Europe/Amsterdam, Dave Crocker wrote:

> TH> is a social problem, not an engineering one.

Ok, maybe the word "spam" is too overloaded to be useful in a technical 
discussion. However, it's always good to keep the customer experience 
in mind, and the customer experience is "I don't want all this spam".

> TH> Focus the group on a tangible engineering problem, deployable

Just adding authentication only solves a very small part of the 
problem: we can then accurately whitelist known senders.

A new interpersonal batch communication system certainly sounds like a 
good idea. The problem with email is that it is incredibly ill-suited 
for transferring larger files. A new protocol should be able to do much 
better in this area. However, this doesn't have much to do with spam 
issues and might make the whole thing much more complex.

> to a socially acceptable level.

The trouble is that on the internet, you can go from house to house and 
try to break locks and nobody will stop you. In the real world, you 
wouldn't be able to do that for very long.

> total size of the beast has only been growing, and rapidly.

Which is kind of ironic because spammers are thereby creating their own 
tragedy of the commons. Spam is so much out of control that any 
individual spam isn't going to have much of a return, so they need to 
send out even more of it. And the volume of spam is becoming so painful 
that people are now seriously working at getting rid of spam. So far 
with limited success, but that will change one way or the other.

> There is a
> adaptable

So let's show some adaptability of our own and plug those SMTP holes.

> combination is universally reviled.

Completely agree.

> permit me to make contact with someone for the first time.

One way would be solicited == whitelisted. Remember that this is only 
necessary for bulk mail. So everyone would need to create a whitelist 
of all the mailinglists and newsletters they're subscribed to.

> people, 100, 1000? Why? Why not?

Why look at individual messages? How much non-bulk mail can someone 
possibly need to send? 10 messages per hour? 100? 1000?

> number, the spammers will simply send batches that are one addressee

That's why it's important to look at ALL mail rather than just copies 
of one message. Spammers by now know how to make messages look 
different even though they're essentially identical.

Someone's "home MTA" sould be able to simply rate limit the number of 
messages an individual user gets to inject into the global email 
distribution system. Then all we need is a system to differentiate 
between trusted MTAs and rogue ones run by spammers.

> appreciate that it is really research.

I'm not convinced.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 3 Jun 2003 12:29:57 +0200

Iljitsch writes:

> The trouble is that on the internet, you can go
> from house to house and try to break locks and
> nobody will stop you. In the real world, you

Sure you could.  But locks break so easily in the real world that most
crooks don't have to bother.

> Spam is so much out of control that any individual
> spam isn't going to have much of a return, so they
> need to send out even more of it.

Since the cost of sending spam is negligeable, sending ten or fifteen
million more isn't likely to be much of a deterrent.

> So let's show some adaptability of our own and

Why does SMTP have "holes"?  It does what it is supposed to.  There isn't
any way to automatically recognize spam, since it looks just like any other
e-mail to a computer.

> Someone's "home MTA" sould be able to simply rate
> limit the number of messages an individual user gets
> to inject into the global email distribution system.

This assumes that the home MTA has an objective of limiting outgoing spam.
But ISPs used by spammers aren't likely to care what they send out, as long
as they pay their bills.

---

From: Dave Aronson <[email-masked]>
Date: Tue, 3 Jun 2003 10:55:44 -0400

Iljitsch van Beijnum <[email-masked]> wrote:

 > The trouble is that on the internet, you can go from house to house
 > and try to break locks and nobody will stop you.

Actually, sometimes they will, or at least try to.  Port scans can be 
detected, both inbound and out, and Things Can Be Done....

-- 
David J. Aronson, Unemployed Software Engineer near Washington DC
See http://destined.to/program/ for online resume, and other info

---

From: Dave Aronson <[email-masked]>
Date: Tue, 3 Jun 2003 10:56:54 -0400

Iljitsch van Beijnum <[email-masked]> wrote:

 > Someone's "home MTA" sould be able to simply rate limit the number
 > of messages an individual user gets to inject into the global email

Then we're back to Square One (okay, maybe Three) with blacklists and 
whitelists.  Not that throttling is itself a bad thing... I'd like to 
throttle some spammers....  ;->

---

From: Dave Aronson <[email-masked]>
Date: Tue, 3 Jun 2003 11:07:08 -0400

> of all the mailinglists and newsletters they're subscribed to.

This could be eased somewhat with something I was trying to get at 
earlier.  This is separate from the idea of fixing or replacing SMTP, or 
other spamfighting, but what I envision is some standard format of data 
about a mailing list.  (MLML, for Mailing List Markup Language?)  Upon 
reading this in an email or on the web, the user can take some sort of 
action (click, reply, etc.), whereby he would be subscribed, and his MUA 
would whitelist the address the email would come from (or some other 
such tag, but usually the From addy so as to enable PGP-type 
authentication).  Something like:

<mailingList
 title="Dave's Demented Droppings"
 name="ddd"
 host="lists.example.com"
 whitelistHeader="X-Drivel"
 whitelistData="Two guys walk into a bar. A third one, ducks."
 My mailing list of occasional jokes, stories, and other alleged humor.
</mailingList>

Ideally, this would set off a confirmation process.  This introduces the 
possibility of whitelisting the addy that the confirmation request will 
come from, but if we establish a standard for transforming the listname 
and host to the various admin addies needed, those can be made optional.  
For instance, in the example above, I could have added 
owner="[email-masked]", confirm="[email-masked]", 
or both, or let them default to [email-masked] and 
[email-masked].  Similarly, there could be explicit or 
implicit URLs for subscription control (defaulting to something like 
"http://www.lists.example.com/ddd-control/", and including possibly that 
there are none for this list), and a standardized set of commands usable 
via email, and possibly a standard set of web-based controls.

Of course, we would quickly see spam in this format, but that's a whole 
different question.

A brief google doesn't turn up anything obviously relevant; anybody know 
of any work having been done in this area?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 3 Jun 2003 18:06:19 +0200

Ok, my last message on the subject on this list (at least for a while).

> whitelists.

Obviously black/whitelisting the MTAs you know is a good start. The 
challenge is doing something useful when you first encounter a new MTA. 
This can be done by asking such an unknown MTA to present a certificate 
that is signed by one or more people or organizations you trust.

This will make getting a new bona fide MTA up and running more 
difficult than it is now, but not to an unreasonable degree, IMO. 
Spammers on the other hand, will be unable to grab an address and start 
spamming immediately: they'll have to trick someone into validating 
their MTA. I'm sure they'll succeed in this from time to time, but not 
all the time, or people will simply ignore the naive validator. This 
should work especially well if validation depends on some real-life 
info: having to get a new (street) address or drivers license to be 
able to do a spam run should have a nice discouraging effect.

---

From: [email-masked]
Date: Tue, 03 Jun 2003 12:27:41 -0400

> able to do a spam run should have a nice discouraging effect.

Street address validated how?  It's the rare ISP that double-checks an account
by snail-mailing information or calling the listed user's telephone number to
confirm.  Not that it would be a bad thing if all ISP's did this, but all
it takes is a few that don't, and the scheme falls apart...

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 03 Jun 2003 10:56:56 -0500

on 6/3/2003 10:07 AM Dave Aronson wrote:
>> necessary for bulk mail. So everyone would need to create a
>> whitelist of all the mailinglists and newsletters they're subscribed
>> to.
> 
> earlier.  This is separate from the idea of fixing or replacing SMTP,
> or other spamfighting, but what I envision is some standard format of
> data about a mailing list.  (MLML, for Mailing List Markup Language?)
> Upon reading this in an email or on the web, the user can take some
> sort of action (click, reply, etc.), whereby he would be subscribed,
> and his MUA would whitelist the address the email would come from (or
> some other such tag, but usually the From addy so as to enable PGP-type

First point is that whitelisting should be one of the optional "locks"
which are enabled by architecture, rather than being core features of any
service. Whitelists don't work for everybody (customer service desks, for
example) so they need to be optional, and there are probably going to be a
variety of whitelisting "applications" (such as what you describe in your
detail) that embedding any of them would make it difficult to develop
alternative whitelisting applications.

For these kinds of reasons, it would be best to provide architecture (in
particular, providing authenticated identity and end-to-end option
encapsulation), and then people could use whatever mechanisms they want
(including hashcash, e-postage, whitelist negotiation, whatever) within
their own administrative space according to whatever works for them.

Whitelisting and mailing-list automation services would be two different
applications, I think, although they should be able to communicate with
each other for the kind of reasons you cite.

Anyway, the overall point is that we should separate the applications from
the message-transfer network architecture and develop them in parallel,
making sure that the architecture can provide what the applications need
for successful deployment.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 3 Jun 2003 17:54:09 -0700

> problem: we can then accurately whitelist known senders.

Two points:
1) besides white listing, the approach also provides irrefutable
evidence to law enforcement about spam sources.
2) it is clear from the related threads that many would rather continue
the lively exchange debating nirvana, rather than tackle the small parts
of the problem that are technically achievable.

> issues and might make the whole thing much more complex.

We can always make it more complex than necessary, but it is pointless
to compare the complexity of a new system that does the job with a
system that is proven to be open to abuse. 

> wouldn't be able to do that for very long.

Adopt draft-hain-ipv6-pi* as the standard addressing plan, provide
automated intrusion detection reporting, and Internet prowlers wouldn't
be able to attack for very long either.

> So let's show some adaptability of our own and plug those SMTP holes.

Or simply leave SMTP to the spammers and move on.

> possibly need to send? 10 messages per hour? 100? 1000?

@ 5kB/message on a 10MB/sec link, 2k/sec. 

> different even though they're essentially identical.

Exactly how would you coorelate email across multiple accounts, on
multiple service providers?

> between trusted MTAs and rogue ones run by spammers.

Why would a spammer limit themselves to a single MTA, or account. Run
VMware on a laptop, and there could easliy be 10 parallel rate-limited
sessions going on. If the rates are low enough, each virtual system
could automatically log into another account on another MTA, then come
back when the timer goes off. 

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 3 Jun 2003 17:54:09 -0700

Dave Crocker wrote:
> ...
> This does not mean we should do nothing. Nor does it mean 
> that there should be no technical interventions.
> 
> It *does* mean that we need to treat this as an incremental 
> systems change process.
> 
> It *does* mean that we will need multiple types of changes, 
> not just one cure-all.
> 
> It *does* mean that we should approach those changes very 
> cautiously, even experimentally.

I am with you up to here, with the comment that any modification to
production services need to be approached incrementally, but new
services can be radical as long as they are deployed in parallel. 

> 
> The place to start is with a modest, objective, 
> operationalizable definition of the thing we all agree needs 
> to be handled differently. 

We agree with the wording of this, but it looks like at this point we
disagree about what should be changed.

> So, let's not worry about the 
> all-encompassing definition of spam. 
> ... 
> In other words, the detail of the content 
> is irrelevant to me.  It does not even need to be
> soliciting.)
> 

I agree completely with these points.

At this point your thoughts appear to drop into the trap of trying to
engineer a solution to the social problem, even though earlier you noted
we don't know how to engineer solutions to complex social problems. 

> ...
> For that matter, the number of addressees per message might 
> not be a useful attribute, as marketeers have become good at 
> tailoring content to individual recipients, thereby producing 
> one addressee per message. So "bulk" requires considering 
> behavior across multiple postings. Oh boy...

And if they spread the individual messages across multiple relays, using
multiple accounts, there is no chance to correlate postings. This shows
that even by your own account of ignoring content, there is no technical
way to stop even the simple case of unsolicited bulk mail. 

> 
> And that's why this is a research topic, no matter how 
> essential it is to to engineer some mechanisms sooner rather 
> than latter. Let's do the engineering and deployment, and 
> let's do it quickly, but let's appreciate that it is really research.

We agree that engineering automated solutions to social problems is a
research topic, and the IETF is not the place to do that work.
Engineering tools that are useful to existing social management agencies
is not research and something that the IETF can take on. Deployment of
experimental technologies is necessary, and something that should begin
ASAP. IMHO where we need to start is agreeing that the greater goal is
reduction of spam, that we don't know of any way to automate the
identification of billions of independent individual value decisions,
that trying to do so at this point is a waste of time, and that existing
social management agencies need tools to deal with the issue. 

I would like to see the outcome of a bof be identification of an
approach to globally verifiable authenticated email. I have no doubt
there will be many gaps in our current tool set (starting with a
deployable PKI), and a truck load of operational guidelines to develop.
This is something tangible we can do without extended research. If the
research community comes up with a breakthrough and figures out another
way to kill off spammers, authenticated email will still be useful as a
replacement for the current legal requirements for fax.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 4 Jun 2003 09:40:03 +0200

(I really wanted to stop this thread with my previous message, but...)

> evidence to law enforcement about spam sources.

Ok, there's some value in that if we build a good key infrastructure. 
Wouldn't say "irrefutable" even then, though.

What I meant to say: we need more than authentication.

> system that is proven to be open to abuse.

SMTP shouldn't be used to transfer binary files. It leads to all kinds 
of problems: clogged mailboxes, wasted bandwidth (base64, aargghh!), 
you name it. A better batch interpersonal communication system would be 
able to send the message, but then negotiate what to do with the 
attachment. From some people you may want to always immediately receive 
the attachment, from others you may want to read the message first and 
then decide whether to inititate the transfer of the attachment.

This would be very cool except that it breaks current email systems at 
a fairly fundamental level. Adding authentication on the other hand, 
can be done in a way that may not be compatible with current ESTMP, but 
it does (or at least: could) fit into the current email architecture 
without too much trouble.

> be able to attack for very long either.

Only if someone cares enough to go to the place where the prowler 
deploys his activities. There was a time when this was a reasonable 
assumption; but this time is now in the past.

> Or simply leave SMTP to the spammers and move on.

Fine by me.

> @ 5kB/message on a 10MB/sec link, 2k/sec.

And how exactly would those messages be "non-bulk"? I mean, I type 
fast, but even then it takes a second or so to even find the recipients 
for a message.

> multiple service providers?

We push this back to the source MTA. Then if the source MTA does a bad 
job, we revoke the MTA's "not-a-spammer" accreditation so only messages 
with whitelisted senders can get through.

Alternatively, we can build a serial number system. An MTA must then 
add a serial number that starts from 0 every day or every week to every 
message. This way everyone who receives a message from this MTA knows 
how many messages the MTA has already transmitted this period. 
Obviously spammers will fake the serial number so we also build a 
system that makes it possible to check if a serial number wasn't used 
more than once afterwards.

This shouldn't be much of a problem for spammers if they can set up a 
new MTA in five minutes, but if they (for instance) have to get three 
people in good standing to sign the new MTA's key in order to be able 
to start a new spam run, then it gets more troublesome for them.

> back when the timer goes off.

At a limit of 1000 messages per hour per account, they need 10000 
account-hours to send out 10 million spam messages. Assuming it takes 
64 hours (on the weekend) to get an account yanked for spamming that's 
160 accounts. This is a good start. Add some additional stuff such as 
limiting the number of messages per hour based on the number of bounces 
received and we should have something that's pretty effective.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 7 Jun 2003 07:28:12 -0700

Tony,

TH> I would like to see the outcome of a bof be identification of an
TH> approach to globally verifiable authenticated email. I have no doubt
TH> there will be many gaps in our current tool set (starting with a
TH> deployable PKI), and a truck load of operational guidelines to develop.

What is wrong with PGP and/or S/MIME?

How do they fail to provide 'globally verifiable authenticated mail?"

How would something else be different?

Given 10 years of public key authenticated mail, why would something new
succeed?

d/

---

From: Paul Vixie <[email-masked]>
Date: 07 Jun 2003 18:36:32 +0000

> What is wrong with PGP and/or S/MIME?

both are unusable by average nontechnical personnel.  not just the daily
use but the initial setup and anything out of the ordinary requires too
much expertise, by far, for many of my current e-mail correspondants to
use.

both rely on nonpermuting gateways and forwarders.  as long as microsoft
outlook strips e-mail addresses out of forwarded e-mail, we're screwed.
as long as line wrapping, mime stripping/mangling, ascii->ebcdic->ascii
translations, and other foul arts are present in the world, neither s/mime
nor pgp can reach a wide enough population to create "the network effect"
whereby either one of them becomes useful, on average, to me or to others
who want them to be useful on average.

s/mime relies on the x.509 pks industry which in is turn based on the goal
of enriching a small number of ca's who have to pay for relationships to
browser/useragent vendors who then make the certs worthwhile.  that can't
scale and hasn't scaled, other than in the case of server certs.  no way
will the average user be willing to pay money for a personal cert signing
if the companies on the list have all spammed them.

> How do they fail to provide 'globally verifiable authenticated mail?"

by appealing only to small communities, they have never created enough
benefit for anyone, anywhere, ever, to be willing to say "if inbound mail
was not signed, just drop it, don't even store it in my inbox" which is
a slightly different question but more apropos to the issue of consensuality.

> How would something else be different?

by starting from the assumption that all successul communications must be
provably consensual, and by making the network agent (think "listening mta")
synchronous with user agent policy ("i don't want mail that isn't provably
beneficial to me, based on the sender's identity, on the trust path from
them to me, and on their authentic promises that this communication does not
have assymmetric benefit to the sender"), and by planning for universal
scalability (no way for thawte or verisign or even rsadsi to get monopoly
economic power or results from it).

> Given 10 years of public key authenticated mail, why would something new

because everything designed or deployed to date has been done by engineers
for engineers.  because this will be made to fit the full spectrum of the
global community, including those at the low end who want assymetric
benefit from nonconsensual communications, and those at the high end who
can't cope with mangled encodings or key rings or signatures.

because (e)smtp has run its course and its model (data model, security
model, you name the model) is bankrupt.  because holding onto it like it
was salvageable if only we could find a vaccine for the plague of spam
has limited the ambitions of all who have tread this path to date.

because the position of "trust broker" cannot be a tiered monopoly in a
system that has to have global scale, and the only people who can think
their way that far out of the loop think that "key signing parties" are
a reasonable alternative.

--------

nevertheless you are still asking the wrong questions and i almost feel bad
for trying (above) to answer them.  don't ask "is this really necessary?" or
"why do we have to discard the current system?" but rather "how long will
the world population tolerate current and increasing levels of mangled or
nonconsensual communication?" and also "who will develop technology to meet
this gaping and obvious need?"

(i don't hold out much hope that ietf will do it, now that i think harder;
the current mix of scientists and vendors and loudmouths aren't sensitive
to the needs or aware of the nature of the broader spectrum of humanity
outside themselves and their current customers.  damn.  i guess i'm wasting
my time and yours on these rants.)
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 07 Jun 2003 18:40:56 +0000

> deployable PKI), and a truck load of operational guidelines to develop.

"globally verifiable" isn't a useful condition.  "universally consensual"
is what the market is demanding.  don't make people pay in bandwidth to
receive noncredentialled traffic.  don't let there be a mix of credentialled
and noncredentialled traffic that a user has to spend a percentage of their
lifetime sorting.  if traffic isn't provably desireable by the recipient
then it ought not be transmittable.  if that proof turns out to be based on
false data then the trust path (possibly including one or more trust brokers)
should be poisoned against future falsity.

and in this bof, i suggest that gateways to the current system be shat upon
and never again considered.  when we move, we'll MOVE.
-- 
Paul Vixie

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 07 Jun 2003 14:28:56 -0500

on 6/7/2003 1:40 PM Paul Vixie wrote:

> and in this bof, i suggest that gateways to the current system be shat
> upon and never again considered.  when we move, we'll MOVE.

That's not globally-applicable. Probably better to specify the gateway
tagging, and then ~Paul can reject mail that has the markers, while ~Sales
can devalue mail with those markers in their post-transfer filters.

---

From: Daniel Senie <[email-masked]>
Date: Sat, 07 Jun 2003 16:06:18 -0400

>can devalue mail with those markers in their post-transfer filters.

Indeed, some level of gatewaying will likely be necessary for transition, 
and to accomodate intra-company use of embedded devices which transmit 
email alerts (e.g. UPSs, NAS boxes, etc.).

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 7 Jun 2003 14:41:31 -0600 (MDT)

> From: Paul Vixie <[email-masked]>

> this gaping and obvious need?"

A contrary view that we have seen the crest of the flood of spam
can be argued:

  - spam filtering is a major selling point for all major ISPs,

  - the mass media is talking about spam filtering and spam, with ever
     decreasing sympathy for the "ethikal biznezmen" who are harmed by
     various anti-spam mechanisms, decreasing talk about evil, nasty
     vigilantes, and increasing sympathy for even abusive spam defenses.

  - there are some amazing legal attacks going on.  See for example
     "Legislators Call for Fix to Law Against Unsolicited E-Mails" in
     http://online.wsj.com/article/0,,SB105484626839598400,00.html
     (may require a subscription)

  - the DMA is getting its fingers squashed in some state do-not-call
     lists and the continuing federal DNC evolution.  See
	http://www.the-dma.org/cgi/disppressrelease?article=444
	http://www.the-dma.org/government/donotcalllists.shtml

  - since the start of the recent series of legal attacks on the worst
      spammers, I've seen a possible leveling off in the total number of
      streams of spam in the system.  The bend in the curve on 
      http://www.dcc-servers.net/dcc/graphs/db-size 
      coincident with the announcement of some legal attacks on spam
      might be an artifact or it might be real.

All of those could be coincidences or illusions, but all of them were
either conceivable or silly jokes 12 months ago.  It is possible that
people have had enough and aren't going to take it any more, much as
people in neighborhoods in some cities in Iraq reportedly decided
enough lawlessness was enough and took steps to control it.

Extrapolating from peaks of lawlessness in Iraq, the Balkans, Lebanon,
and elsewhere implies that the old system of a few, easily broken
locks and a few lightly armed police must be replaced with a full-up
prison state.  However, the local residents eventually decide to deal
with the worst problem makers one way (e.g. vigilantes) or another
(e.g. cooperating with old or external/U.N. civil authorities) and
the apparent need for extreme measures ebbs.  Sometimes, it takes
years for the residents to decide and overcome the problems including
external pressures, but eventually things get better and the old system
prevails.

In other words, Paul, are you sure you're not calling for an ashcroft?

Personally I'm equally convinced of the validity of both Paul's and
the view above.  I'm not convinced either is all or even most of the truth.

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 7 Jun 2003 13:57:31 -0700 (PDT)

Disclaimer: there are people who know more about e-mail than I
do, and some of them are on this list. But, to press on.

Ummm, I'm wondering... in my own naive way.

My memories of mail gateways involved SMTP-to-non-SMTP mail
gateways, and the ones I hung around existed because one network
didn't speak SMTP. I can't imagine that there's a meaningful
mail system deployed today that doesn't speak SMTP (even if it's
through a gateway).

Why wouldn't we have mail sending applications that spoke (I'm
making this up) SMTP and MT2, with different URL schemes
(mailto: for SMTP, mailtoauth: for MT2) associated with our
correspondents, let correspondents advertise both ways of being
reached on Vcards, etc., and not worry about gateways?

The idea would be that after I get my friends trained that they
can send me mail at mailtoauth:[email-masked], and get
subscribed to my mailing lists with this address, I could move
away from mailto:[email-masked] on my own schedule. If I
hope I never miss an unsolicited e-mail (from my high school
reunion group, for example), I might never move away. If I get
tired of looking at UBE in languages I don't have the privilege
of understanding, I might move away more quickly. But waiting
for the deployment of a gateway infrastructure wouldn't affect
my timeline, either way.

I know this is the dual-stack IPv6 migration strategy two
protocol stack levels higher - would that make any difference?

He asked naively, hoping that an MT2-to-SMTP gateway wouldn't be
necessary... isn't a lot of our mail munging the result of
gateways now?

Spencer

--- Daniel Senie <[email-masked]> wrote:
> _______________________________________________
> This message was passed through
> [email-masked], which is a sublist of
> [email-masked]. Not all messages are passed. Decisions on what
> to pass are made solely by Raffaele D'Albenzio.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 07 Jun 2003 16:45:26 -0500

> reached on Vcards, etc., and not worry about gateways?

Let's separate those concepts.

First, regarding the need for gateways, people will use them no matter
what we say, since there will always be people with mixed installations,
people who need mail from both networks (eg, sales and support), and so
forth. If we dont specify the gateway behavior, the only predictable
outcome is that people will build them without guidance. If we specify
that they cannot be made, people will still make them, and without
guidance. Clearly, the only workable strategy is to specify them, and to
do so in such a way that folks like Paul can reject mail that ever
travelled across a legacy network (that's going to be tough in toto,
considering that MUAs will probably be built to use SMTP as the first-hop
service for a very long time to come).

As for the use of an alternate URI, those are used to tell the viewer
which protocol to use. In the case of outbound mail, it would effectively
be a way for the message recipient to tell the message sender that they
have to use MT2 for the first-hop of the message, which doesn't make a lot
of sense outside closed environments. Furthermore, what happened to the
message after the first-hop would be a result of the mail-routing
information in between the first and last hops, and would not necessarily
be determined by the protocol that the sender used for the first-hop. So,
URIs can't really be used to control the delivery path.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 8 Jun 2003 00:38:41 +0200

> How do they fail to provide 'globally verifiable

Neither is universally supported.

---

From: Paul Vixie <[email-masked]>
Date: 07 Jun 2003 23:01:43 +0000

> >That's not globally-applicable.

yes, it is.

> >Probably better to specify the gateway tagging, ...

and we're going to convey trust and credence through a nontrusted system How?

> Indeed, some level of gatewaying will likely be necessary for transition, 

no, it's not.  i really mean it.

> email alerts (e.g. UPSs, NAS boxes, etc.).

let me explain what i mean, in case there's room for compromise.  ibcs will
have to be an end to end system.  there won't be MX RRs for RHS's, but 
rather SRV RRs for destinations -- almost exactly like SIP, i suspect.  so,
rather than the current logic of

        ($lhs, $rhs) = split /@/, $dest;
        @mxset = &lookup($rhs, 'MX');
        foreach $mx (sort { $a->prio <=> $b->prio } @mxset) {
                return 1 if &try($mx->host, 25);
        }
        return 0;

we'll see logic of the form

        (($srvname = $dest) ~= s/\./\\./go) ~= s/@/./;
        @ibcsset = &lookup("_ibcs._tcp.$srvname", 'SRV');
        foreach $srv (sort { $a->prio <=> $b->prio } @srvset) {
                return 1 if &try($srv->host, $srv->port);
        }
        return 0;

this means any destination needs a SRV RR.  instead of cracking [email-masked]
on the @ and looking for the MX RRset for vix.com, it'll get translated into
_ibcs._tcp.paul.vix.com and the SRV RRset will be used to find the possible
agents for this destination.

if smtp fallback is desired, it must be done in the sending user agent, who
upon not finding the SRV RR, could ask "try smtp instead?".  if there's a
NAT or firewall or gateway involved, then the submission protocol between
the user agent and local gateway has to have enough infowidth to express
these conditions and offer these choices.

the idea of an ibcs agent who nexthops through smtp is just right out, other
than because the user's own avatar decides to punch it through smtp to reach
a pager or something like that.

the idea of an smtp agent who can gain a sender's credentials in order to
make promises about mail that came from smtp and has to reach an ibcs
recipient is likewise nonsequitur.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 07 Jun 2003 23:14:33 +0000

> In other words, Paul, are you sure you're not calling for an ashcroft?

completely.  i have met the enemy, and i have also met the potential enemy,
and i know that recipient privacy is nowhere on anybody's mind.  consider
what would happen if the ITU ever finished its debate about e164.arpa and
there a few hundred million voip-reachable phones (either IP to the station
or IP to the central office and analog to the station).  all it would take
a telemarketer is a simple NAPTR/SRV sweep, with SYN-probe, to build a list
of tens of millions of reachable endpoints.  ten racks of linux PC's later,
we'd all be getting round the clock robotic calls from some telespamketer
with some viagra to sell.

i need ibcs to make it possible to keep doing what i used to do in e-mail,
but more importantly i need the "ashcroft" you speak of in order to gain
confidence about SIP callers, or instant messenger or SMS senders.  right
now the security people call this "the PKI problem" and calling it that is
exactly what makes it unsolvable.  i sweartagod the next time i meet an
ivorytowermathtype who wants to tell me how hard something is, i'm just
going to <do something unsavory>.  We Know How To Do This!  not only that,
but We Know What The Market Demands!

note that brokered anonymity will still be possible.  knowing someone's
identity means knowing that they are somebody in particular, and not 
necessarily knowing their meatspace-corredpondance identity.  i'd be one
of many people who would set my acceptance-filters to allow e-mail 
traffic based on transitive recourse toward a well-heeled trust broker
(who has much to lose if their clients misbehave), even if i might not
accept an e-commerce transaction from someone who didn't want me to know
their name and address in meatspace.

> Personally I'm equally convinced of the validity of both Paul's and the
> view above.  I'm not convinced either is all or even most of the truth.

i have faith in human nature.  if you build a world wide communications
system to make communications easier, It Will Be Used.  by the full
spectrum of humanity.  anybody who wants 10000:1 odds against this should
just gimme yer money right now, because it's not even a fair bet.
-- 
Paul Vixie

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 8 Jun 2003 02:04:52 +0200

Paul writes:

> if you build a world wide communications
> system to make communications easier, It
> Will Be Used.  by the full spectrum of humanity.

Then logically, the only way to exclude any part of that spectrum is to make
a communications system harder to use.  I'm not sure that making things
harder is a desirable goal.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 07 Jun 2003 19:49:56 -0500

> and we're going to convey trust and credence through a nontrusted

We can discover without question who the first MT2 system in the path was,
and (assuming that identity information is required, which I do) that
gateway will also have had to present identity information about the
sender. All rules, recommendations, and supportive integrity mechanisms
aside, those are going to be your primary actionable knobs.

Assume that somebody like AOL embraces this system for private transfers
with some other large-scale provider. They probably won't update all of
their submission services beforehand, but instead will just map their
existing authenticated submission services to this system. EG, they'll
see who a particular mail message is from, locate the appropriate user
certificate in their private directory, and feed that into the system.
This same model can hold true for private Exchange, GroupWise, or SMTP
AUTH submission services. All of these are examples of gateways that can
leverage authentication services to map a sender certificate, even if
those networks aren't running MT2 as the native service.

So the problem isn't with "gateways" it's with unauthenticated senders.
Simply put, messages won't make it to the next-hop inside the MT2 transfer
network UNLESS the gateway provides a user cert for the sender identity;
the next-hop would otherwise just reject the message.

Gateway rules (which weren't discussed in any of the above) can give you
more information to act on. For example, you can set your defenses higher
if you see remnants of more than one legacy Received header, or if there
are other characteristics you don't like. Obviously gateways are going to
be necessary, so it's really going to be a question of being able to apply
the right kind of heuristics.

> if smtp fallback is desired, it must be done in the sending user agent,
> who upon not finding the SRV RR, could ask "try smtp instead?".

Conversion in either direction could theoretically occur at any point.
What cannot easily happen is for any message to get past the first hop of
the MT2 network without having entered at a system which did not have
access to user credentials.

[not to Paul, who already gets it: On the subject of identity-tracking,
this subject is a non-starter. Folks can gather and use all of the
identities they want from any number of ISPs and mail services (you can
call yourself WonderWoman@yahoo and nobody will care as long as it
validates). This is, in the end, the same level of anonymity that is
available with SMTP today]

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 7 Jun 2003 18:53:00 -0600 (MDT)

> with some viagra to sell.

I can't see enough difference between that rhetoric and the doomsday
scenarios of anthrax in cropdusting airplanes, "dirty nuclear" bombs,
and the rest of the conceivable catastrophes that rationalize locking
us up in our homes in front network TV.

You can't and shouldn't even try to engineer perfect safety from all
conceivable disasters.  Before getting excited about such a
viagra-VoIP bomb, think the likelihood of the first bombing, whether
it could happen a second time after the perpetrators of the first were
drawn and quartered, and whether the costs (not just in money) of
preventing the first detonation are worthwhile.

> confidence about SIP callers, or instant messenger or SMS senders.  right

By an "ashcroft" I mean extremely costly (mostly not in money),
insufficiently or entirely unjustified, so called defenses against
potential disasters, where the defenses are of dubious or no real use
(e.g. the new airplane passenger screening) against the ostensible
potential disaster.

I don't understand enough of your notions to see whether I think it
would work or be worse than spam, but I have dark suspicions that they
would turn out like the new and forthcoming "defenses" against "terrorism"
(and "drugs," "child porn," etc.) from the U.S. DOD and DOJ.

Cassandra was right, but her proscription was only to send one woman
home to her lawful husband.

So how about turning down the heat a little and being more technically
specific about your replacement for the Internet?  Since that viagra-VoIP
bomb has nothing to do with SMTP, it seems you're talking about a far
bigger progject than "merely" replacing SMTP.

---

From: Paul Vixie <[email-masked]>
Date: 08 Jun 2003 01:46:59 +0000

> (e.g. the new airplane passenger screening) against the ostensible

ah.  then that's not what i'm advocating.  i want the digital equivilent
of a peephole in my front door so i can ignore the doorbell if i don't
like what i see.  

> I don't understand enough of your notions to see whether I think it would
> work or be worse than spam, but I have dark suspicions that they would
> turn out like the new and forthcoming "defenses" against "terrorism" (and
> "drugs," "child porn," etc.) from the U.S. DOD and DOJ.

i believe, and have always believed, that all communications ought to be
mutually consensual.  that philosophy underlaid my initial thoughts about
both MAPS and DCC, and is part of my motive for trying to get DNSSEC deployed.

plenty, no, *many* are the humans who can reach me by digital
communications for whom my consent is seen as irrelevant (or worse.)  my
son has been receiving pornographic spam for five years, and he just now
turned twelve years old.  did you all who contributed to the creation of
e-mail as a media believe that it should be "rated R, no children under the
age of 17 admitted without a parent"?  for my part, i did not.

or consider the "e-mail appending" data miners, who believe that my consent
to receive a magazine by postal mail somehow implies my consent to receive
anything else that publishing conglomerate wants to send me by e-mail.  (one
is sender-paid, the other is not, and my consent cannot be implied.)

due to accidents of fate, the CIX.NET MX RR points at my personal server.
it turns out that there are now many millions of valid @COX.NET mailboxes,
and that through normal error rates i receive several dozen misaddressed
messages per day, usually several of them being microsoft passport ACK's
containing enough information for me to commit identity theft if i so
desired.  a lot of the mail is quite personal in nature, too.  is this
how we thought e-mail would grow up and meet its larger audience?  not me!

the current system is utterly laughable and if it were proposed apriori
it would be laughed out of the room.  that which was suitable for polite
early adopters in the R&E community is completely unsuiable for the full
global population, And This Should Come As No Surprise To Anybody.

> bigger progject than "merely" replacing SMTP.

here's the problem.  if we had end-to-end personal certificates that were
widely deployed and universally presented, it would become reasonable to
try to wire an smtp listener to reject all but certified traffic -- but
since pornospammers could and would acquire signed certificates, we'd
have to do some kind of pgp-like kevinbacon-like "degrees of separation"
logic to find out about trust.

it turns out both of those are missing.  and creating them is a bigger
problem than rewiring smtp would be.  and that once they exist they will
have equal applicability to IM/ICQ/SIP/etc.

as usual, i would be happiest if someone else would take this on: i'm Busy.
however, that's not why i don't write a detailed proposal.  my goal at the
moment is to discover whether the ietf possesses a "collective will" and
if so, whether it is "willing" to take on this much larger problem.  so far
the answer seems to be not just "no" but "hell no!"
-- 
Paul Vixie

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 7 Jun 2003 22:07:44 -0600 (MDT)

> > specific about your replacement for the Internet?  ..

> the answer seems to be not just "no" but "hell no!"

Imagine if you will (since it's true), that I don't have any real idea
what you're talking about.  I understand only that you think that PKI
is hopelessly broken (golly gee, what a surprise) and that something
else easy and obvious (to you but not me) is The Solution.  Assume
(since it's also true) that I've lost track of the number of times
someone has announced Third/Forth/Fifth Generation Computing, Artificial
Intelligence, True Artificial Intelligence, For Sure This Time Really
True Artifical Intelligence, the Solution to the Von Neumann Bottleneck,
Real Computer Security, Really Real Computer and Network Security,
The Solution To Spam, and any and everthing else.  Many of those
announcements came from bright and sincere people who were only
overstating their points.

All I can see is the truth of your point that pornospammers could and
would acquire signed certificates, that each of us have a single digit
kevinbacon-like separation from any pornospammers, and that most of
us are closer to some pornospammer than to someone else we'd like to
hear from.

What do you expect me to do?  I won't answer your draft notice
"hell no I won't go!" but I'm not going to enlist until I have a
glimmer of where you're sailing and what's under the decks.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Sun, 8 Jun 2003 00:39:24 -0400

> How do they fail to provide 'globally verifiable authenticated mail?"

Again, I'd like to repeat my observation that we don't need to provide
"globally verifiable authenticated mail" in order to solve the SPAM
problem.  Given the notable lack of success in setting up a global PKI
after more than decade of trying, assuming that this is a prerequisite
for solving the SPAM problem is merely setting ourselves up for failure.

Bare keys will do; consider a system where people keep a list of those
keys that they will accept mail.  If someone tries to send mail and
their key is not on the recipient's list, the mail is returned to them
until they can perform a Hashcash calculation consuming a non-trivial
amount of CPU time, at which point their key is placed on the
recipient's list, and the sender can retry to send the message.  If a
recipient receives SPAM, they simply drop the key of the sender from
their "ok-to-receive" list.

This avoids the whole requirement of binding identities to names via a
global system that everyone trusts, and it avoids the problem of
determining who to trust regarding whether someone is or isn't a
spammer.

I'm sure this isn't the only way to do things, but I'm also sure this
is far more practical than any scheme that requires a global PKI.  

							- Ted

---

From: Paul Vixie <[email-masked]>
Date: 08 Jun 2003 07:23:21 +0000

> glimmer of where you're sailing and what's under the decks.

at this point I'm still looking for the answer to some simple questions.

1. does the ietf as a community generally believe that provable
   mutual consent between a sender and recipient is an achievable
   (technically) and desireable (by the global user base) goal?

2. if #1, does this same community believe #1 can be accomplished
   by means of negative pressure (bayesian, dcc, blackhole lists,
   hashcash, etc) on the current e-mail system (smtp, rfc822, mime)?

3. if !#2, then does this same community have any interest in being
   a creative, ambitious force that brings this functionality to
   the masses, or should this work be pursued independently/elsewhere?

there are other issues, like whether there has to be a flag day for e-mail
and whether gateways into/outof "old style e-mail" can exist, but frankly
those are details which won't matter (to this mailing list) if the answers
to the above continue to be "not really", "well probably" and "elsewhere"
as they have been since may 25 when i entered this thread.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: 08 Jun 2003 07:29:32 +0000

> their "ok-to-receive" list.

i think that we could write this up as open source and widely distribute
it and publicize the hell out of it for the rest of our careers without
ever having it become common practice to reject-with-explaination all
e-mail that comes from unauthorized senders.  therefore it can become,
at best, a system that radical and highly technical recipients can use.
we've got a number of those already.  (this one sounds new and better.)
-- 
Paul Vixie

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 8 Jun 2003 10:31:18 +0200

Paul writes:

> i want the digital equivilent of a peephole
> in my front door so i can ignore the doorbell
> if i don't like what i see.

One of the big problems of spam is that it takes up more than half the total
bandwidth used by e-mail.  If you want a peephole, then all spam must still
be delivered, so that you can examine it and reject it.  That may keep it
out of your mailbox, but the entire network is still being used to route and
deliver it, which seems wasteful.

> i believe, and have always believed, that all
> communications ought to be mutually consensual.

Most human communications do not involve any explicit consent.  They are
initiated by one party and accepted by another.  If a person refuses any
communication to which he has not consented, he spends his life alone.

> plenty, no, *many* are the humans who can reach me
> by digital communications for whom my consent is
> seen as irrelevant (or worse.)

The same is true for your telephone, your postal mailbox, your person on the
street, radio, television, and newspapers.

> my son has been receiving pornographic spam for
> five years, and he just now turned twelve years old.

Another 24 months or so and you may not be the only person examining it.

> did you all who contributed to the creation of
> e-mail as a media believe that it should be "rated R,
> no children under the age of 17 admitted without
> a parent"?

Children are not interested in porn, so spamming them with it isn't nearly
as harmful as their elders would like to believe.  Only adults care about
sex.

> or consider the "e-mail appending" data miners,
> who believe that my consent to receive a magazine
> by postal mail somehow implies my consent to receive
> anything else that publishing conglomerate wants
> to send me by e-mail.

That seems like a rational assumption.  Did you tell them otherwise?

> ... one is sender-paid, the other is not, and my
> consent cannot be implied.

Why not?

> due to accidents of fate, the CIX.NET MX RR points
> at my personal server.  it turns out that there are
> now many millions of valid @COX.NET mailboxes,
> and that through normal error rates i receive
> several dozen misaddressed messages per day, usually
> several of them being microsoft passport ACK's containing
> enough information for me to commit identity theft if i so
> desired.  a lot of the mail is quite personal in
> nature, too.

How do you know the e-mail is quite personal in nature, if you are just
discarding it without reading it?

> is this how we thought e-mail would grow up and meet
> its larger audience?  not me!

It seems pretty inevitable with the increasing use of e-mail, even if it was
not a design goal.

> the current system is utterly laughable and if it
> were proposed apriori it would be laughed out of the room.

No, the current e-mail system works admirably well.  I don't care much for
spam, but the advantages to receiving legitimate e-mail are so great that
I'm not about to sacrifice the latter to eliminate the former.

> ... that which was suitable for polite early adopters
> in the R&E community is completely unsuiable for the full
> global population ...

They why have they embraced it so willingly?

> if we had end-to-end personal certificates that were
> widely deployed and universally presented, it would
> become reasonable to try to wire an smtp listener to
> reject all but certified traffic ...

Maybe, but how would you reduce the bandwidth expended on spam, and the
processor time required to screen for it?

> ... but since pornospammers could and would acquire
> signed certificates, we'd have to do some kind of
> pgp-like kevinbacon-like "degrees of separation"

This is sounding more and more complicated.  Why not just use the delete
key?

> it turns out both of those are missing.  and creating
> them is a bigger problem than rewiring smtp would be.

SMTP is pretty much cast in concrete and will likely be with us for decades
to come, at the absolute minimum; so it's best to try to work within it.

> as usual, i would be happiest if someone else would

No so busy that you don't have time to open spam messages and examine them
to see if they contain pornography, or personal messages to other people, or
the like.

> my goal at the moment is to discover whether the ietf
> possesses a "collective will" and if so, whether it is
> "willing" to take on this much larger problem.  so far

Probably because, in the final analysis, spam is an annoyance, but that's
about all.  Like postal junk mail.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 8 Jun 2003 10:36:21 +0200

Paul writes:

> 1. does the ietf as a community generally believe
>    that provable mutual consent between a sender and
>    recipient is an achievable (technically) and
>    desireable (by the global user base) goal?

It's certainly achievable technically, since other protocols already do it.
I don't see it as desirable, though, since it would generate more overhead
than spam does, and it would significantly slow and impede e-mail
communication overall.  Additionally, it might take decades for everyone on
the Internet to adopt it, and those who did not would eventually be at a
disadvantage, even if they were not spammers.

> 2. if #1, does this same community believe #1 can be
>    accomplished by means of negative pressure (bayesian,
>    dcc, blackhole lists, hashcash, etc) on the current
>    e-mail system (smtp, rfc822, mime)?

No.

> 3. if !#2, then does this same community have any interest
>    in being a creative, ambitious force that brings this
>    functionality to the masses, or should this work be
>    pursued independently/elsewhere?

Not applicable, given the answer to #2.

---

From: "Haren Visavadia" <[email-masked]>
Date: Sun, 8 Jun 2003 11:22:51 +0100

One way to deal with is to use a firewall theory.

I contain a list of e-mail address of people.

So if I receive a e-mail, if it is not in my e-mail address list, it is
discarded.

The only problem is e-mail addresses can be faked.

For example, its configuration could be:

Allow <[email-masked]>
Deny <*@*.com>

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 08 Jun 2003 05:49:36 -0700

> If someone tries to send mail and their key is not on the
> recipient's list, the mail is returned to them until they can
> perform a Hashcash calculation consuming a non-trivial amount of CPU
> time, at which point their key is placed on the recipient's list,
> and the sender can retry to send the message.  

Hashcash has one big problem: worms.    CPU time is free for them..

There are many reports in the press suggesting that spammers are using
worms such as "Jeem" to deploy open relays; they could also use them
to deploy hashcash generators.

						- Bill

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 8 Jun 2003 07:26:12 -0600 (MDT)

>    (technically) and desireable (by the global user base) goal?

What's that about a "community"?  Individuals can believe things, but
communities can only argue.  Communities also don't write code or even
Internet-drafts.  It's also not clear to me what "provable mutual
consent" means.  I suspect it's something other than PGP key servers
or PKI, but I've no clue if it's more interesting than the NSA's
Rainbow Series on Trusted Computer Systems on one hand or the unending
stream of unbreakable military grade one time pad psuedo-random number
based encryption products on the other.

>    hashcash, etc) on the current e-mail system (smtp, rfc822, mime)?

I see no consensus on what to do about spam and don't believe one is
possible for any of those efforts or any group of them.  It's
possible that something new would fair better, but pigs in pokes are
hard to sell except to those whose opinions are worthless.

>    the masses, or should this work be pursued independently/elsewhere?

After passing that through an exhortation filter, I'm left with "should
work be pursued independently/elsewhere?" which is hard to gainsay.

The continuing history of IPng is cautionary for IETF Manhattan-project
style community efforts.

> as they have been since may 25 when i entered this thread.

The little I've understood is that you've said something about "mutual
consent" and vendors or notaries of the same, which for me evokes
"like Verisign?" and a little more best unsaid.

---

From: "Tomson Eric \(Yahoo.fr\)" <[email-masked]>
Date: Sun, 8 Jun 2003 15:55:13 +0200

=>-----Original Message-----
=>From: [email-masked] [mailto:[email-masked]] On 
=>Behalf Of Anthony Atkielski

(...)
=>
=>Children are not interested in porn, so spamming them with it 
=>isn't nearly as harmful as their elders would like to 
=>believe.  Only adults care about sex.
=>
(...)

Anthony,

This sounds quite dangerous a way of thinking to me. And proven to be quite
erroneous : look at how the cigarette manufacturers focus on youth as the
ideal target for advertising. They know they must attack them very young to
bind them on the long run and make them addicted customers later, when they
are grown-up.

So, in short : *maybe* only adults care about cigarettes and sex (not sure
of), but I think both are - or could be - the target of choice for
advertisers, because it seems that when you catch them young enough, you
create a bigger, deeper addiction.

E.T.

P.S.: and it appears to be similar with alcohol, candies, cars, computers,
drugs, gambling, guns, pets, etc.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 8 Jun 2003 16:06:57 +0200

Eric writes:

> This sounds quite dangerous a way of thinking to me.

Nothing particularly dangerous about it.  Adults seem to readily forget that
they were completely uninterested in sex prior to puberty; things sexual
(including pornography) were nothing more than curiosities that rapidly
became boring on those rare occasions when they were encountered.  Adults
have a built-in obsession with sex; prepubescent children do not.

It's rather like gambling addicts assuming that anyone who walks past a
casino cannot resist running in and squandering his life's savings on
gambling.  That may well be a danger for gambling addicts, but it is not a
danger for anyone else, and in fact the addict is just projecting his own
behavior and preoccupations onto others.  Thus, the general public doesn't
need to be kept away from casinos, because most people don't care about
casinos, anyway--even though gambling addicts may behave self-destructively
when exposed to casino activity.

> And proven to be quite erroneous ...

I'm not aware of any invalidation of this principle, and it is regularly
confirmed.

> ... look at how the cigarette manufacturers focus on
> youth as the ideal target for advertising.

Sex and cigarettes are not the same thing.  Nobody is interested in sex
prior to puberty; everyone is interested in it after puberty.  In contrast,
an interest in cigarettes is strictly acquired, and in fact must be
explicitly sought out, since smoking is not by nature a pleasant activity at
any age.

> They know they must attack them very young to
> bind them on the long run and make them addicted
> customers later, when they are grown-up.

There is no need to "attack" youngsters with pornography; they will become
potential consumers at puberty, whether they are exposed to it prior to that
age or not.  And conversely, they won't care about pornography until they
reach puberty--they'll just see it as something icky and boring, if they run
across it at all.

> So, in short : *maybe* only adults care about cigarettes
> and sex (not sure of), but I think both are - or could be
> - the target of choice for advertisers, because it seems
> that when you catch them young enough, you

No spammers are deliberately advertising porn to children; apart from legal
risks, it's a waste of time, rather like advertising refrigerators to
Eskimos.  They are trying to spam _adults_ with porn ads.  And given how
much traffic on the Internet is dedicated to porn, they probably get quite a
return on their investment--from the grown-ups, not from kids.

> P.S.: and it appears to be similar with alcohol,
> candies, cars, computers, drugs, gambling, guns, pets, etc.

None of these have a biological basis.  Sex does.  The distinction is
important.

---

From: Dean Anderson <[email-masked]>
Date: Sun, 8 Jun 2003 13:05:47 -0400 (EDT)

On Sun, 8 Jun 2003, Anthony Atkielski wrote:

> bandwidth used by e-mail.

Which is still practically nothing, compared to the bandwidth consumed by
http (gifs and jpegs), IM (and its picture sharing), (legal) movie and MP3
downloads, and other stuff.

Also, you mentioned something about porn to children. This is already
illegal. If its a Type 1 or Type 2 operation, they are easy to shutdown.
Unfortunately, quite a lot of this type of spam is Type 3 spam, just meant
to shock and annoy, and not meant to really sell porn.

> about all.  Like postal junk mail.

Agreed.

		--Dean

---

From: "Theodore Ts'o" <[email-masked]>
Date: Sun, 8 Jun 2003 13:47:07 -0400

> we've got a number of those already.  (this one sounds new and better.)

In order for this to work, the request for the Hashcalc calculation
has to be done automatically.  If it requires manual intervention
where the user sees the reject notice and then has to manually take
action --- of course, it's doomed to fail.  So this is something which
would require modification to the MTA's in order for this to work.

The easist way to automate such a scheme would be in the context of
your "replace SMTP" proposal; it's just a matter of using bare keys +
hashcash-style solution, instead of requiring a global PKI.

						- Ted

---

From: "Anthony Atkielski" <[email-masked]>
Date: Mon, 9 Jun 2003 00:34:15 +0200

Dean writes:

> Which is still practically nothing, compared to the
> bandwidth consumed by http (gifs and jpegs), IM (and
> its picture sharing), (legal) movie and MP3

I know, which is why I specified e-mail bandwidth specifically.  One cannot
say that spam is actually putting a load on network bandwidth, since there
are much greater bandwidth hogs on the Internet

> Also, you mentioned something about porn to children.
> This is already illegal. If its a Type 1 or Type 2
> operation, they are easy to shutdown.

Of course, spammers tend to send to e-mail addresses, not to human beings.
Whoever has access to the mailbox receives the mail.  But I don't see any
reason why pornographers would target children, since their only real market
is adults.

> Unfortunately, quite a lot of this type of spam
> is Type 3 spam, just meant to shock and annoy, and
> not meant to really sell porn.

I don't even know what is Type 1 or Type 3 in my mailbox, since I delete it
all without reading it.

---

From: "Bill Cunningham" <[email-masked]>
Date: Sun, 8 Jun 2003 21:40:57 -0400

----- Original Message -----
From: "Theodore Ts'o" <[email-masked]>
To: "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, June 08, 2003 1:47 PM
Subject: Re: Engineering to deal with the social problem of spam

> hashcash-style solution, instead of requiring a global PKI.

Good Idea. Sounds like a Pretty Good Protocol.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 09 Jun 2003 00:24:36 -0500

> hashcash-style solution, instead of requiring a global PKI.

If a key was linked to a sender address, wouldn't that give somebody
everything they'd need to send me mail (just send it as me, since I'm
going to read my own mail even if nobody else does)? What's to prevent a
group of blackhats in the ~Ukraine from having their farm of 3Ghz PCs
generate error responses all day, just to gather keys to sell along with
the associated addresses? How would I replace the key/address pair in all
of the good repositories -- but not the bad ones -- after my key were
compromised, especially if my own delivery server is responding to
requests on my behalf?

Isn't the only way out of this to require senders use certificates that
can be validated, proving that the sender has access to a private key
which roughly corresponds to that address?

I'm in agreement that we don't need a "global PKI" to do any of this. We
only (ha!) need a relatively simple and lightweight way to locate and
retrieve public keys associated with specific resources (additional
vouching systems would be useful but aren't immediately necessary). That
particular problem isn't too tough to solve when limited to a scope that
is somewhat smaller than "global PKI", and I think we'll actually get
something like that relatively quickly. I also think this is mostly a
chicken-and-egg problem at that level, and that we might find both the
chicken and the egg at the same time if we're willing to look a bit.

---

From: Paul Vixie <[email-masked]>
Date: 09 Jun 2003 09:35:43 +0000

> > i think that we could write [hashcash] up as open source and widely
> > distribute it and publicize the hell out of it for the rest of our
> > careers without ever having it become common practice to
> > reject-with-explaination all e-mail that comes from unauthorized
> > senders.  therefore it can become, at best, a system that radical and
> > highly technical recipients can use.  we've got a number of those
> > already.  (this one sounds new and better.)
> 

ah.  then the right way to think about this is "an option for trust" where
one way to "feel the trust" is to know that someone else has performed the
hashcash ritual on your behalf.  this is workable.

> hashcash-style solution, instead of requiring a global PKI.

hashcash-style solutions are prone to computational cost diversity problems,
such that someone you want to exchange e-mail with might still have a 2GHz
32-bit CPU even though 90GHz 64-bit CPU's are what's being sold at that time.
a requirement that someone do some work that takes 1 CPU minute on the fast
(future) CPU's will tend to "lock out" owners of older (current) CPU's.  a
requirement that would only take one CPU minute of time for an older (current)
CPU would "allow in" any spammer who wanted to buy (lots of) modern hardware.

but more germane to the problem at hand is the fact that the community Will
Not Move To A New Protocol if all it offers is hashcash, with or without the
computational cost diversity problems, with or without other problems.  my
children are relatively wise in the ways of the world but the age at which i
want them to have ibcs(*) access is lower than the age at which i'd be
comfortable letting anyone with hashcash in their pocket send us traffic.  so
while hashcash might be a form of trust for some, it wouldn't be one here.
-- 
Paul Vixie

(*) "ibcs" == interpersonal batch communication system, which is my generic
term for "whatever will follow 821/822 email".

---

From: Paul Vixie <[email-masked]>
Date: 09 Jun 2003 09:54:58 +0000

> communities can only argue.

that's how it feels, i know.  however, even the most bitterly disappointed
individual contributor to the IPng effort knows that IPv6, warts and all,
could only have come from a "community."  because of the number of adopters
needed to deploy it before it could become relevant, the technology had to
be developed in a sausage factory of some kind.

note that i am not sure that ietf is the right such "community" for ibcs(*)
but i am very sure that it won't get done by a small team working in dark
and quiet and then thrusting a working solution into the spotlight with a
bit "USE ME!" sign painted on it.

> possible for any of those efforts or any group of them.  

this isn't about spam, it's about trust.  with MAPS and DCC my early
thoughts were in terms of "disabling nonconsensual communications" and what
i've gone over to in recent years is "enabling consensual communications"
which is not at all as similar as it sounds.

> The continuing history of IPng is cautionary for IETF Manhattan-project

therein lies the rub.  nothing like DNS or HTTP could be created in the
kind of sausage factory the ietf has become.  there are too many witnesses
now, and too many helpers.  if someone hears that something interesting is
going to be worked on, they join the mailing list and come to meetings
since they're at ietf for the week anyway.  with 750 people on the mailing
list and 300 in every meeting, all actual work stops, or moves into "design
teams" which mimic the IETF of olde (or so i'm told -- my first rfc was in
the 1800 series, so most of the history predates my participation.)

however, i do not consider IPng to be a failure.  it's taking a while to get
deployed, that's true, but at least (unlike DNSSEC) the last flag day has
passed and there are multiple interoperable implementations.

so the choice of whether to do ibcs inside IETF isn't dictated (in either
direction) by what's happened with IPng.

however, the choice to do ibcs outside IETF may be dictated by what's had
to happen with HTML and its related standards.

> "like Verisign?" and a little more best unsaid.

no, not like verisign.  in <[email-masked]> i wrote as follows:

| s/mime relies on the x.509 pks industry which in is turn based on the goal
| of enriching a small number of ca's who have to pay for relationships to
| browser/useragent vendors who then make the certs worthwhile.  that can't
| scale and hasn't scaled, other than in the case of server certs.  no way
| will the average user be willing to pay money for a personal cert signing
| if the companies on the list have all spammed them.

sorry to evoke the wrong thing.  i really am trying to be very clear, here.
-- 
Paul Vixie

---

From: Marc Schneiders <[email-masked]>
Date: Sun, 8 Jun 2003 00:25:07 +0200 (CEST)

On Sat, 7 Jun 2003, at 13:57 [=GMT-0700], Spencer Dawkins wrote:

> do, and some of them are on this list.

I know absolutely nothing more than the bare minimum needed to keep
sendmail running (so far). That is no reason to stop reading.  If my
idea has some merit, you can stop the spam topic on this list.

Why do people not fill my snail mailbox with junk letters, leaflets?
Because (1) it costs money to print a leaflet and get it distributed.
Also (2) there are (where I live) laws and political deals with
advertizers, that make it a bad idea to use addresses from cd-roms, or
just deliver leaflets to all addresses (direct distribution). If my
mailbox says "NO" I should not get them. And the great thing is, the
Dutch police and justice system can get at those who don't play by the
rules.(*)

Spam costs nothing. Spam comes from all corners of the world, where
the Dutch police doesn't dare to go. And even if they would the Dutch
judges would say it is without their introduction. Spam can only be
fought through a worldwide police and justice system. This cannot by
achieved by an RFC. Send this problem to ICANN.

(*) I know that in theory people could evade being prosecuted in
Holland by sending advertizing letters, using illegal address
databases from Tuvalu and contact addresses for themselves in Libya.
But this doesn't happen.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 9 Jun 2003 07:57:44 -0600 (MDT)

> while hashcash might be a form of trust for some, it wouldn't be one here.

Why would you trust or even both with "ibcs"?  Why not just configure
your children's mail system to accept only mail that is signed with
any of a handful of cryptographic keys, using S/MIME, PGP, or whatever?

That solution is currently available only to a very few people, but
fixing that needs only modest work in user interfaces and no effort by
the IETF.  Some browser-MUAs can already be used to click on a URL to
add a certificate to a private, trusted list.  What would be wrong with
having the controls on your children's browser-MUAs locked with a
password that only you know, and then visiting the web sites of tour
children's teachers and sites of (the parents of) their peers to add
keys (certificates, or whatever) to a list of trusted senders?

] From: Paul Vixie <[email-masked]>

] ...
] > The little I've understood is that you've said something about "mutual
] > consent" and vendors or notaries of the same, which for me evokes
] > "like Verisign?" and a little more best unsaid.
]
] no, not like verisign.  in <[email-masked]> i wrote as follows:
]
] | s/mime relies on the x.509 pks industry which in is turn based on the goal
] | of enriching a small number of ca's who have to pay for relationships to
] | browser/useragent vendors who then make the certs worthwhile.  that can't
] | scale and hasn't scaled, other than in the case of server certs.  no way
] | will the average user be willing to pay money for a personal cert signing
] | if the companies on the list have all spammed them.
] ...

That Verisign is an industry pioneer and continuing leader in unsolicited
bulk commercial advertising is irrelevant.  Ethical outfits would not
suffer that problem.  The main problem is what you touched on by
talking about the x.509 pks industry.  The problem with third party
signers, notaries, and so forth is that at the price points that people
will pay in time and effort as well as money, the third parties cannot
do a competent job or anything useful.

People insist on using Outlook and Outlook Express instead of MUAs
that are not designed to be user friendly virus and worm transports.
They can't even be bothered to lock down their "security preferences."
I can't imagine people going to the equivalent of the trouble of
finding an old fashioned notary and paying $3 to get their keys or
whatever registered.

Note that those who know apparently don't trust old fashioned notaries.
Why else does the U.S. stock and bond industry refuse to use ordinary
notarized signatures?  From what I've seen, the few financial institutions
that can certify your signature on a stock certificate or similar
paper work are also ordinary notaries.

The problem is not lack of interest in the IETF, but among users.
Some of us are obsessed with some dangers, but most people have more
balanced views.  Most people don't pay any attention to the current
terrorism color scheme.  They did not buy generators and flee to the
woods to wait for the collapse of civilization due to the Y2K bug.
Only a few people in the military and civilian police prepared for
the great wave of terrorism that was supposed to sweep the nation
during the 1976 Bicentenial celebrations.  (The U.S. Army Reserve unit
in which I was working off my draft dodging was one.)

People who are really vulnerable to "nonconsensual communications"
such as your children can use whitelists to better effect than any
sevices from third parties.

---

From: "Haren Visavadia" <[email-masked]>
Date: Mon, 9 Jun 2003 17:29:20 +0100

>Spam costs nothing.

It costs you using your bandwidth.