Engineering to deal with the social problem of spam

[Dave Crocker]

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" requir

Re: Engineering to deal with the social problem of spam

[Dave Crocker]

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/
--
 Dave Crocker 
 Brandenburg InternetWorking 
 Sunnyvale, CA  USA , 

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> 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
> succeed?

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

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> 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.

"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

Re: Engineering to deal with the social problem of spam

[Eric A. Hall]

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.

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

Re: Engineering to deal with the social problem of spam

[Iljitsch van Beijnum]

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

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.
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
TH> authenticated email. Or as Vixie labeled the more generic, 
interpersonal
TH> batch communication system.
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.

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.
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.

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.
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
key lesson here and it is mostly missed. The lesson is that spammers 
are
adaptable
So let's show some adaptability of our own and plug those SMTP holes.

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)

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

So we then need to define unsolicited properly. We must make sure to
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.

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?
Why look at individual messages? How much non-bulk mail can someone 
possibly need to send? 10 messages per hour? 100? 1000?

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.
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.

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.
I'm not convinced.

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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
> wouldn't be able to do that for very long.

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
> plug those SMTP holes.

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.

Re: Engineering to deal with the social problem of spam

[Dave Aronson]

Iljitsch van Beijnum <[EMAIL PROTECTED]> 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

Re: Engineering to deal with the social problem of spam

[Dave Aronson]

Iljitsch van Beijnum <[EMAIL PROTECTED]> 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
 > distribution system. Then all we need is a system to differentiate
 > between trusted MTAs and rogue ones run by spammers.

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  ;->

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

Re: Engineering to deal with the social problem of spam

[Iljitsch van Beijnum]

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

On dinsdag, jun 3, 2003, at 16:56 Europe/Amsterdam, Dave Aronson 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
distribution system. Then all we need is a system to differentiate
between trusted MTAs and rogue ones run by spammers.

Then we're back to Square One (okay, maybe Three) with blacklists and
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.

Re: Engineering to deal with the social problem of spam

[Valdis . Kletnieks]

On Tue, 03 Jun 2003 18:06:19 +0200, Iljitsch van Beijnum said:

> 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.

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...



pgp0.pgp
Description: PGP signature

RE: Engineering to deal with the social problem of spam

[Tony Hain]

Iljitsch van Beijnum wrote:
> Just adding authentication only solves a very small part of the 
> 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.

> 
> 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.

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. 

> 
> > 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.
> 
> 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.

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.

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

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

> 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.

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

> 
> 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.

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

RE: Engineering to deal with the social problem of spam

[Tony Hain]

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

Re: Engineering to deal with the social problem of spam

[Iljitsch van Beijnum]

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

On woensdag, jun 4, 2003, at 02:54 Europe/Amsterdam, Tony Hain wrote:

Just adding authentication only solves a very small part of the
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.
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.

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.

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.
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.

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.

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.
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.

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

Or simply leave SMTP to the spammers and move on.
Fine by me.

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

@ 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.

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.

Exactly how would you coorelate email across multiple accounts, on
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.

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.

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.
At a limit of 1000 messages per hour per account, they need 1 
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 

Re: Engineering to deal with the social problem of spam

[Daniel Senie]

At 03:28 PM 6/7/2003, Eric A. Hall wrote:

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.
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.).

Re: Engineering to deal with the social problem of spam

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> ...
> "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?"
> ...

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.


Vernon Schryver[EMAIL PROTECTED]

Re: Engineering to deal with the social problem of spam

[Spencer Dawkins]

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 PROTECTED], and get
subscribed to my mailing lists with this address, I could move
away from mailto:[EMAIL PROTECTED] 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 PROTECTED]> wrote:
> At 03:28 PM 6/7/2003, Eric A. Hall wrote:
> 
> >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.
> 
> 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.).
> 
> 
> ___
> This message was passed through
> [EMAIL PROTECTED], which is a sublist of
> [EMAIL PROTECTED] Not all messages are passed. Decisions on what
> to pass are made solely by Raffaele D'Albenzio.

Re: Engineering to deal with the social problem of spam

[Eric A. Hall]

on 6/7/2003 3:57 PM Spencer Dawkins wrote:

> 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?

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.

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

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

Dave writes:

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

Neither is universally supported.

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> > > 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.

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.

> and to accomodate intra-company use of embedded devices which transmit 
> 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 PROTECTED]
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

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> 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 .  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 1:1 odds against this should
just gimme yer money right now, because it's not even a fair bet.
-- 
Paul Vixie

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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.

Re: Engineering to deal with the social problem of spam

[Eric A. Hall]

on 6/7/2003 6:01 PM Paul Vixie wrote:

>>> Probably better to specify the gateway tagging, ...
> 
> and we're going to convey trust and credence through a nontrusted
> system How?

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 [EMAIL PROTECTED] 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]

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

