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

From: [email-masked]
Date: Mon, 26 Apr 2004 12:19:39 -0500

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

Thanks.  The biggest problem with unrestricted sending is that one's inbox fills 
up and mail starts bouncing.  THAT creates HUGE problems for (at least many) 
people.

> ...but it can already be handled without extra standards.  

Sure, and my solution doesn't really require "standards" either, since by its 
nature it is single-ended.

> Perhaps someone could write something to hook into procmail, and/or write a 
BCP.

I guess I really need to find out more about BCP documents.  What does it take 
to write them, is there a particular format they must adhere to, and where must 
they be submitted for review/distribution/archiving/etc?

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

And that implies that the ISP treats E-mail as a special case, and/or forces 
originators within their network to use the ISP's mail servers (which many of us 
REALLY do not want to do).

In my case, for example, I'd really rather use the mail server provided by 
DomainDirect (my domain provider for terabites.com, and indeed for all the 
domains I provide for my consulting clients) rather than the one provided by 
comcast.net.  It simply looks more professional to have my server be 
"mail.terabites.com" or "smtp.terabites.com" than "dfw.comcast.net" or whatever.

And of course, there's also the issue about braindead SPF-type schemes which try 
to FORCE users to use mail server IP addresses which are coherent with the From: 
address... if I'm going to use my terabites.com E-mail address, then I would not 
be able to do that from my comcast.net-provided SMTP server.

One interesting-sounding alternative approach is to MAKE SURE that any Web site 
being promoted by the spam gets LOTS AND LOTS of hits... for example, by having 
EVERY recipient of the spam auto-generate hits against the Web sites being 
promoted.  (The result is essentially a DDOS attack against the spammer's site!) 
 The problem with that approach, as fun as it initially sounds, is that it's far 
too easy for the spammer to use that mechanism to "joe-job" someone else.

> Which isn't happening, in general.  

And for a number of good reasons, including that in general they don't have any 
ready way to control what is and isn't E-mail... and to decide what you count 
and what you don't.  Do copies count as much as original destination addresses? 
 How about bcc copies?  What about mails sent to forwarding services or mailing 
lists (or zombies, for that matter)?  It's ultimately pretty easy to evade such 
schemes.

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

It's very hard to deal with in any definitive way.  How do you distinguish 
whether outgoing mail from a normally-reputable system is really still 
legitimate?

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

That, plus they simply decided that it was silly for them to use their OWN 
resources for spamming, when it was so easy to steal resources from other 
people.

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

Well, not really.  

A salesman who hands out thousands of business cards a year (or a company which 
posts a customer service e-mail address on the labels of their products) is 
EXPECTING to get mail from people they haven't whitelisted... just as publishing 
your telephone number in the phone book is done PRECISELY SO THAT you can be 
called by people you haven't given your phone number to, personally (and thus 
'whitelisted').  Normal whitelisting schemes generally don't allow you to get 
mail from people not yet on your whitelist.  Blacklisting IP addresses, on the 
other hand, allowed us to block known-bad open relays and other familiar sites 
that spammers were massively misusing.

This fixation on "authentication" and forged From addresses is really dumb 
because it really does NOT solve the problem.  (NEITHER the spam problem NOR the 
worm/virus problem).  It's really just a diversion chewing up a lot of 
engineering time and standards committee effort which ultimately isn't going to 
be effective for the stated purpose.

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

Most spammers are NOT casual "script kiddies" working out of their dorm room 
just on a lark.  Hackers, maybe, are of that ilk.... but not spammers.  Spammers 
are generating REAL MONEY by their antisocial behavior, and are plenty ready to 
use any techniques they can to continue doing so.  It took concerted, ongoing 
court actions over many years to put Spamford Wallace out of the business.  

I still contend that Macs and *nix boxes are generally just as vulnerable, and 
are only "safer" because they're less numerous and thus less attractive targets 
for spammers and hackers to go after.

