Subject: Re: [Asrg] Re: "worm spam" and SPF

From: [email-masked]
Date: Sun, 5 Dec 2004 16:42:26 +0000 (GMT)

> FUSSP: http://www.rhyolite.com/anti-spam/you-might-be.html

OK, thanks.  :-)  It's pretty clear that my proposal really IS that simple, and 
really DOES go a LONG way to solving/reducing the problems of spams, worms, and 
viruses.

I *do* urge the use of a good antispam content filter IN CONJUNCTION WITH my 
proposal.  My proposal, however, *greatly* improves the efficacy of the content 
filter.

>> THE DEFAULT, for unknown/unspecified senders, would be to allow
> through the mesh filter only mails smaller than a specified size
> (say 25K or 50K bytes maybe) which contain no HTML and no
> attachments... thus simple, text E-mails not exceeding the specified
> maximum size.

>> So note that the proposal DOES NOT eliminate HTML-burdened mail,
> nor does it impact ANY legitimate E-mail technology.  It DOES mean
> that UNSOLICITED mail from UNKNOWN senders would need to be sent (as
> it SHOULD be anyhow, since the format is designed for universal
> readability) as small E-mails using only plain ASCII text.

> This is problematic at best. 

Your objections are ridiculous....

> ...Many mail reading programs don't follow standards properly, 

I'm sure that's true, but that doesn't impact my proposal.  First, my proposal 
is TOTALLY controlled by the RECIPIENT, so the recipient can set the filter any 
way they like (hopefully using the same rules you'd use for setting the squelch 
control on your 2-way radio... you want to block the noise while letting through 
all legitimate and trusted transmissions).  Obviously, if you set the E-mail 
"squelch" control to "minimum" then it won't help you much.

But anyhow, the fact that they "don't follow standards properly" doesn't really 
affect my proposal one way or the other.  My proposal should still work, and one 
can set the filter as aggressive (or not) as is appropriate for their situation.

> ...and even try to improve on perceived shortcomings
in the name of robustness. There is never any guarantee that an ASCII
message, sent as ASCII, will actually be displayed as ASCII rather
than some other format which the reading program thinks it can somehow
deduce.

And why, exactly, do you think that makes my proposal "problematic"?

> Any filter of the type you propose must still second guess how all the
major current mail reading programs will interpret ASCII, 

Why do you think that?

>  ....under all their available options, settings and overrides. This is an 
arms race exactly like the current one.

What does "how they interpret ASCII" have to do with my proposal?

It MIGHT have more to do with the proposed ASSOCIATED use of a good antispam 
content filter (like Spam Assassin) but my proposal really has only VERY limited 
need (itself) to interpret the contents of the E-mail, beyond looking at 
attachments and HTML tags.

> Furthermore, typical spam messages are 2-3K in length, well below your
proposed limit. 

Yes, and that causes NO problems for my approach.  I'm NOT proposing that SIZE 
be used to discriminate spam/nospam.  I *am* saying that, along with 
antispam/antivirus/antiworm goals, it ALSO makes sense that recipients be able 
to prevent abusively large messages from being sent to them (and perhaps chewing 
up their limited-size ISP-provided Inbox) from people they don't know and don't 
trust.  (Limiting the size DOES, however, provide an additional way of 
controlling incoming worms (from untrusted/unknown senders), most of which are 
significantly larger than 25K).

> This allows higher throughput at the spammer's end.

Throughput is generally not a problem for spammers and virus authors, since they 
as a rule don't pay for it, or at least they pay for a vanishingly small 
percentage of the total bandwidth their actions cause to be consumed.

> If the first step in your solution, namely blocking emails containing
nasty side effects, is ineffective, 

I think you're misunderstanding my proposal.  Either that, or you seem to be 
misrepresenting it.

> ...then you are simply proposing a highly configurable whitelisting system, 
with all the associated scalability issues.

Certainly it IS a "highly configurable whitelisting system" but with the key 
property that you allow a significant and useful type of "initial contact" mail 
through at least the whitelist part before going into the associated content 
filter.

