Subject: [Asrg] HashCash

From: [email-masked]
Date: Wed, 28 Apr 2004 15:06:59 -0500

> How about figuring out a robust hashcash and signature mechanism, and 
considering how well it would work, including the possibility of third 
parties selling hashcash as a form of decentralised e-postage.  There's 
already some work in this area, which can be built upon, but a summary 
of this would be useful.

> Oh, and I think I've figured out a way to do signatures without 
involving the message content (which is liable to change in transit 
under various circumstances).  It ties in neatly with hashcash.  :)

> Simply put, since the hashcash must be unique per message, do the 
signature on the hashcash rather than the message itself.  For messages 
which don't require high-value hashcash due to whitelisting, generate a 
trivial (say 8-bit) unique hashcash and use that for the signature.

Hashcash and signatures are non-starters (or deserve to be) for the simple and 
immutable reason that compromised spambot zombies will pump out large numbers of 
hashcash-certified, signature-carrying spams.

AGAIN, THIS DOES NOT SOLVE THE PROBLEM.  It only makes the system more 
complicated and expensive.

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: Thu, 29 Apr 2004 05:47:36 +0100

> complicated and expensive.

I don't buy this argument, because the "large numbers" of mail will be 
significantly smaller than the "massive numbers" we're seeing today.  
Instead of each zombie being limited only by it's pipe, it'll be 
limited by it's CPU, so the resource pool available to spammers will be 
orders of magnitude smaller than it is today.

Since when is that such a weak argument?

I added the idea of a simple signature because it's clear that PGP and 
S/MIME haven't taken off - so are they too complex and/or intrusive for 
Joe User?  We need *something* to whitelist against.  Each signature, 
incidentally, will be valuable only for the number of recipients who 
have whitelisted it, which for Joe User will normally be quite a small 
window.  The signature will not say anything about the contents of the 
message, merely where it's stamp came from.

Once a machine has been compromised, of course, it needs a new signing 
key after being cleaned up, but that's easy to arrange.

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

---

From: [email-masked]
Date: Thu, 29 Apr 2004 01:06:54 -0500

>I don't buy this argument, 

Hey, suit yourself.

>because the "large numbers" of mail will be 

I don't think that's assured.

>orders of magnitude smaller than it is today.

The statistics recently reported regarding spammer zombie recruitment pointed 
out that spammers tend to favor using more recently recruited zombies, since 
those are less likely to be filtered yet.  But as the "burst rate" of each 
zombie is reduced, it's likely to not be detected and filtered as quickly... so 
spammers might find that they can use each recruited zombie longer.

Anyhow, the rate of recruitment continues to accelerate.

I really don't believe that the solution to the spam problem involves making 
E-mail harder or more costly to send.  I think a much better solution involves 
making it (if unwanted) *far* less likely to actually be delivered... such that 
the spammer realizes that the effort is probably futile.

Likewise, we HAVE to work on cutting down the ease of zombie recruitment, and I 
believe that my attachments (and HTML!) permissions list idea (basically a 
fine-resolution whitelist) is a *major* step in the right direction there.

>Since when is that such a weak argument?

Well, maybe always, in part since it ignores the very legitimate needs of 
organizations like Yahoogroups and other major outbound mailers to send millions 
and millions of pieces of mail a day.

What determines whether a piece of E-mail is wanted or not (and whether it's 
spam or not) is NOT whether it got sent out in large quantities, or whether the 
sender paid or not to send it, or even who sent it out.  What determines whether 
it's spam or not is whether the RECIPIENT wants it and authorized the sender to 
send it to them, and whether the content of the mail is remotely like what the 
recipient(s) expect and want to receive from that sender.

>Joe User?  We need *something* to whitelist against.  

Why do you think that it's not enough to simply use the E-mail characteristics 
(type of content, HTML classes used, type of attachments, size maybe) in 
combination with the sender and the list of permissions granted to that sender 
by the recipient?  And if you DO want something more, why is a "passcode" or 
something freely made available by the recipient (perhaps in large number of 
variant forms, so to make life difficult for address harvesters) and included in 
(say) the Subject or a special header line perhaps, not enough?

