Subject: [Asrg] Re: Asrg] My take on e-postage

From: [email-masked]
Date: Mon, 26 Apr 2004 02:13:03 -0500

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 26 Apr 2004 12:51:16 +0100

> problem and the most annoying from the perspective of typical users.

Agreed.

> someone is going to be gone on a cruise for a week or two...
>

That's also an interesting way of looking at the problem, but it can 
already be handled without extra standards.  Perhaps someone could 
write something to hook into procmail, and/or write a BCP.

>> stamps, but they will be able to choose their stamp vendor, rather 
>> than being limited to their ISP.
>

Without attaching *some* new piece of information to the mail itself, 
the only even partial solution I can see is rate-limiting by the 
sender's ISP.  Which isn't happening, in general.  Only a few ISPs - 
the most savvy and network-oriented (as opposed to revenue-oriented) - 
seem to have any mechanism to detect and deal with zombies.

> Thanks for also pointing that out.  That is in fact the KEY problem, 
> at least using present-day spammer approaches.

Hold onto that thought.

Why did spammers start using zombies?  Because we got good at 
blacklisting by IP address.

Why did we blacklist by IP address, rather than whitelist by e-mail 
address?  Because we didn't have any strong authentication method that 
was widely used - and we still don't.

> systems and "serious" OSes.

The difference is that the cluster was hacked by a determined, 
"professional" cracker in an isolated incident.  The Wintel zombies are 
being compromised by what we used to call "script kiddies" using 
mass-market exploits, via vulnerabilities that were either known (and 
were patched) long before, or social engineering coupled with poor OS 
design.

While the Mac and Linux are not perfect, they do lack many of the 
fundamental design flaws that make Windows such a soft target.  Linux 
MUAs are largely incapable of creating an executable file on their own, 
and have to be deliberately coaxed into expanding a tarball in such a 
way.  Apple Mail isn't quite as mistrustful, but it's generally clear 
to a Mac user what is an executable and what isn't.

> (trusted, legitimate) systems to serve spammers.

Then how do you propose to get rid of the zombies?  I thought we just 
agreed they were always going to be a problem.

If the resource being leeched is controlled by a third party, however, 
it's easier to monitor and take action on suspicious behaviour.  This 
is why e-postage can be helpful - as I mentioned immediately 
afterwards, the compromised account will quickly run dry.

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

Of course.  Education is vital!  Perhaps, to save personnel costs, ISPs 
(especially those who are also stamp vendors) will start throwing in 
antivirus software, easy-to-use personal firewalls, and even (wow!) day 
classes for net-newbies.

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

ISPs that take that kind of attitude probably deserve to lose 
customers.  The *right* approach is to offer advice on how to clean up 
and secure their machine, and how to avoid future infections.  It's not 
really all that hard, and they could even print a leaflet about it with 
step-by-step instructions.

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

Unstamped spam isn't going to get into the inboxes of participating 
recipients - that's the whole point.  Once woken up, the victim might 
be one less person to get re-infected in the future, so perhaps the 
endless supply of zombies will get less plentiful in the future.  At 
the moment, there's little or no feedback to victims, so they don't 
learn anything.

> direction" things, like SPF, that ultimately doesn't really answer the 
> spam problem in a meaningful way.

...but it's not actually a *bad* thing, is it?

> though there are millions of holes.

Uh-huh...

> valid return addresses.

But in that case, you know who's sending it, so you can block them 
temporarily and help them fix it.

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

But we don't.  If we did, we'd be able to stop spam, NOW, just by 
slapping one of these perfect filters on the front of our inbox.  
Here's some news:  we already do use content filters - everything from 
Bayes through distributed bulk detectors to phrase matching.  It helps, 
but it is absolutely nowhere near perfect.

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

Some of the proposed schemes undoubtedly are.  Have you read the 
discussion I've been having with "der Mouse" over the past day or so?  
I think we've hashed out something a lot more scalable than most, 
though I won't pretend it's finished.  Many schemes and objections seem 
to assume, for example, that stamps have to be anonymous like e-coins - 
which makes them unreasonably hard to verify.

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

Take a look at the numbers I worked out, with commentary, in the 
discussion with "der Mouse".  The gist of it is that while zombies can 
indeed be turned into hashcash factories, they will still be limited to 
a tiny fraction of what they'd normally be capable of if they were just 
limited by bandwidth.  So it improves the situation dramatically when 
compared to the status quo.

And that's while keeping the bit count low enough to run on Aunt 
Tillie's prehistoric Mac IIcx.  If we forget about the IIcx and 
concentrate on Pentium-class customers, the rate limit gets even 
tighter.

> And likewise, "identified" systems can be taken over by zombies.  So 

If an identification is compromised, a few spams will get through to 
particular recipients who have it on their whitelist, but the 
recipients will know exactly who needs to be told about it, and can 
remove the appropriate whitelist entries until it gets fixed.  Without 
the whitelist, the identification becomes moot, as the filter will fall 
back on other schemes.

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

Do I want forged mail in my inbox?  No, because whoever sent it can't 
be trusted to even say who he is.  End of discussion.

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

Stop.  Think.  How do mass-mailing worms usually find machines to 
infect?  They scan the latest victim's address book.  Then they send 
infected mail using every combination of addresses they can think of 
from that list.  Chances are good, a lot of these people know each 
other and maybe even trust each other to send attachments once in a 
while.  Add just a tiny bit of social engineering, and you have a fresh 
zombie.

The same logic applies to spam.  Chances are, a lot of people in the 
address book will be in each others' whitelists.

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

Executable attachments are old news.  Every ISP with a clue already 
blocks them.  The new threat is ZIP archives!  Even better, they're 
polymorphic, password-encrypted ZIP archives that are hard to scan with 
antivirus programs!  Tell me, how do these fit into your brilliant 
scheme?  Don't forget that these ZIP archives are often apparently 
coming from people the recipient trusts, and probably has in their 
whitelist...

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.