As for "scalability issues" you don't indicate why you think my approach is 
particularly challenging in that area;  certainly the whitelist portion is not 
particularly resource-intensive (the content filter portion is the more 
difficult part of the two main sections, but even THAT is greatly reduced by the 
reduced need to worry about HTML and other evasions).  

While obviously it would be NICE to have spam filtered out as close to the 
sender as practical, then you get back to all the issues about worldwide 
consensus and all the rest, and I just don't think that's feasible at the moment 
(at least, I'll observe, it certainly hasn't gotten us very far up to now).  One 
of the nice aspects about my solution is that it is ENTIRELY implementable at 
the RECIPIENT end (and they get IMMEDIATE and substantial gratification upon 
doing so), and they probably are not in any significant way inconvenienced by 
the modest resources that my approach would use.  

It would be ENTIRELY possible to implement it entirely within an E-mail client 
(such as Outlook or Outlook Express for example) and wouldn't require ANY 
changes whatsoever from the ISPs or the wider Internet infrastructure at 
large... and because of that, it doesn't really require the issuance of any 
official standards, either... (since in effect the recipient-controlled filter 
ONLY really directly affects THEIR incoming mail) although a "best practices" 
type document might recommend general approaches to use in implementing such 
software, or to perhaps help avoid foreseeable issues or implementation traps 
for the unwary.

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: "Peter J. Holzer" <[email-masked]>
Date: Sun, 5 Dec 2004 18:21:06 +0100

> proposal.  My proposal, however, *greatly* improves the efficacy of the content 

Since your proposal can be usefully implemented on a small scale (unlike
SPF, which will only work if (almost) everybody uses it), a few
questions:

1) Have you implemented it? Is the implementation available?

2) Are you using it yourself? If so, how much much did it reduce the
amount of spam, how much time do you spend tweaking your permission
lists, how many people claim that they can't send mail to you?

3) Have you deployed it at a scale where you couldn't explain it to
everybody in person (E.g., a company with ~100 employees, a small ISP,
etc.)? Same questions as above, plus: How many support calls do you get?

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Laird Breyer <[email-masked]>
Date: Mon, 6 Dec 2004 13:12:03 +1000

On Dec 05 2004, [email-masked] wrote:

>  But anyhow, the fact that they "don't follow standards properly"
> doesn't really affect my proposal one way or the other.  My proposal
> should still work, and one can set the filter as aggressive (or not)
> as is appropriate for their situation.

> What does "how they interpret ASCII" have to do with my proposal?

The problem in a nutshell is this: when your filter receives a mail
and analyses it to see if it contains prohibited content such as HTML
(to take an example), what criteria does it use? If the criteria are
different than those applied by the mail reading program downstream,
then there will be a discrepancy. Either the filter blocks mail when
it shouldn't (which is often called a false positive), or it doesn't
block some mails which will turn out to contain HTML (possibly
malicious) anyway.

There are some standards for when a mail contains HTML and when it
doesn't but they are often ignored by mail reading software, and often
ignored by spammers, and also ignored by legitimate senders depending on
how the programmers who wrote their mail programs interpreted the gray
areas in standards. 

So unless your filter uses the exact same heuristics about when a
message contains HTML and when it doesn't, there will be discrepancy
as above. Either you accept that there will be an amount of false
positives, or you accept that your users will see HTML content even
though your filter thought it only contained plain text.

The only sure way to protect users against HTML attachments is to
prohibit them from using mail software which displays HTML, so at
present if that is your goal for unknown mail, you would certainly
prohibit Outlook, OE, Lotus Notes, etc., and in the future you would
allow those programs if they guarantee to not display HTML, XHTML,
XML, flash, ActiveX, etc.

> It MIGHT have more to do with the proposed ASSOCIATED use of a good
> antispam content filter (like Spam Assassin) but my proposal really
> has only VERY limited need (itself) to interpret the contents of the
> E-mail, beyond looking at attachments and HTML tags.