Again, do note that unanticipated/unwhitelisted E-mail (presuming that it does 
not include HTML or attachments, which would immediately t-can or at least 
reroute it, for example during the breakin period) would also need to be vetted 
by some kind of SpamAssassin-like antispam content filter prior to presentation 
to the addressee.

> Each signature, 
>window.  

So what happens if they HAVE NOT whitelisted it?  I think that many (most if not 
all!) types of users NEED to have SOME kind of way to receive legitimate, 
unanticipated E-mails (consumer feedback to manufacturers, people responding to 
the business card they have from you, etc etc.)  Obviously they don't want those 
to be spam.  My solution to this is that those E-mails have to be plain ASCII 
text (and therefore _much_ more effectively content-filtered, and much less 
likely to contain malicious content).

>The signature will not say anything about the contents of the 

Again, I think this is fairly useless because when it comes to spam/virus/worms, 
the CONTENT of the mail (in conjunction with who it came from, perhaps, and the 
express wishes of the recipient in that regard) is the ONLY thing which truly 
guarantees whether it's spam/virus/worm or not.

Signatures, like E-postage, SPF, and all these other schemes, are really 
solutions in search of a problem.  THAT is the REAL reason why PGP never caught 
on... it simply was too complicated and too much hassle to use it, and most 
people simply didn't think it was worth it.  To now try to pretend that each of 
these "pet solutions in search of a problem" is the key to the spam problem is 
like claiming that attacking Iraq is the key to the international war on 
terrorism... in each case, someone with a vested interest is trying to impose an 
agenda on the rest of the world that has nothing to do with the problem they're 
proposing it for, just because they're trying to twist strong concern over the 
problem into support for something else that's truly unrelated.

>key after being cleaned up, but that's easy to arrange.

I think my solution is better here, too.

If a machine is compromised and suddenly starts sending spam, the spam is most 
likely **immediately** blocked simply because it no longer "looks" like what the 
recipient expects to receive from the sender it's coming from.  Now it "looks" 
like spam.  You don't have to "arrange" anything new at all.

If I suddenly get an E-mail containing an executable attachment from one of the 
newsletters or Yahoogroups discussion lists I subscribe to, it's virtually 
GUARANTEED that it's bogus.  I could care less whether it's got an E-stamp on 
it, or has a "certificate", or whether the sender thought about it a long time 
before sending it, or anything else.  I can tell based on what it is and who it 
claims to be from that it doesn't look like what that person sends to me.  
Therefore, I don't want it.

If I get a message claiming to be from a newsletter company, and that I happen 
to know includes HTML formatting codes in their messages, if I suddenly find 
that it comes in and uses ActiveX or scripting, then that's clearly not within 
the purview of what I expect from that sender.

If I get an E-mail from my clueless Aunt Millie ([email-masked]) I might expect 
it to have that stupid AOL-style formatting BS, and she might even send me a JPG 
now and again, but if suddenly I get a message from her containing a .PIF 
attchment or that contains HTML hyperlinks, or something like that, I can be 
pretty confident that my dear sweet aunt didn't originate it.

Or for that matter, maybe this is someone I gave a business card to on a cruise 
ship several years back and they're finally getting back to me about something 
they ran across that might be interesting.  I'm probably glad to hear from them, 
but if I'm out of town this week (maybe on a cruise again) and their (inept?) 
message is going to chew up 95% of my ISP-provided Inbox, then chances are 
pretty good that I'd rather not receive it and have the rest of my E-mails 
bounce all week long until I can get back.

Who really cares about signing keys, or certificates, or all these SPF-like mods 
to DNS which don't solve the problem, or E-postage and all the new opportunities 
for fraud, abuse, extra costs and hassles?  I sure don't.  All I'm concerned 
about is dumping spam in the trash so I don't have to deal with it.