> While the Mac and Linux are not perfect, they do lack many of the 
fundamental design flaws that make Windows such a soft target.  

Microsoft has gotten the message, and their new systems are going to be 
substantially harder to break into.  We're just starting to see the results of 
those changes.

Regardless, the fact is that the ultimately secure system has never been created 
(despite billions of dollars spent by the military over several decades trying 
to do so) and if we ever DID create such a beast, it probably wouldn't be good 
for much of anything.

> Linux MUAs are largely incapable of creating an executable file on their own, 

Who or what says the MUA has to do it?

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

Mac and Apple are largely RESPONSIBLE for much of the problem.  They are the 
ones who created and pushed the idea of hiding file extensions and file types, 
and for dumb users to "just click on everything" [blindly!] to make it do 
something.

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

One major move towards getting rid of them, as I've stated repeatedly, is to 
restrict (by default, at least) incoming attachments (by several classes of risk 
and danger) to only specified, recipient-approved senders.  That would (at a 
minimum) virtually eliminate E-mail attachments as a vector for spambot zombie 
worms, since the great majority of recipients probably wouldn't accept 
executable-type attachments from ANYBODY AT ALL.

> If the resource being leeched is controlled by a third party, however, 
it's easier to monitor and take action on suspicious behaviour.  

That's like saying that there ought to be somebody (FBI?) monitoring and 
pursuing stuff like Nigerian spam.  If there really were, then why in the hell 
does this crap keep going and going?  Why don't they round up these scum and put 
them all out of business?  There can't POSSIBLY be THAT many of them.  The fact 
seems to be that the third parties that are supposed to be protecting the public 
simply are NOT doing their job.

> This is why e-postage can be helpful - as I mentioned immediately 
afterwards, the compromised account will quickly run dry.

As has been repeatedly stated (and just as repeatedly ignored) there is NOTHING 
about E-postage and requiring money and payments that can't be achieved without 
money or payments entering into it.

For that matter, you could even GIVE away the "stamp" that the sender would need 
to use.  For instance, when you give someone your E-mail address (at your Web 
site, on your business card, whatever) simply tell them to "put 17XyZ in the 
subject line somewhere, otherwise your mail won't be delivered to me."  Everyone 
would present the key in a different way, complicating address (and key!) 
harvesters.  This could then be used in conjunction with a permissions whitelist 
such as I've proposed... you can whitelist people (mailing lists, for example) 
that don't need to include the passkey, but non-whitelisted senders (that still 
could be restricted against sending HTML-burdened mail or attachments of various 
kinds) might also have to have one of the recognized passkeys in the subject 
line somewhere.

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

That type of "education" is brutal and ineffective.  Ultimately, what happens 
when people run up (via worms etc) thousands of dollars of phone bills to 
Moldavian 900-number dialup accounts is that the phone companies end up getting 
stiffed, but not before they spend hundreds or thousands of dollars worth of 
time trying to deal with the mess.

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

And who do you believe will pay for all of that stuff?  Not the spammers, that's 
for sure.  And when are busy people going to make time to attend those classes? 
 Get real.

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

As do the ones that simply pass on the high costs of these ill-conceived and 
ultimately ineffective "anti-spam" solutions...!

> The *right* approach is to offer advice on how to clean up 
and secure their machine, and how to avoid future infections.  

And maybe a Web site could help teach people that, but there are plenty of sites 
with that information available today and lots of people that just don't find 
it, or care enough to take it to heart.

Meanwhile, ISPs that ought to know better (such as AOL, with perhaps the highest 
ratio of "clueless newbies" of anyone) are among the WORST by virtue of 
promoting the pointless and gratuitous use of HTML-burdened E-mail!!!

> It's not really all that hard, and they could even print a leaflet about it 
with step-by-step instructions.

And who will pay for THAT?  Again, not the spammers.

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

