First things first. The resource being consumed/abused is the
recipient's inbox.
While not the ONLY one, I'll agree that that's the one which is the biggest
problem and the most annoying from the perspective of typical users.
Therefore we need to make any charge a condition of entry into a
participating
recipient's inbox.
I don't think it needs to be a CHARGE, per se. But clearly we need to have a
variety of ways that recipients can control who gets to put stuff (and more to
the point, what KINDS of stuff) into their Inbox.
I've specifically mentioned HTML and attachments, but a similar control might
be
that a recipient might want to limit the ability of non-whitelisted senders to
(say) drop messages bigger than a certain SIZE into their Inbox, too. If
someone is going to be gone on a cruise for a week or two, and has a typical
10Mb Inbox provided by their ISP, it's a big problem if someone (especially
someone sending a mis-addressed E-mail!) drops an 8Mb E-mail into their Inbox
the moment the vacationer heads out the door! Their mailbox might be bouncing
important mail before their flight even takes off to their holiday destination.
:-((
That means the recipient is the one who needs to decide whether a stamp is
needed, and whether any given stamp is sufficiently valid.
I don't think that recipients really give even a half-hoot about stamps. What
they have is a limited resource (Inbox, and their time!), and they typically
want to restrict WHO has access to it, or (if they're a newcomer) how much
space
they can use until the recipient has decided whether or not to grant them more.
Unilaterally charging a levy at the sending side isn't going to work,
for a variety of reasons - primarily that the major ISPs will start
using it as a revenue stream in it's own right, rather than for the
intended purpose of preventing abuse by it's customers.
ABSOLUTELY!!!! Worse, the "revenue stream" will end up costing consumers A
WHOLE LOT MORE than they pay today, for a whole lot less usable service.
Another reason is that spammers will set up their own ISPs and backbones to
avoid the normal stamping routes as much as possible.
Phooey!! They don't send their own mail out NOW! But whatever the mechanism
is
by which they avoid paying "postage", we agree that spammers won't be paying
the
costs of sending out their junk E-mails. Someone else will pay (and dearly, no
doubt).
In a recipient-driven scheme, senders still have to be able to buy
stamps, but they will be able to choose their stamp vendor, rather than
being limited to their ISP.
Stamps are stupid and cumbersome. I agree with those who point out that the
purpose is to limit sending rate and volume, and that there must be easier and
less complicated/expensive/disadvantageous ways to do that.
There's always going to be a zombie-PC problem, to some extent at
least.
Thanks for also pointing that out. That is in fact the KEY problem, at least
using present-day spammer approaches.
At the moment there are hundreds of thousands of insecure
Windows machines out there, and they aren't going away.
If anything, the Internet user population is overall DECREASING in savvy-level
as more and more clueless-type-folks find their way increasingly online.
There is a very slight possibility that it might be feasible to economically
force novice users onto a more secure platform - such as the Mac -
There's NOTHING inherently more secure about the Mac, other than the fact that
it's a distinctly second-string system in terms of frequency and therefore
hackers haven't focused their attention on it. If everyone were running Macs,
or everyone were running Linux, then hackers would be writing Mac or Linux
worms
instead, and they'd be comparably successful.
Note that (just recently) a multi-university "distributed supercomputer
cluster"
of *nix-based boxes was penetrated by hackers, much to the chagrin of the
associated administrators. And THAT was a system which DID have savvy,
highly-intelligent-and-qualified admins AND expensive, professional-grade
systems and "serious" OSes.
...but we can't rely on that, either.
Right, on that we agree.
A problem is that zombies can't merely be used as a relay, they can
also be used to leech any stamp account the victim uses for their own
e-mail.
Absolutely. And that's why _all_ of these modified-DNS, SMTP-auth, SPF,
certificate, E-postage, and similar such systems are ALL simply non-starters.
NONE of them solve the problem, because zombie enlistment will enroll
legitimate
(trusted, legitimate) systems to serve spammers.
Any antispam approach (at least based on everything I've seen so far) which
doesn't also address the worm/virus/zombie problem in a major way is like
pissing into the wind.
However, the compromised stamp account will quickly either
become empty or run up a monstrous bill on the victim's credit card
(the former situation is obviously preferable, and I'd hope that
consumer stamp accounts were set up that way).
Either way, there's going to have to be a procedure (probably involving
per$onnel) to deal with that $ituation when it (frequently) develop$. Taking
the "Harry Hardass" approach ("well, that's just too frickin' bad, maybe you'll
learn next time to not let your system get infected!") will end up eventually
driving a lot of people offline that *need* to be online. This kind of thing
will eventually become a NIGHTMARE, and a costly one to boot. I really don't
see it as a practical solution.
After that, the zombie can still spew mail all over the place, but it will be
unstamped. The empty account (or huge bill) also serves as a wake-up call to
the victim, to get their machine cleaned and secured.
Fine, but again, meanwhile, you're going to have lots and lots of spam. And
for
every spambot zombie that you clean up, the spammer will create two new ones.
The interesting thing is that a stamp can also act as proof of where
the mail was sent from, and/or who by, because there's a money trail
(if nothing else) to follow, and each stamp is unique.
Again, I think this is one of those "it seems like a step in the right
direction" things, like SPF, that ultimately doesn't really answer the spam
problem in a meaningful way.
This probably won't tell you who the spammer is, but it can help for
whitelisting...
Well, you know, I don't think that you really HAVE to do that for useful
whitelisting. It's sorta like the metal grills in the door windows of
microwave
ovens... if the holes are small enough, the microwaves simply don't escape even
though there are millions of holes. If the bogus senders don't know how to get
their spam through the holes, and the holes are small enough, then most spams
are going to hit the barrier and fall by the wayside.
Hopefully most recipients will open their "permission windows" to their Inboxes
JUST large enough to let in the stuff they want, from the folks they trust, and
keep them tight enough that almost nothing else manages to slip in.
forgery detection,
Forgery detection sounds fine, and I suppose that you could even just build
your
OWN statistical table based on IP addresses that you've seen in the headers of
valid E-mails coming from whitelisted senders, but again that fails
dramatically
when the "valid" non-forged sender gets infected and starts sending spams with
valid return addresses. I think that one can forego trying to detect
forgeries,
actually, as long as you have a good way to detect spams based on their CONTENT.
Content is really what decides whether something is spam or not, NOT whether
it's forged, or sent in bulk, or most anything else.
...and for notifying victims. And it doesn't require
the victim's ISP to lift a finger, unless they also happen to be the
stamp vendor.
E-postage is cumbersome, costly, and very labor-intensive to deal with the
problems that would inevitably result from it.
The big disadvantage for e-postage is that everyone now has to pay for
e-mail service. A service which we presently take for granted as
incrementally free.
Yeah, that's not exactly an appealing aspect of it either. Especially as
worthwhile organizations come up with good, non-abusive ways to further social
goals using the low-cost options that E-mail makes available. Even just
"community building" things like Yahoogroups... things which are very
satisfying, even though most folks would never pay for them directly on an
incremental basis.
There are alternative schemes which can operate alongside e-postage to
eliminate the monetary cost for most normal purposes. A combination of
a proof-of-work stamp (such as hashcash) and a proof-of-identity
signature would also serve a useful rate-limiting purpose. Again, it's
up to the recipient to decide how strong a guarantee he requires before
a mail can land in his inbox.
The problem, again, is that both "proof of work" and "proof of identity" are...
JUST like E-postage... subject to being subverted/stolen by spammers. The army
of spammer zombies out there have a collective computing power FAR greater than
that of ALL the legitimate E-mail publishers. So that scheme simply doesn't
work. And likewise, "identified" systems can be taken over by zombies. So
neither of these schemes work. Period.
(At the moment, most recipients' barriers to entry are exceptionally low,
even
with today's content filters, because there's no practical, universal way to
detect forged mail.)
Detecting "forged" mail, while arguably nice to know, only tells you whether
mail is (probably) forged. It doesn't tell you EITHER that the mail is, or
that
it is not, spam. Absolutely *nothing* whatsoever says that spam must use
forged
return addresses (and as I've pointed out, it's a KINDNESS of the spammers
(after a fashion, anyhow) that they do for now usually use forged return
addresses). It achieves little (and is probably counterproductive) to force
spambot zombies to use real, legitimate E-mail addresses instead.
And note that, as I've pointed out, those E-mail addresses don't even need to
be
valid for the sending MACHINE... a big ISP, for example swbell.net, will
SPF-certify EVERY E-mail that uses a legitimate swbell.net user name (and there
are probably MILLIONS of valid ones) since any of those could conceivably come
from any swbell.net mail server. So this whole area, too, is honestly a
non-starter (as much as Wong would try to make less-cognizant folks believe
otherwise).
The common factor in the above is that the sender can say "I want this
mail to go through so badly that I will do one or more of the
following: prove *I* sent it; pay for a stamp from a trustworthy
vendor; expend N seconds of CPU time".
I think it's enlightening to understand that *NONE* of those costs need
necessarily to be borne by the actual spammer. Clearly they can, and will,
shift those to their victims... just as OBL didn't BUY the (literally HUNDREDS
OF MILLIONS of dollars worth of) airplanes and fuel that they used to destroy
WTC and damage the Pentagon. They STOLE our own resources and used our OWN
things against us. Spammers do the exact same thing, and it's critical to not
forget that. All of these schemes (except mine, I think) are based on spammers
"playing by the (new) rules" and there's more than ample evidence to prove that
they simply don't do that, and aren't likely to start doing so anytime soon.
The recipient can then look at the credentials supplied with the mail,
optionally check them against stamp vendors' databases (etc.), and decide
whether they're good enough.
Again, a non-solution because spambot zombies will commandeer "credentialed"
systems and spam from them.
That's one of the distinguishing characteristics of my proposed approach...
there is nobody who gets blanket approval to do anything everywhere (with the
exception that everybody (by default, anyhow) can send HTML-free,
attachment-free plain ASCII text E-mail, as long as it passes the content
filter
that identifies nearly all spam mail content).
An infected zombie machine only can send the type of E-mails it usually sends,
and only to the folks who have approved receiving those from it.
Bogus counterfeit E-mails as From addresses for HTML-burdened E-mail are very
very unlikely to get through the permissions gauntlet protecting the
recipient's
Inbox. Those trying to send executable attachments have less (almost zero!)
likelihood of ever being delivered, simply because most recipients allow almost
nobody to send them that kind of stuff.
And it doesn't matter all that much if someone with lots of permissions ends up
being infected, since chances are good that if they start sending spam, it will
STILL be picked up by the content filter... (and they can only still spam to
the
people they habitually send that type and class of HTML-burdened stuff to, and
the spammer doesn't really know who that might be so they don't have any very
effective way of deciding what part of their spam victim database to send to
each zombie spambot machine).
Likewise, they in general don't know who the intended recipient might have
whitelisted, so they don't know either which machines they'd need to infect (or
what From addresses they'd have to counterfeit) in order to get their spam
through to that specific recipient.
What this ends up building is a fairly narrow-mesh permissions grid where a
spammer has a very small chance of guessing their way successfully through it.
And the biggest problem confounding most antispam approaches, the spambot
zombie, is virtually eliminated as a threat (at least for E-mail transmission)
by my approach's default of not allowing executable attachments from
non-whitelisted (TO SEND EXECUTABLES!) senders. Again, note that typical users
will normally not whitelist ANYBODY AT ALL to send them executable attachments!
NONE of these other DNS-based, certificate-based, credentials-based,
E-postage-based, Hashcash-based, upload-rate-limited, etc., technical proposals
do much of anything at all to solve the problem of how easy it is to recruit
zombie spambots, and that's a big part of why they simply don't solve the
problem!
People, please point out what's wrong with the above, specific
high-level design, not with "e-postage" in the abstract.
Hopefully I've managed to pretty adequately do that. ;-)
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