I don't see any point of E-mailing back (to who?  AS IF there were a real return 
address!) and telling them what to do to get past my checks!!??  Riiiiiiiight.  
No, a big part of the whole key to this thing is that the legitimate senders 
know that their current behavior is acceptable (perhaps JUST!) and that they may 
run into problems if they stray too far from that standard (and different 
recipients may have set their filters and permissions standards for the same 
material VERY differently!).  Even if one of those familiar senders WERE to get 
zombie-ized, the fact that suddenly they're not behaving (SOMETIMES!) the way I 
expect them to behave is enough to cause the irregular mail to be zapped, EVEN 
THOUGH the real stuff they still occasionally send me legitimately will still 
sail through to me just the way it always has.

A spambot zombie probably won't be able to guess what the rules are to get mail 
through to given recipients, and just because the machine they've overtaken has 
lots of permissions... for SOME folks... won't help at all for e-mailing to 
other people, or for mailing (even to the SAME people!) different types of 
stuff.

AND for the case (the typical case) where the sender is only sending plain ASCII 
text, without attachments, then NO amount of HTML-obscured deviousness or 
scripted decryption or misrepresented hyperlinks or seductive ruses to try to 
get the recipient to decode and launch some evil attachment is going to get the 
spam or virus or worm stuff past my permissions list.  It's simply as futile as 
arguing with a vending machine about the change it gave you (or didn't).  Those 
bogus things simply disappear down a black hole, giving the spambot (or the 
spammer controlling it) no indication at all about what it might more profitably 
try for the next time.

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 29 Apr 2004 08:22:32 +0100

> I don't think that's assured.

Please justify this statement.  I've taken some numbers provided by a 
poster, and indicated the difference in the quantity of resources 
available - even assuming the spammers can use a significantly larger 
fraction of their zombie pool to make stamps than send mail.  I'll even 
summarise here:

At present, spammers use fresh zombies for an average of 4 days after 
infection - this pool is about 100,000 machines at present.

The total zombie pool is about 1,500,000 machines at present, depending 
who you ask and how they collected their data.  This is about 15x the 
number of active spewers.

Assumption:  It presently takes about 4000 times as long for a typical 
zombie (1.0GHz P6 or K7 class CPU with a 128Kbit DSL uplink) to mint a 
20-bit hashcash stamp as to send out an unstamped, 5KB mail.

Given that spammers can recruit the entire horsepower of their zombie 
army, compared to only a fraction of the bandwidth, this still marks a 
reduction in overall spamming capacity of about 200 times.  And this 
assumes the zombies' CPUs aren't being used for anything else, such as 
games.

> fine-resolution whitelist) is a *major* step in the right direction 

How is your proposal incompatible with mine?  I can't see any 
particular way.

Just for reference, I turned up the score for MICROSOFT_EXECUTABLE in 
my SpamAssassin filter long ago.  Now I don't get any of the usual 
viruses, but I get the encrypted ZIP archives instead.  I'm sure 
SpamAssassin could easily be modified to handle everything you propose 
- so why don't you talk to them instead of shooting me down all the 
time?

> and millions of pieces of mail a day.

Did I say that every piece of mail needed a 20-bit hashcash stamp?  No, 
I said that whitelisted senders get to use smaller, even 
computationally trivial stamps.  Subscribing to a mailing list should 
include making a whitelist entry at each end of the transaction.

I also said, at some point, that if a message is addressed to a mailing 
list and the stamp matches the mailing list's address, then if the 
recipient is subscribed to the mailing list he should accept the stamp 
as valid.  This caters for listserv software that doesn't (yet) 
understand stamping, signatures and whitelists.

Here's my point, since you seem to have missed it up until now:  
Hashcash and signatures work in concert!  One covers some situations, 
the other covers the rest.  Please stop taking them in isolation to 
make straw men.

> What determines whether it's spam or not is whether the RECIPIENT 
> wants it and authorized the sender to send it to them, and whether the 
> content of the mail is remotely like what the recipient(s) expect and 
> want to receive from that sender.