There are more than enough stamps to go around, and plenty of infected zombies 
to "steal" stamps from.

> Once woken up, the victim might be one less person to get re-infected in the 
future, 

Nice thought, but....

> ...so perhaps the endless supply of zombies will get less plentiful in the 
future.  

In fact, experience demonstrates otherwise... people who get infected by worms 
and viruses tend to get infected over and over again.  And this isn't just about 
computing... consider folks in the hospital for life-threatening emphysema, who 
still insist that they have a 'right' to keep smoking.

> At the moment, there's little or no feedback to victims, so they don't 
learn anything.

It's not just a "learning" thing, they have to CARE.  And many, simply, do not.

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

Anything that increases costs and doesn't solve the problems it's claimed to 
solve (or at least comprise a major step in right direction, and without 
significant counterbalancing negatives) is "a *bad* thing", IMHO at least.

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

Do YOU intend to go around cleaning up other people's messes?  *I* don't have 
the time for that, as a general rule.  I do it for my consulting clients, but 
then again THEY *pay* me for that.  :-)

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

You really haven't been paying attention, have you?

There are a number of familiar tricks and evasions that spammers use which 
frustrate and confound antispam content filters.  One of them is 'text as image' 
which would require OCR software or something (at least) to decipher the content 
of the mail message.  Another is obscuring the content by HTML tricks (bogus 
tags, scripted decryption, misrepresented links, font and color tricks, obscured 
non-canonical URLs, and so forth ad infinitum).  

Denying the spammer those tricks and evasions makes it VERY VERY MUCH EASIER for 
effective and practical antispam content filters to do their job.

But also let's recognize that when dealing with the question of antispam content 
filters, "good" might be quite adequate, even if they're not 100% "perfect".  It 
wouldn't really bother me TOO much if a spam or two got through my filter, say 
once a week or once or twice a month.  

And there are a number of apparently "good" antispam content-based filters out 
there.  They will be BETTER once the attachment/HTML issues are resolved.

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

Doesn't have to be perfect.  Most importantly, we need to be able to have 
techniques which evolve as spammers get more devious.  SpamAssassin is a good 
start, at least in terms of what it apparently does (I'd probably be less 
impressed about the language it's likely written in).

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

Sure.

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

I simply think they're (still!) cumbersome and inconvenient, and don't really 
solve the problem.

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

There are SO MANY zombies (and spammers can make about as many more as they 
want) that for all intents and purposes they have no genuine limits to EITHER 
computing power, OR bandwidth.

> So it improves the situation dramatically when compared to the status quo.

So what happens to companies (say, like Yahoogroups) that (legitimately) sends 
out probably billions of E-mail messages a day?

Sorry, I truly don't like ideas that make sending (legitimate!) E-mails 
significantly more expensive.  ULTIMATELY, we LEGITIMATE users have to pay the 
price for that... spammers won't pay it, that's for sure.

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

Sorry, I don't like junk like that.  It's a lot like schemes that used to count 
on slower processors and which then fail when timing loops (say in device 
drivers) time out far faster than they were ever supposed to.

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

You don't have to have stamps or authenticated IDs to achieve that.  All you 
need is a multilevel address scheme, or (barring that) even just the "free 
stamp" passcode thing in the subject line as I discussed earlier.  (A new header 
line would work just as well, if you didn't want to use the subject line for 
it.)

> Without the whitelist, the identification becomes moot, as the filter will 
fall back on other schemes.

We agree that whitelisting and filtering are key parts of the solution, anyhow.

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

So let's say that we stop all forged or bogus from addresses.  BFD.  Spammers 
change (overnight) to use "real" return addresses.  There, are you happy now? 
(Really... THINK about the implications...)  Again, you've probably made the 
problem WORSE, rather than better.

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

That doesn't help unless (1) you know what TYPE of attachments the sender is 
approved to send to a given recipient, _and_ (2) sending that specific type of 
attachment can be used to the spambot's advantage.

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