What you perhaps don't realize is that an attachment marked plain text
but containing HTML tags is often displayed as HTML by mail reading
software anyway. Some software reads plain text, looking for anything that
resembles a web address and generates a clickable URL (thereby turning
the plain text into HTML). Some software accepts even malformed HTML
tags, which aren't considered HTML by any standards.

My point is that when you say "looking at attachments and HTML tags",
you are glossing over a difficult problem, because while ordinary
users tend to produce mail where attachment types and HTML are clear,
spammers purposefully make those aspects as hard to identify as they can,
by exploiting gray areas.

Moreover, you might not realize that SpamAssassin is bundled with 
bulk mail sending software precisely so that spammers can design their
emails against SpamAssassin and tweak them until they pass the tests
performed by SA, and only then start spamming. 

> > Furthermore, typical spam messages are 2-3K in length, well below
> > your proposed limit.

> Yes, and that causes NO problems for my approach.  I'm NOT proposing
> that SIZE be used to discriminate spam/nospam.  I *am* saying that,
> along with antispam/antivirus/antiworm goals, it ALSO makes sense
> that recipients be able to prevent abusively large messages from
> being sent to them (and perhaps chewing up their limited-size
> ISP-provided Inbox) from people they don't know and don't trust.
> (Limiting the size DOES, however, provide an additional way of
> controlling incoming worms (from untrusted/unknown senders), most of
> which are significantly larger than 25K).

You are proposing that size be used for discrimination. What you are not
doing is proposing that it be used exclusively. There are two avenues
for worms under your scheme. Worms can get smaller in size, or worms can
stay the same size and spread via trusted senders, by looking for 
regular correspondents in address books etc. Fifteen years ago viruses
were less than 1K in size, there is no reason beyond lazyness why worms
need to be around 25K. 

> Throughput is generally not a problem for spammers and virus
> authors, since they as a rule don't pay for it, or at least they pay
> for a vanishingly small percentage of the total bandwidth their
> actions cause to be consumed.

It is a problem. Once a spamming campaign is started, it's a race
against time before spam defences recognize and try to block the
campaign, so speed matters. Also, the spammer economy is
structured. Your typical spammer rents facilities from people who own
zombie armies, open relay lists, bulk mail sending software etc.  The
costs for spammers are not always negligible, and I expect they are in fact
as high as the market will bear.
 
>  It would be ENTIRELY possible to implement it entirely within an
> E-mail client (such as Outlook or Outlook Express for example) and
> wouldn't require ANY changes whatsoever from the ISPs or the wider
> Internet infrastructure at large... 

Sure. I'm not arguing you shouldn't implement it, I'm arguing that
the scheme isn't as foolproof as might be hoped. The devil is in the
details, because the high level concepts in which you describe the 
scheme do not map perfectly into the low level concepts required for 
implementation.

Some problems with whitelists: 

Once you've whitelisted all your friends and colleagues, you depend on
how good *their* spam defenses are. If they receive a worm, it can
travel to you freely. And worm writers realize this, so it is one of their
priorities.

If you have a finely grained scheme which requires giving permission
for all sorts of attachments on a case by case basis, you'll be investing
a lot of time into maintaining your rules and regulations, even if the
software can handle them in the blink of an eye. This depends on how much
and how varied your mail is (the problem is worst for customer service
type employees), but it's clearly a case of diminishing returns.

Do you intend to share whitelist data with colleagues? If so, how
does the software deal with conflicts?

Finally, what happens to the emails which are blocked by the whitelist?
Are they silently thrown away, do they collect in a folder which must
be checked periodically, do they pop up a message informing the user?
The last two schemes don't reduce the amount of work a user must do,
as each message must still be scanned. 

-- 
Laird Breyer.

---

From: [email-masked]
Date: Mon, 6 Dec 2004 22:51:02 +0000 (GMT)

and analyses it to see if it contains prohibited content such as HTML
(to take an example), what criteria does it use? 

[snip]

The choice doesn't have to be a binary one, which seems to be what you're 
talking about.  The whole point is that my permissions list approach allows the 
user to specify what sorts of things they trust a given sender to send to them. 

What my current mail filter here does is to first strip HTML-burdened 
alternative attachments, and then to further strip the majority of HTML tags 
that it finds in "plain text" parts of the message as well.

> The only sure way to protect users against HTML attachments is to
prohibit them from using mail software which displays HTML, 

There's no point in "prohibiting users" from doing most ANYTHING.  The whole 
point is that users should be able to do anything they CAN do now, but 
encouraging them to do it selectively, for those cases where they trust the 
senders.

but containing HTML tags is often displayed as HTML by mail reading
software anyway. Some software reads plain text, looking for anything that
resembles a web address and generates a clickable URL (thereby turning
the plain text into HTML). 

Fine, but at least in that case the URL will NOT be spoofed or misrepresented, 
right?  :-)

> Some software accepts even malformed HTML

Clearly, but the point is to force the spammers into areas that are VERY, VERY 
gray (and which for most users, simply don't exist at all).

I'm not naive enough to presume that ANY one approach will work for EVERYBODY or 
for ABSOLUTELY ALL possible (past/present/future) software.  I don't think that 
any other approach I've seen proposed will protect so many people, so 
automatically, with so little interference with their existing methods and 
systems, and with so many other advantageous effects.

Of course.  Most of those deceptions [mis-]use HTML or attachments.  That's one 
big reason for encouraging users to limit the use of such features only to 
trusted senders.

> You are proposing that size be used for discrimination. What you are not
doing is proposing that it be used exclusively. 

Well, it WOULD be sufficient to block "large" (as defined by the recipient) 
messages coming from unknown senders.

> There are two avenues

All this use of heuristics can be evaded by various strategies.  If worms shrink 
to less than 25K, it might be that a recipient will shift their "allowed maximum 
unsolicited E-mail size" to 15K, or 10K, or maybe even 5K or something.  THAT IS 
*THEIR* CHOICE, and they aren't constrained to maintain the SAME choice.

As for "trusted senders", they'd have to use trusted senders who are trusted to 
send THAT type of content to THAT user.  This is a much narrower gauntlet to 
walk than at present (and MANY users will not allow *ANYBODY* to send them 
executable attachments, which means that NO trusted user exists whose name will 
get a virus or worm past the intended victim's front door).

> Sure. I'm not arguing you shouldn't implement it, I'm arguing that
the scheme isn't as foolproof as might be hoped. 

Nothing is foolproof "because fools are SO resourceful".  :-)  But the fact is 
that this approach still gives FAR better results, faster, at a FAR lower cost 
and with fewer ugly side-effects, than any other proposed solution I've seen to 
date.

> The devil is in the details, because the high level concepts in which you 
describe the scheme do not map perfectly into the low level concepts required 
for implementation.

There is no one SINGLE set of details required.  There is a wide leeway in terms 
of how the various aspects get implemented, and in fact this is an advantage... 
it allows different companies to differentiate their products, while at the same 
time creating distinct products which probably will not share common potential 
weaknesses that a spammer might exploit.

travel to you freely. 

No, ABSOLUTELY NOT, since my proposed "whitelist" is NOT just a simple yes/no 
whitelist.  

  1)  Most of my "friends and colleagues" don't REQUIRE explicit whitelisting 
because the stuff they send me does not exceed the default (very safe) rules.

  2)  The ones I *would* whitelist don't automatically receive "wide open" 
permissions.  I would allow individual senders to send me the type of stuff that 
I might expect THEM as an INDIVIDUAL to send.  NONE of them, for example, are 
likely to be permitted to send me (say) PIF attachments.  :-)   Likewise, VERY 
few (if any) would be whitelisted to send me (say) ActiveX or cookies or 
scripting.

One of the advantages of my approach is that, in fact, people using it would 
block VIRTUALLY ALL incoming worms and viruses, EVEN IF they came (ostensibly) 
from people who they otherwise know and trust.

> And worm writers realize this, so it is one of their priorities.

You greatly underestimate the difficulty of evading the type of permissions-list 
filter such as I'm proposing.  Perhaps you still don't understand my approach;  
I'll be glad to try to explain it further.  

for all sorts of attachments on a case by case basis, you'll be investing
a lot of time into maintaining your rules and regulations, 

That depends a LOT on just how the software ends up being implmented (and that 
would depend on the specific software vendor).  But NOTHING requires that it be 
complicated or time-consuming.  (For example, it would be easy enough to say 
"let mail like this through from this sender in the future" and have the 
software determine the minimum set of permissions needed to allow such example 
mail to pass the filter, and add those permissions to the sender's existing 
permissions).

> ...even if the software can handle them in the blink of an eye. This depends 
on how much and how varied your mail is (the problem is worst for customer 
service type employees), 

Not really, because they will tend to receive a quite predictable type of 
E-mails.  People in this type of job tend to actually find that the great 
majority of their incoming E-mails fit into a small group of types.

> ...but it's clearly a case of diminishing returns.

Indeed.

> Do you intend to share whitelist data with colleagues? 

I probably wouldn't.  People who E-mail to me and those who E-mail my colleagues 
are probably not that overlapping a set.

What I've done in my experimental incoming mail processing program here, though, 
is to provide several levels of permissions, which are sort of 
"company/installation/department/individual" (but this could vary, of course).  
Since I'm presently the only one using the system (it's a home office) I'm not 
really using those multiple levels much;  but the capability infrastructure is 
there in the code should I decide to make use of the software somewhere else (or 
if someone with funding and marketing ability wants me to pursue it as a 
potential commercial product).

> If so, how does the software deal with conflicts?

The present software is designed such that "rules" about stuff like that can be 
defined at each of the various levels.  This way, it would be possible to 
implement "mandatory installation rules" that could not be overridden by lower 
level people, and/or "company/department/workgroup" defaults that individuals 
(or groups) could supplant if desired.  

> Finally, what happens to the emails which are blocked by the whitelist?

At the moment, what happens is that they're routed to a "quarantine folder" 
(which could be on a user-by-user basis;  presently I'm the only user of the 
system here) which is simply a subdirectory with each E-mail message represented 
by an individual file.  That way it's easy enough to search for specific 
messages (by whatever criteria).  Again, the handling of this could be 
determined by the same kind of multilevel rule configuration as is used to 
control the rest of the system.

They COULD be handled in any of those ways, or others if desired.  Presently 
they collect into a folder.  I certainly COULD write a program to summarize 
recently arrived messages, at some (specified) frequency, and alert me to those 
(and perhaps allow me to flag some for delivery, or delete them, or whatever) 
but up to now that simply hasn't been enough of a priority for me here that I've 
felt the need to write that one.

Well, yes and no.  

First, one could combine quite a number of supposed "spam"/disreputable messages 
and summarize them as a group.  This could be combined by sender, or by subject 
line, or by size, or perhaps by other characteristics.  In practice, I find that 
looking at the logs to see WHY the message was rejected (along with things like 
the sender name and/or subject, and/or To: address) usually allows me to very 
quickly concur with the system's triage for most of the E-mails it's rejected.

The reasons could be diverse:  reference to a distrusted/disreputable domain, a 
high score by my "gibberish" detector, reference to a 
distrusted/disreputable/blacklisted E-mail address or domain, or whatever.

One of the reasons why I'm mostly just presently collecting the rejected stuff 
is precisely so that when I *do* decide to sit down and write an experimental 
"scan/confirm" part of the system, I'll have a healthy universe of stuff to use 
as test material...  :-)

But anyhow, it's not nearly as annoying as having to deal with the individual 
messages... since you can deal with them later (when you're not busy with 
pressing matters) and because you're already aware of what the filter found 
about each individual E-mail that it didn't like.  That allows one to make 
pretty short work of dismissing large groups of them.

---

From: Laird Breyer <[email-masked]>
Date: Tue, 7 Dec 2004 13:38:59 +1000

On Dec 06 2004, [email-masked] wrote:

>  What my current mail filter here does is to first strip
> HTML-burdened alternative attachments, and then to further strip the
> majority of HTML tags that it finds in "plain text" parts of the
> message as well.

How does the scheme deal with mislabeled attachments? Spam messages
don't play by the rules. And some popular mail programs virtually
ignore attachment types altogether and use the filename extension, or
rely on defaults known for the target mail reading software.

How does the scheme identify HTML in plain text? Does it correctly
recognize a discussion about HTML tags from a text using HTML markup?

> There's no point in "prohibiting users" from doing most ANYTHING.
> The whole point is that users should be able to do anything they CAN
> do now, but encouraging them to do it selectively, for those cases
> where they trust the senders.

But as I understood it, your scheme is supposed to block the receipt
of email containing HTML from unknown/untrusted senders originally,
and only allow such email through after the sender is trusted. If you
let HTML through to begin with (assuming you can always identify it),
it's much less effective?

> > What you perhaps don't realize is that an attachment marked plain
> text but containing HTML tags is often displayed as HTML by mail
> reading software anyway. Some software reads plain text, looking for
> anything that resembles a web address and generates a clickable URL
> (thereby turning the plain text into HTML).
> 
> Fine, but at least in that case the URL will NOT be spoofed or
> misrepresented, right?  :-)

The art of misrepresenting URLs to the public is called phishing, and
is fairly well developed ;-)

> Clearly, but the point is to force the spammers into areas that are
> VERY, VERY gray (and which for most users, simply don't exist at
> all).

The fact that most users aren't in the gray area is irrelevant. If
(your, any) scheme lets through too many spams, it is as useless as if
spams weren't being identified in the first place.

However, the amount of spam passing through depends solely on the spam
filter and how clever the spammers are. So discussions naturally
gravitate toward spammer tricks.

>  I'm not naive enough to presume that ANY one approach will work for
> EVERYBODY or for ABSOLUTELY ALL possible (past/present/future)
> software.  I don't think that any other approach I've seen proposed
> will protect so many people, so automatically, with so little
> interference with their existing methods and systems, and with so
> many other advantageous effects.

I'm not suggesting you are. However, current state of the art systems
achieve 99+ percent success, and for organizations with very large
userbases, even that isn't enough.  Unless your scheme can claim these
sorts of numbers for nearly all people to begin with, then it isn't
worth trying to convince people here. Most people on this list are
only interested in systems which can deal with vast numbers of
messages with little extra work.

http://www.usenix.org/events/lisa04/tech/blosser/blosser.pdf

> bulk mail sending software precisely so that spammers can design
> their emails against SpamAssassin and tweak them until they pass the
> tests performed by SA, and only then start spamming.
>
> Of course.  Most of those deceptions [mis-]use HTML or attachments.
> That's one big reason for encouraging users to limit the use of such
> features only to trusted senders.

I don't seem to remember whether you explained how to initially deal
with (untrusted) people who (unwittingly, incapably) send exclusively
HTML burdened messages.

>  Well, it WOULD be sufficient to block "large" (as defined by the
> recipient) messages coming from unknown senders.

It is debatable whether large attachments are in fact an indicator of 
friendly (ie nonspam) messages. Spammers tend to send small messages,
unless they're trying to be clever, while worms are as you pointed out
a bit larger. But the truly large messages are sent by clueless people who will
write two lines in Word, include a BMP image, then attach the whole
document to an empty email message and send the lot...