Content filters only work to a point.  SpamAssassin actually has 
filters set up to detect most content-disguise mechanisms already - 
stuff like an excessive number of HTML tags, FONT COLOR="white", etc.  
Spam *still* gets past it occasionally.

As for whether the recipient authorised the sender...  without any 
widely deployed authentication mechanism, how do you avoid spoofing on 
the whitelist entries?

> by the recipient?

Because we already have that general type of filtering, and it isn't 
working well enough.

> And if you DO want something more, why is a "passcode" or

Because that's too much effort for most users - it's "intrusive".  I 
have seen people using it, but they're distinctly in the minority.

>> Each signature, incidentally, will be valuable only for the number of 
>> recipients who have whitelisted it, which for Joe User will normally 
>> be quite a small window.
>
> unanticipated E-mails...

Then they mint hashcash for it.  It only takes a few seconds of CPU 
time for most people.  If they happen not to have the CPU resources 
available to do it themselves, they have the option of paying a third 
party to do it for them.

The signature is merely a way to bypass the CPU expenditure for regular 
correspondents - friends, family, regular business contacts, mailing 
list subscriptions, etc.  Nothing more.

> about is dumping spam in the trash so I don't have to deal with it.

Then implement your filter for yourself.  It sounds like something you 
can implement and gain benefits from on an individual basis, so you 
shouldn't really have any trouble with it.  If it works for you, come 
back and tell us about your experience.  But don't just pan everyone 
else's ideas while your own is still theory.

---

From: Philip Miller <[email-masked]>
Date: Thu, 29 Apr 2004 11:22:54 -0400

Gordon,
I'm just going to pick out a few little points here about how LMAP is
complementary to your permissions system. Note that I agree with the general 
principles of least privilege for email senders.

1. Reducing zombie population

> Likewise, we HAVE to work on cutting down the ease of zombie recruitment,
> and I believe that my attachments (and HTML!) permissions list idea
> (basically a fine-resolution whitelist) is a *major* step in the right
> direction there.

I agree with you here. This goal is very compatible with implementing an 
LMAP system, because it means you have an authenticated ISP to send 
(automated) complaints and abuse reports to, and if they're on the ball, the 
user part will have been authenticated by them, so it becomes a matter of
economics for them to clean up their network, to reduce complaints or to
avoid black-listing because they are abusive to the Internet as a whole.

2. Preventing forgeries getting you infected

> Even if one of those familiar senders WERE to get zombie-ized, the fact
> that suddenly they're not behaving (SOMETIMES!) the way I expect them to 
> behave is enough to cause the irregular mail to be zapped, EVEN THOUGH 
> the real stuff they still occasionally send me legitimately will still 

If one of your legitimate correspondents catches a virus, there are a couple
things that could happen. If they send you a mail directly, odds are it gets 
blocked by your ACLs. But imagine that the virus instead forges all of the 
N^2 combinations of To and From using the addresses in the infected users 
address book. There a chance (however slim) that you have a common 
acquaintance from whom you'll accept an email that will infect you.
Now add authentication back into the mix:
If the 'vulnerable from' happens to be in another domain, the message will
be rejected at the recipient edge MTA as forged. If it's in the same domain 
as the already infected person, then the ISP should be authenticating it.
Looks like a win-win proposition to me.

3. Sending back bounces to legitimate senders telling them that they were
out of line.

