Obviously if we can deliver that many emails per day THEN WE CLEARLY
CAN HANDLE THAT MANY TRANSACTIONS PER DAY! Nicht wahr?
And if we can deliver that many emails today at nearly no incremental
cost, or so it appears, then what do you base your insinuation that
adding the overhead of metering etc would skyrocket the cost on?
Several points.
1) Exception handling on E-mail delivery is very simple... any question about
whether it got delivered? Just send it again. Duplicate E-mail delivery isn't
considered to be a huge problem. Multiple charging for the same E-mail is
obviously a much bigger issue.
2) Auditability. When you're talking about money, you have to be much more
disciplined (and you have to deal with correcting the inevitable mistakes etc
which suddenly become a much bigger deal).
3) Handling "transactions" involves a much higher degree of guarantees...
delivery, non-duplication, accuracy, privacy, etc etc.
We seem to have added all manner of spam filtering,
Spam filtering, even quite elaborate spam filtering, is cheap in part because
it's inherently single-ended and doesn't therefore require any kind of "delayed
handling" (e.g. additional queuing while waiting for responses from other
entities elsewhere on the net, dealing with exceptional situations such as
cases
where expected responses don't ever occur, etc. etc)
...right down to
handshaking with multiple remote blacklists per message and running
each one through all kinds of DNS and content checks such as
spamassassin or various commercial spam filtering services'
software.
Stuff that can be done locally is actually very cheap, and scales well.
And all that doesn't seem to have, by its mere overhead, taken down
the entire world email system, yet, even if it's a lousy trend.
The problem with the free market is that pricing and other abuses and their
correction tends to exhibit a time constant that is not compatible with what
human expectation wants it to be...!
But it's not unreasonable to predict that if we had a pretty good, unified
system for preventing spam in the first place...
That's rather like the old joke about the economist, physicist, engineer, etc
all marooned on a desert island and eventually a crate of canned food washes
ashore, and they all set about trying to figure out how to open the cans. It
eventually ends with the economist announcing, "First, let's assume we have a
can opener..." :-)
The way to stop spam is ultimately for spammers to realize that it has a
vanishingly small chance of getting through, and therefore it is largely futile
and totally uneconomic to send it. Part of that shift involves making it more
difficult or expensive to send spam (legal action, making it harder to create
zombie spambots, etc) and part of it involves squashing virtually all the spam
somewhere enroute, before any human eyes (likely to benefit the spammer at
least) see it.
I still very much like the idea of turning the firehose back on the spammer (or
their Web/email host perhaps) in a sort of massively distributed retaliatory
DDOS attack, but the issues then are whether the spammer being retaliated
against is the real one and how to prevent "joe jobbing" (and this is true
whether the retaliatory responses are automated, or even if human-approved
before the counterstrikes are launched).
(such as an e-postage system as idealized)
"idealized" is all too true... this is one of those schemes where the devil
TRULY IS in the details and there are a LOT of devils there. In truth, the use
of "stamps" would help even if the stamps were FREE and distributed by the
addressees upon request. It's not at all clear that paying for them adds much
(that's GOOD, anyhow) to the scheme.
And in fact, that gets right back to the sort of scheme that I proposed to
begin
with... where the sender needs to negotiate (by plain ASCII text E-mails, that
have to maybe meet size restrictions and can pass through antispam content
filters) for permission to send a certain type of mail to the recipient.
Whether that permission is granted by the recipient by adding their name and
type of mail to the recipient-end whitelist (and then, I suppose, sending them
E-mail to say it's okay), or whether that "permission" is granted in the more
tangible form as a "postage stamp" or passcode (whether single-use or
multiple-use! but 'revokable' without notice in any case) that the sender must
include with their future E-mails in order to evidence prior approval...
personally, I think it's just as easy for the recipient to look up the sender
name (and perhaps 'passcode') and check the incoming E-mail type against that
sender's pre-approved permissions as it is to process a "stamp".
...then all that other overhead infrastructure would be taken apart, or most
of it anyhow.
Far better, I think, to AVOID the waste of building a pointless worldwide
infrastructure that ultimately DOES NOT SOLVE THE PROBLEM (and later to realize
that and take it back apart again). Let's be smarter about how we do things.
So why do you keep asserting that adding the overhead that might be
incurred in other per-message proposals is so obviously the straw that
shall break the camel's back? (gak! lousy sentence, sorry.)
It's not just the overhead, and the need for worldwide concurrence. It's the
fact that it creates as many problems (or more) than what it solves, and still
doesn't fix the spam problem.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections! http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg