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

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

> 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...
>
> 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.
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.
> > 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.
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.
> > 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.
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.
> 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.
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.
> > 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.
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.
> > 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.
...but it's not actually a *bad* thing, is it?

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

> > 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.
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 
> neither of these schemes work.  Period.
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:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg