Re: Engineering to deal with the social problem of spam

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]