Re: Engineering to deal with the social problem of spam

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> > 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 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.


> 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
> ...

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.


Vernon Schryver[EMAIL PROTECTED]

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> 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.

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.

> 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.

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

Re: Engineering to deal with the social problem of spam

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> ...
> > So how about turning down the heat a little and being more technically
> > specific about your replacement for the Internet?  ..

> 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!"

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.


Vernon Schryver[EMAIL PROTECTED]

Re: Engineering to deal with the social problem of spam

[Theodore Ts'o]

On Sat, Jun 07, 2003 at 07:28:12AM -0700, Dave Crocker wrote:
> 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?"

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

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

[EMAIL PROTECTED] (Vernon Schryver) writes:

> 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.

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

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

[EMAIL PROTECTED] ("Theodore Ts'o") writes:

> 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.

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

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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"
> logic to find out about trust.

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
> take this on: i'm Busy.

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
> the answer seems to be not just "no" but "hell no!"

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

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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.

RE: Engineering to deal with the social problem of spam

[Haren Visavadia]

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 PROTECTED]>
Deny <[EMAIL PROTECTED]>

Re: Engineering to deal with the social problem of spam

[Bill Sommerfeld]

> 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

Re: Engineering to deal with the social problem of spam

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> > 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.
>
> 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?

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.


> 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)?

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.


> 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?

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.

> 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.

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.


Vernon Schryver[EMAIL PROTECTED]

RE: Engineering to deal with the social problem of spam

[Tomson Eric \(Yahoo.fr\)]

=>-Original Message-
=>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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
> create a bigger, deeper addiction.

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.

Re: Engineering to deal with the social problem of spam

[Dean Anderson]

On Sun, 8 Jun 2003, Anthony Atkielski wrote:

> 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.

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.

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

Agreed.

--Dean

Re: Engineering to deal with the social problem of spam

[Theodore Ts'o]

On Sun, Jun 08, 2003 at 07:29:32AM +, Paul Vixie wrote:
> [EMAIL PROTECTED] ("Theodore Ts'o") writes:
> 
> > 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.
> 
> 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.)

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

Re: Engineering to deal with the social problem of spam

[Anthony Atkielski]

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
> downloads, and other stuff.

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.

Re: Engineering to deal with the social problem of spam

[Hallam-Baker, Phillip]

Paul writes:

>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

Hmm and the cost of MAPS would be?

It costs money to perform authentication and issue certificates, less than
the amount charged for but the total cost to the end user in terms of time
is still significant and in the case of spam control you have certified the
wrong party.

The party that is generally held responsible for users actions is the ISP,
not the user. So that is the level at which you want to certify, not the end
user. S/MIME is not designed to do the job being proposed here. You want to
hold the ISPs responsible, there is no point in having greater granularity
in your authentication system than you intend to use in the revocation
system.

I don't know what a class 3 cert for an ISP would cost but I would guess
rather less than is charged for MAPS these days.


Phill

Re: Engineering to deal with the social problem of spam

[Bill Cunningham]

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


> On Sun, Jun 08, 2003 at 07:29:32AM +, Paul Vixie wrote:
> > [EMAIL PROTECTED] ("Theodore Ts'o") writes:
> >
> > > 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.
> >
> > 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.)
>
> 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

Good Idea. Sounds like a Pretty Good Protocol.

>

Re: Engineering to deal with the social problem of spam

[Eric A. Hall]

on 6/8/2003 12:47 PM Theodore Ts'o wrote:

> 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.

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.

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

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> > 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.)
> 
> 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.

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.

> 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.

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".

Re: Engineering to deal with the social problem of spam

[Paul Vixie]

> > 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?
> 
> What's that about a "community"?  Individuals can believe things, but
> 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.

> > 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)?
> 
> 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.  

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.

> > 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?
> 
> The continuing history of IPng is cautionary for IETF Manhattan-project
> style community efforts.

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.

> 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 PROTECTED]> 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

Re: Engineering to deal with the social problem of spam

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> ...
> 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.

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 PROTECTED]>

] ...
] > 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 PROTECTED]> 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.


Vernon Schryver[EMAIL PROTECTED]

Re: Engineering to deal with the social problem of spam

[james woodyatt]

everyone--

Here's a silly idea: let's try adding an option for hashcash to APEX.  
(Or has someone already done that?)

If the problem with hashcash is that worms can steal CPU cycles to 
generate hashcash, then let's attack the problem of worms separately 
from the problem of spam suppression.  If the problem with hashcash is 
that poor people are taxed more heavily than rich people for the 
utility of spam suppression, then-- well-- they should upgrade their 
CPU's, now shouldn't they?

And as for those too poor to keep their CPU's current, Let Them Eat 
SMTP.  They clearly have an unhealthy interest in paying to receive 
MAKE MONEY FAST spam, so we should encourage them to continue using 
SMTP anyway.  The Internet interprets censorship as damage and routes 
around it.  Let SMTP continue to serve the useful function it serves: 
carrying spam messages.