> > There are two avenues for worms under your scheme. Worms can get
> smaller in size, or worms can stay the same size and spread via
> trusted senders, by looking for regular correspondents in address
> books etc. Fifteen years ago viruses were less than 1K in size,
> there is no reason beyond lazyness why worms need to be around 25K.
>
> All this use of heuristics can be evaded by various strategies.  If
> worms shrink to less than 25K, it might be that a recipient will
> shift their "allowed maximum unsolicited E-mail size" to 15K, or
> 10K, or maybe even 5K or something.  THAT IS *THEIR* CHOICE, and
> they aren't constrained to maintain the SAME choice.

None of these suggestions is preventative, only reactive. You're
suggesting that attacks on your proposed spam defense should be
best handled by an arms race between the spammer and the user.
The spammers still have the initiative.

>  > The devil is in the details, because the high level concepts in
> which you describe the scheme do not map perfectly into the low
> level concepts required for implementation.
> 
> There is no one SINGLE set of details required.  There is a wide
> leeway in terms of how the various aspects get implemented, and in
> fact this is an advantage...  it allows different companies to
> differentiate their products, while at the same time creating
> distinct products which probably will not share common potential

Right, various elements of what you propose (scanning for HTML,
blocking attachments) are widely implemented in many different
anti-spam products. One could argue that companies already have
several pieces of your puzzle and have mixed and matched them as they
like.

> No, ABSOLUTELY NOT, since my proposed "whitelist" is NOT just a simple yes/no 

You've talked about examining a limited set of properties such as existence of
attachments and of HTML tags. Your whitelisted friend may have a trojan or worm
which will send plain text advertisements to all people in his address book.

If some combination of tags and attachments can get through, it will
get through eventually.
 
> because the stuff they send me does not exceed the default (very safe) rules.

That's great for you, but these issues must be addressed when proposing a
spam solution for the masses.

> few (if any) would be whitelisted to send me (say) ActiveX or cookies or 

How do you recognize a PIF attachment? What if it's inside a ZIP file?
Inside an LHA file? Inside a zipped HTML file containing an embedded
OBJECT tag with a particular class ID pointing to external data? There
are innumerable ways of sending malicious code with various levels of
obfuscation. Spammers don't use them because the simple stuff works
quite well for now.

>  One of the advantages of my approach is that, in fact, people using
> it would block VIRTUALLY ALL incoming worms and viruses, EVEN IF
> they came (ostensibly) from people who they otherwise know and
> trust.
>
> You greatly underestimate the difficulty of evading the type of
> permissions-list filter such as I'm proposing.  Perhaps you still
> don't understand my approach; I'll be glad to try to explain it
> further.

I think I sort of understand your approach. Your filter scans an
email's MIME structure, looking for particular types of
attachments. It also scans for some simple tags such as <FONT>, <A>,
etc., in the plain text attachments.

[Not all email uses MIME, not all MIME using email is correctly
generated. Not all MIME attachments contain what they are labeled as
containing, not all mail software interprets attachments according to
the labels either, but others do]. 

If the sender is unknown, the mail is blocked if it contains the tags
you scan for or attachments labeled as forbidden. If the sender is
known, the mail is blocked if it contains tags or attachments which
are prohibited for that sender.

[It blocks mail from unknown people who use HTML or attachments or
large mail bodies, which is a sizable proportion of the email sending
population. People need to know enough about email structure to maintain
complex sets of permissions.]

Blocked mail can be inspected individually, possibly by grouping 
according to some heuristics based on header fields or message structure.

[For spam, header fields are both faked and randomized to thwart easy
grouping, as that would also make filtering easy. If you receive 500 spams
a day and wait a week to check them at your leisure, you have to wade
through 3500 messages looking for the elusive incorrectly blocked
email - that's still a chore, once a week, and the unfortunate sender
has been waiting for a response for a week].

Based on the above objections, I'm not convinced your system is
competitive (accuracy wise) with other systems for large
organizations. For individual use by power users, it appears to me to
be less work than custom keyword filters, but more work than personal
Bayesian filters.

This is just my opinion based on our discussion, of course. 
For a serious evalutation, nothing beats physical deployment at 
multiple locations, and you at least pass the test of using your own
system yourself.

-- 
Laird Breyer.