Actually, probably not.  Most of my correspondents don't send me HTML-burdened 
E-mail, and fewer still send me attachments.  Almost none send me executable 
attachments!  Of those who DO send HTML-burdened E-mail (with my very begrudging 
approval), basically NONE of those use scripting or ActiveX in their E-mail 
messages.

It's very much mistaken to believe that you have to whitelist everyone you 
receive E-mail from.  You apparently don't really understand my proposal.

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

Antivirus programs are based on the premise that you know all the viruses, which 
presumption clearly fails for new viruses.  

> Tell me, how do these fit into your brilliant scheme?  

Very simple.  Since they're potentially carrying extremely dangerous cargo, AND 
since they're very rarely used for legitimate purposes, you either classify them 
like you do executable attachments, or you could create a special attachment 
class for encrypted archives.  Then you'd only receive such stuff from people 
(if any, probably there aren't any) that you had already arranged with and 
whitelisted to send you that type of stuff.

> Don't forget that these ZIP archives are often apparently 
coming from people the recipient trusts, and probably has in their 
whitelist...

You've completely ignored or misunderstood the nature of my whitelist, it seems. 
 Think of it as more than a binary "whitelist", rather more like a "permissions 
list".  Each whitelisted sender would have your approval to send you certain 
classes of mutually agreeable HTML and/or attachments, based upon your 
relationship with that sender.  By default, non-whitelisted senders could only 
send you plain ASCII text E-mails, without any HTML or attachments at all (and 
those would be subject to further limitations, say a maximum "unknown sender" 
size limit and (hopefully!) after having passed a good antispam content filter.

Think of it more like the type of permissions that an NTFS file system 
supports... some users can list the filenames in a directory but not access the 
files, maybe they can't list the filenames but CAN open them (only!) if they 
know the filename already, maybe they can write a file but not read it, maybe 
they can read or write a file but not delete or rename it, or whatever.

The fact that it's so much more fine-grained than a crude binary "whitelist" 
means that you can create a very narrow set of rights and permissions for the 
people you normally deal with, and most spammers or zombies won't understand or 
be able to figure out the rules, and therefore will have a lot of trouble not 
running afoul of them and having their spam output t-canned.

Does that make more sense now?

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: Yakov Shafranovich <[email-masked]>
Date: Mon, 26 Apr 2004 13:51:59 -0400

> they be submitted for review/distribution/archiving/etc?

Since this is an IRTF group, BCPs produced by this group go through the 
IETF standards process which is described in RFC 2026 
(http://www.faqs.org/rfcs/rfc2026.html). The process starts by writing 
up a draft as described here (http://www.ietf.org/ID.html). Approval is 
done by the IESG and finished documents are archived as RFCs at the RFC 
Editor's page.

Details of the BCP process are described in section 5 of RFC 2026. 
Reading the Tao of the IETF helps also (http://www.ietf.org/tao.html 
also published as RFC 3160).

If a given document is within the scope of the ASRG and documents the 
discussions in the group, or is a work of several group members, than 
the Internet draft that is produced can be published under the ASRG's 
name as draft-irtf-asrg-xxx. This requires approval from the chairs.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
-------

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 26 Apr 2004 23:01:27 +0100

> whether outgoing mail from a normally-reputable system is really still

You pick up the phone, and have a brief word with your customer.  If he 
hasn't any idea why his box is spewing a thousand mails a minute, you 
have an opportunity to deal with the problem, starting with blocking 
his outgoing SMTP.  If he *does* know about it, then it's his 
responsibility.

This isn't just hyperbole.  This is roughly how my present ISP, Demon, 
says it handles excessive SMTP output.  This is also how one of my 
previous ISPs alerted me to an inadvertent misconfiguration of my 
website, which was causing a type of DDoS on their webserver via a 
stack of poorly run Squid proxies.

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