> I don't see any point of E-mailing back (to who? AS IF there were a real
> return address!) and telling them what to do to get past my checks!!??
> Riiiiiiiight. No, a big part of the whole key to this thing is that the
> legitimate senders know that their current behavior is acceptable 
> (perhaps JUST!) and that they may run into problems if they stray too far
> from that standard (and different recipients may have set their filters

With LMAP, this works better. You will have a validated return path to send 
a bounce back to, even after the message has been delivered locally. Thus, 
if one of your legitimate senders just steps over the line (maybe attaches a 
JPG that's 1K over what would have been tolerated), they'll get a bounce
saying it wasn't delivered, rather than wondering why you never responded.

Philip Miller

---

From: [email-masked]
Date: Thu, 29 Apr 2004 13:17:49 -0500

>assumes the zombies' CPUs aren't being used for anything else, such as 

1)  The reason the zombie pool is "only" at 1.5 million machines is largely 
because that number is largely sufficient for spammers needs.  If they needed 
more, they'd infect/recruit more.

2)  The zombie pool is clearly not cranking out spam at anything like its 
potential capacity... even the last four days worth of infected machines are 
probably not producing spam at anything like their total capability.

>How is your proposal incompatible with mine?  I can't see any 

It doesn't HAVE to be mutually exclusive to make hashcash a bad idea.

>viruses, 

And that's fine, but it goes back to the not-fine-grained approach that my 
proposal specifically doesn't use... where these values would be individually 
specifiable by a given recipient for EACH SENDER.  I *do* happen to occasionally 
want to receive executable attachments... it's just that they're from a VERY 
small percentage of my correspondents, and the receipt of the executable 
attachments is NEVER unexpected.

>but I get the encrypted ZIP archives instead.  I'm sure 

Sure, as could any kind of good E-mail filter.  SpamAssassin is fine, 
functionally speaking (it would have been (probably MUCH) better if it had been 
written in SPITBOL, but that's another story).  SpamAssassin is a good step in 
the right direction (and perhaps the best thing of its sort out there today).  I 
don't happen to think it's good enough, AND I think that most of the protection 
against spams/viruses/worms, to be meaningful and effective worldwide, needs to 
be BY DEFAULT... thus built in either to the OS, or the mail client software 
(say, Outlook/Outlook Express/etc) that "most" people use.  And not an 
independent addon program, which is unlikely to be widely used enough to be as 
effective as this kind of thing wants to be.  (My approach DOES _immediately_ 
benefit those adopting it, but in order to really make a difference in spam we 
see on the net worldwide, a lot of people should be using it.)

Clearly, though, you're right in that SpamAssassin needs to be able to treat ZIP 
archives (and with or without encryption) as "dangerous" and as one of the 
available filter criteria.

>- so why don't you talk to them instead of shooting me down all the 

The people who I'd *like* to see[/help them] solve the problem would be 
Microsoft, since if they solve it at their level then truly a *large* number of 
folks around the world will benefit from the improvement.

As for shooting you down all the time, please don't take it personally.  There 
are a lot of people pushing for a lot of harebrained and ultimately 
not-very-clever "solutions" for these problems, and most of the ideas simply 
aren't very good.  Before we go off halfcocked racing down a path to a future 
that isn't very well thought out, we need to ALL consider these proposals and 
EVERYONE try to foresee what's wrong with them.  Otherwise, we're going to go 
way far down a road towards a costly, unworkable "solution" which is going to 
leave everybody wondering "What the hell were those guys thinking?"

We should be able to do better than that.

>include making a whitelist entry at each end of the transaction.

I don't like that.  First, because I don't think the sender should have to do 
ANYTHING different on a recipient-by-recipient basis (other than, perhaps, 
deciding who will tolerate bulky HTML-burdened E-mail (that's if the sender 
REALLY wants that kind, rather than just using ASCII) and who wants plain ASCII 
text instead...)  I don't like two-ended solutions, since it invariably seems to 
involve coordinating things that end up being hard to coordinate, and ends up 
forcing mutual concurrence on things where it's often hard to get agreement.

Secondly, it means that the recipient has to whitelist a *lot* more of the 
senders that they get mail from than they should have to whitelist.  If you have 
a reasonable policy for default mail permissions, then most of the senders you 
get mail from (even unexpectedly) shouldn't be affected by your filter.  The 
goal of my scheme is a fine-grained sieve putting the RECIPIENT in control, and 
which lets as much of your legitimate mail as possible through but which turns 
aside virtually all the spam, and without significant negative implications on 
legitimate and responsible senders.

And, all this without having to change the basic worldwide Internet E-mail 
infrastructure, or significantly increasing the fixed/incremental cost of that 
infrastructure.

>understand stamping, signatures and whitelists.

But you presume that everyone SENDING to that mailing list is going to go along 
with your "stamp" and signatures proposal and deal with the hassles, right?

Again, I don't much like proposals that force EVERYBODY around the world to 
change their behavior.  And it's bad enough when it's TWO people that e-mail 
each other directly;  it's much worse when you have third parties (like 
Yahoogroups) involved and you end up creating this kind of great scism between 
communities.