--
j h woodyatt <[EMAIL PROTECTED]>

Re: Engineering to deal with the social problem of spam

[Valdis . Kletnieks]

On Tue, 10 Jun 2003 10:08:15 PDT, james woodyatt <[EMAIL PROTECTED]>  said:
> And as for those too poor to keep their CPU's current, Let Them Eat 
> SMTP.  They clearly have an unhealthy interest in paying to receive 
> MAKE MONEY FAST spam, so we should encourage them to continue using 
> SMTP anyway.  The Internet interprets censorship as damage and routes 
> around it.  Let SMTP continue to serve the useful function it serves: 
> carrying spam messages.

Ahem.

I have several million dollars of compute resources at my disposal.
It will take a fairly large hashcash request to make it painful for
me.

There's a *large* number of people still in the 386 world, who are
financially unable to upgrade.  That same hashcash request that will
not inconvenience my hardware will probably kill their box for the
better part of an hour.  You are concluding that they therefor have an
interest in paying to receive spam???

If anything, spam is a *bigger* problem for those on older hardware,
simply because they have fewer computrons available to process it - so
you're basically creating a regressive tax here.

Just because the Internet routes around censorship doesn't mean that
we have the moral right to censor those people who need it the most -
those in underdeveloped countries with repressive regimes.

Just because the Great Firewall of China exists doesn't mean we should
add injury to insult by disenfranchising those who manage to get
around the firewall.

There is junk fax - and the Berlin Wall was brought down by fax machines.

Let's not get this wrong.


pgp0.pgp
Description: PGP signature

Re: Engineering to deal with the social problem of spam

[james woodyatt]

On Tuesday, Jun 10, 2003, at 22:12 US/Pacific, [EMAIL PROTECTED] 
wrote:
[...]
There's a *large* number of people still in the 386 world, who are
financially unable to upgrade.  That same hashcash request that will
not inconvenience my hardware will probably kill their box for the
better part of an hour.  You are concluding that they therefor have an
interest in paying to receive spam???
Yup.  I am.

If anything, spam is a *bigger* problem for those on older hardware,
simply because they have fewer computrons available to process it - so
you're basically creating a regressive tax here.
And I'm not going to apologize for proposing it.

Look, the phenomenon of spam is already a regressive tax, in and of 
itself.  I'm just looking for a way to get some useful work done in 
exchange for receiving it.  And I certainly won't mind if someone else 
is interested in paying me for the option to use the result of whatever 
useful work your CPU has to do to get your message in front of my 
eyeballs.

Just because the Internet routes around censorship doesn't mean that
we have the moral right to censor those people who need it the most -
those in underdeveloped countries with repressive regimes.
Who's talking about censorship?  I'm not proposing that we outlaw SMTP.

--
j h woodyatt <[EMAIL PROTECTED]>
that's my village calling... no doubt, they want their idiot back.

Re: Engineering to deal with the social problem of spam

[Dean Anderson]

On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote:

> On Tue, 10 Jun 2003 10:08:15 PDT, james woodyatt <[EMAIL PROTECTED]>  said:
> > And as for those too poor to keep their CPU's current, Let Them Eat
> > SMTP.  They clearly have an unhealthy interest in paying to receive
> > MAKE MONEY FAST spam, so we should encourage them to continue using
> > SMTP anyway.  The Internet interprets censorship as damage and routes
> > around it.  Let SMTP continue to serve the useful function it serves:
> > carrying spam messages.
>
> Ahem.
>
> I have several million dollars of compute resources at my disposal.
> It will take a fairly large hashcash request to make it painful for
> me.

Then you obviously have too much compute power for the number of users
that you have.

If you get more users, the compute power to implement hashcash increases.
Hashcash just makes you more vulneralble to a DOS attack, and does nothing
to deter spam. Spammers will still send something that is cheaper than a
postcard.

If you make email cost more than a postcard, _that_ will kill email.
Nothing else will.

>
> There is junk fax - and the Berlin Wall was brought down by fax machines.
>
> Let's not get this wrong.

Let's not forget that it was UUCP and not the internet that foiled the
coup that imprisoned Gorbachev for 3 days.

--Dean

Re: The spam problem is political (Re: Engineering to deal with the social problem of spam)

[Anthony Atkielski]

Marc writes:

> Spam can only be fought through a worldwide
> police and justice system.

If so, that does not bode well for the future.  As far as I can remember,
_nothing_ has been successfully fought worldwide, except perhaps smallpox.

> This cannot by achieved by an RFC. Send this
> problem to ICANN.

ICANN can't do anything about it.

RE: The spam problem is political (Re: Engineering to deal with the social problem of spam)

[Haren Visavadia]

>Spam costs nothing.

It costs you using your bandwidth.