>the other covers the rest.  Please stop taking them in isolation to 

Both of them require components to be installed EVERYWHERE, both to generate 
them and to check for them.  I don't object to multifaceted solutions (hey, I 
specifically endorsed a SpamAssassin-like content filter working in conjunction 
with my permissions lists.)

But if I don't like attempts to increase the cost of mailing by hashcash, and 
don't like cumbersome "signature" or "certificate" approaches, I don't know why 
you'd imagine that I'd like a solution better that involves the combined 
disadvantages of EACH of those. 

>Spam *still* gets past it occasionally.

Sure.  But in conjunction with my permissions lists, there will be many fewer 
ways to deceive and bypass it, while still getting the things through that you 
occasionally need to receive from SOME selected few of your correspondents.  
Presently, setting your filter settings tight enough means that you're filtering 
out some stuff that OCCASIONALLY you need and want to receive from SOME folks.

I don't suggest that SpamAssassin is perfect.  It *looks* pretty good.  It would 
be *better* if it didn't have quite such a difficult job to try to do (and my 
permissions list makes its job a LOT less daunting).  If SpamAssassin were 
written in SPITBOL, they'd have far more powerful pattern recognition 
capabilities available to them at the core programming-language-level, and it 
would be a lot harder for spam to slip past it.

But I also don't think that the spam filter HAS to be absolutely 100% effective.

It's probably enough that the spam problem is reduced to an occasional nuisance.

It's perhaps true, though, that by the time we t-can that much of the spam, 
combined with making it MUCH MUCH harder to recruit spambot zombies, that a lot 
of the spammers will simply go look for more promising ways to pursue their 
scams.

We haven't seen the worst of spam, yet.  But eventually the tide will crest and 
we'll start seeing an improvement.  

>widely deployed authentication mechanism, how do you avoid spoofing on 

Spoofing only helps if the permissions assigned by a given recipient for the 
sender you're spoofing helps you send the stuff you're (as a spammer) trying to 
send.  In general, you simply don't know that it does... you don't know WHO you 
want to spoof, and you don't know WHO has assigned them the "advanced" 
permissions that apparently you're hoping to benefit from.   If ultimately the 
majority of recipients have VERY few people with advanced "whitelisted" 
permissions, then your odds of hitting one at random are very small.

>Because we already have that general type of filtering, and it isn't 

No.

1)  We don't have that on the basis of a sender/recipient pairing;  

2)  We don't have the kind of fine-grained control based on the types of HTML 
codes present and the types of attachments in use;

3)  Gratuitous HTML provides a lot of underbrush for spammers and abusers to 
hide in.  Far too many people presume that they can send HTML mail and that it 
will be unquestioningly accepted by "everybody".

4)  Far too few people have even the "general" kind of filtering that you're 
talking about implemented.

Even if *I* implement completely all of my ideas, and use them here, the fact 
that they only help ME is still going to run afoul of your "it isn't working 
well enough" condemnation.  

There are a variety of commonly recurring types of spam that still make it 
through my present incoming mail filter.  In part that's simply because it's 
small enough in volume (so far) that I haven't busied myself to make the 
appropriate improvements to the filter to detect and t-can those types.

>have seen people using it, but they're distinctly in the minority.

It's certainly less intrusive than having to buy E-postage or computing 
"hashcash".  And this would work with basicaly all existing E-mail programs.

I do agree though that I like single-ended solutions better in principle.  (I'll 
point out that, unless I'm mistaken, NONE of the other solutions we've been 
discussing here are single-ended, other than my permissions list idea).

>available to do it themselves, they have the option of paying a third 

Again, complicated and it increases the cost, while not solving the problem.

Besides, anything keyed to "consuming processor time" is inherently a decaying 
thing, as processor speeds increase.

>list subscriptions, etc.  Nothing more.

Signatures require a concurrence at both ends on the type of signature to be 
employed, and much existing E-mail software (including embedded apps that 
generate and send E-mails) obviously don't generate mail containing them.

Again, you're talking about changing the world's E-mail infrastructure.  
Possible, maybe, eventually, but not right away and not without a lot of grief 
in the meanwhile.

>Then implement your filter for yourself.  

Fine, and I've done much of that.  As I said, I continue to refine my filter... 
I'm currently up to revision 1.43 (since 2002 when I first wrote and started 
using it) and in general it works pretty well.  The present filter is 1742 lines 
of (fairly heavily commented) 32-bit SPITBOL source code.  (It does a LOT more 
than just antispam filtering).  It works in conjunction with a couple of 
"helper" apps and a variety of data files (including dictionaries) and produces 
a variety of log and audit trail files.  The current version was written with 
multiuser features to support enterprise use, although nobody except me is 
presently using it on a daily basis.

>It sounds like something you 
>can implement and gain benefits from on an individual basis, 

Can, have, and do!  :-)

What I presently have here doesn't fully implement my proposal, but that's 
because it's presently "close enough" to solving enough of my own personal spam 
problem that I don't feel a pressing need to implement the rest (not for myself, 
anyhow).

The framework I have would probably support all of the things I'm talking about.

>so you 
>back and tell us about your experience.  

That's largely why I'm here.  :-)   I've been observing the problem for a long 
time, and particularly in the context of seeing what I already have and what 
things one could do to pick up on the remaining "problem" spams.

>But don't just pan everyone else's ideas while your own is still theory.

I think that:

  1)  My ideas are a LOT more than just "theory".

  2)  My ideas hardly require any kind of dramatic technological breakthroughs 
that would call into question their implementability.

In fact, of the ideas being discussed here, mine involve a whole let less 
"waving of hands" and "blue-skying" than hashcash, OR E-postage, OR signatures, 
OR certificates, or global changes to the Internet's DNS infrastructure, or 
indeed just about any of the other ideas that we're discussing.

So I think it's pretty silly to condemn anybody's ideas here as "just theory".  
By definition, this is an "asRg" and the R stands for RESEARCH!

---

From: [email-masked]
Date: Thu, 29 Apr 2004 15:41:20 -0500

>principles of least privilege for email senders.

Thanks!  I'll reply with my comments on the items you've noted.

>I agree with you here. 

Thanks.  I think this is simply the BIGGEST improvement that can be made the 
FASTEST to solving this TERRIBLE problem.

>This goal is very compatible with implementing an 

Well, sort of.

I wouldn't say it's "very compatible with"... the way I'd characterize it is 
that WITHOUT a fine-resolution whitelist to block virtually all executable 
attachments and other malicious E-mail content, that LMAP and its ilk are fairly 
useless (as, indeed, are most of these other ideas such as E-postage, 
certificates, SPF, and the like)... simply because spambot zombies mean that 
actual spammers never pay E-postage, generate hashcash, deal with stamps or 
certificates, or deal with any of these other restrictions that supposedly are 
being designed to put a crimp in their operations.

The question then becomes... once the permissions list solves the great majority 
of the zombie spambot problem, and removes most of the HTML deceptions, and 
antispam content filters resolve most of the rest... how much of a problem 
really still remains, and would it justify the time, hassle, and expense of 
these more intrusive, controversial, and costly schemes?

As for finding the right person to complain to... I still send complaints to the 
various Nigerian/lottery spammer ISPs, and although I'm sure I'm not the only 
person griping about it, and although CLEARLY there's no question about who is 
hosting the fraudster's E-mail boxes, the same small number of ISPs keep getting 
implicated with disturbing regularity.  So I'm less convinced than you seem to 
be that flooding them with automated complaints and abuse reports really 
accomplishes anything;  it seems that their own defensive automated 
abuse-report-discarders are just as efficient!  :-(

Ultimately, most of these abuse reports and complaint letters (and the ISP's 
automated responses to them) just make the "wasted bandwidth" problem worse than 
if the original objectionable material just went down a black hole.

>acquaintance from whom you'll accept an email that will infect you.

First, basically *no* E-mails will infect me, simply because my preferred E-mail 
client doesn't encourage that to happen.  But I've seen a lot of infection mails 
arrive here, and I've investigated them enough to see how other folks get 
infected.  :-)

The fact is that the great majority of people simply have no reason to EVER 
whitelist ANYBODY to send them an EXE file type as an E-mail attachment;  fewer 
still would whitelist ANYBODY to send them a PIF file.  Few people similarly 
ever need to accept an encrypted ZIP file!  Secondly, the likely overlap in the 
E-mail address books (regarding people I'd be likely to whitelist to send EXEs) 
is likely to be the null set, or pretty close to it.

And even THOSE people I'm not likely to accept unexpected/unsolicited 
executables from.  (Obviously, Outlook or whatever E-mail client wants to make 
it VERY ominous-sounding before they let anyone turn these permissions on... so 
people won't let themselves be hoodwinked or wheedled by a bogus E-mail that 
tries to talk them into dropping their shields.)

So anyhow, I think that your scenario is VERY VERY farfetched.

>be rejected at the recipient edge MTA as forged. 

...And that is a BIG "if".  Especially now with Internet accesses concentrating 
around a relatively small number of big players... Comcast, SWBELL, SBC, AOL, 
etc etc.  And in fact, that's a big reason why the "domain-approved authorized 
mail server IP address" concept (regardless of which variant you're talking 
about) is so terribly flawed (aside from the issue regarding personal domain 
names, mailing lists, etc etc).  There are literally MILLIONS of SBC users, 
MILLIONS of Comcast users, close to ten million AOL users, etc etc.  So someone 
infecting an SBC or Comcast user's machine can forge any of a million or more 
other addresses which will NOT be detected by these schemes as forged.  And 
that's true even if they originate the mail from one of hundreds of other mail 
servers used elsewhere nationwide by that big ISP.

>If it's in the same domain 

Some do, some don't.  Again, SMTP authenticating becomes problematical when 
people are using their own personal domain names, mailing lists, etc etc.  Many 
ISPs refuse to let people forward mail to their domain name supplier's mail 
servers, etc.

>Looks like a win-win proposition to me.

And if you ignore the folks who lose big, you'd almost be right.

>a bounce back to, even after the message has been delivered locally. 

You're presuming (and this is NOT necessarily a valid presumption) that the SMTP 
and POP mail paths are parallel and coherent.

Not everybody uses the same outgoing mail path as they use for their incoming 
mail path.

The other question is to decide if it even makes sense to try to send the 
bounce.  I'm not at all sure that it does.

>Thus, 

If they write me and inquire, I can probably tell them I didn't get it.

And remember that (depending on what they sent me) it's entirely possible that 
the BOUNCE ITSELF will be filtered out by THEIR permission list, since it's 
entirely possible that the 'mailbot' sending the bounce won't be whitelisted at 
their end, either.  :-)

(This can occur even today... let's say that they send me an E-mail which is 
4.9Mb, and by the time the various Received: headers are added it JUST exceeds a 
5Mb maximum E-mail supported by my domain supplier.  If they try to bounce it 
back along with an explanatory header, chances are good that the ORIGINATING 
E-mail inbox won't accept it, either.  Or, they might already have 3.5Mb of mail 
queued there already, and doesn't have adequate room to hold the bounced mail.  
Anyhow, you can't always guarantee that a bounce will be received.)