Subject: [Asrg] Re: whitelisting

From: [email-masked]
Date: Tue, 26 Apr 2005 01:57:34 +0000 (GMT)

>> "A whitelist scheme can only be used to reject spam when *every*
> legitimate mail sender is part of the scheme. "

That's ridiculous.  

The point of a whitelist (IMHO) is to toss out certain types of incoming mail 
that you aren't willing to trust or accept from people you don't recognize.

Ideally, such a whitelist is VERY finely-grained, and with a "relatively safe" 
default behavior.

I have proposed here (and I'll do so again) that a reasonable default behavior 
(for senders not on your whitelist) is to allow plain ASCII text, NO HTML, no 
attachments, and of a limited size (say 25K or 50K or something).

When you whitelist senders, you ought to be able to do so (again) in a 
fine-grained way.  For example, Aunt Gertrude might send me a JPG of her poodle 
Fifi, or might use her favorite stationery with a nice script or handwriting 
font, but there's no likelihood that she'd try to send me a 165K byte PIF file 
or an ActiveX enclosure or some kind of encrypted Javascript.  Anything 
purporting to come from her which contains that kind of unusual stuff is almost 
certainly bogus, and can be safely deleted.

Once the HTML, scripting, and attachments are zapped, there are relatively few 
tricks remaining that spammers can use to evade content filters... so the 
fine-grained whitelist discrimination should be followed up by a good content 
filter.

> Well, no.  Having a whitelist scheme in place means you can turn up the
> sensitivity on your spam-detection tools (i.e. lower SpamAssassin score
> thresholds and reject more spam) and maintain the same FP rate, or keep
> them at the current level and have a lower FP rate.

It's certainly true that a good fine-grained whitelist makes it a LOT easier for 
your content filter to do a good (in fact, probably EXCELLENT) job.

> Yes that's exactly correct - a whitelist doesn't increase the positive
rate (ie. you can't use it on its own to reject spam) 

I disagree... I think you CAN use it to reject spam, although one might argue 
that it's even more useful to reject OTHER kinds of unwanted/untrustworthy 
mail.... specifically, phishing scams with misrepresented hyperlinks, 
attachments which carry viruses or worms, and other unwanted junk.

> ...though it can be used to lower the false-positive rate for next layer 
(though the whitelist needs to be backed up by a working authenticated-sender 
scheme (which doesn't exist yet??) to be reliable).

I agree that knowing who the "real" sender is can be useful, although by itself 
it's NO guarantee of safety (or not being spam) either.  The fact that the 
"from:" address represents the actual machine of (or an alternate machine 
sometimes used by) that legitimate sender is NOT a guarantee that said machine 
hasn't been commandeered by a spambot zombie which is sending out spam or 
viruses using the victim's authorizations and certificates.  

Many "certification" schemes are worse still in that they only try to determine 
that the E-mail originated from a server authorized to send mail from the 
indicated "sender domain", and for domains containing (literally) millions of 
valid E-mail addresses, that means that ANY of those millions of machines could 
counterfeit/spoof the E-mail address of any other user within the same domain 
name and still successfully pass the "authorized mail server for that domain" 
test.

Ultimately, it's a FAR better solution to identify spam based on whether it 
"looks right" (i.e. looks like mail is EXPECTED to look, coming from that 
specific sender) and that it doesn't contain anything (executable attachments, 
encrypted ZIP files, Javascript, ActiveX modules, etc etc) that make its purpose 
or intentions suspect.

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: James Baldwin <[email-masked]>
Date: Tue, 26 Apr 2005 10:31:10 -0400

> that you aren't willing to trust or accept from people you don't 

I think we're getting into a bit of a semantical tiff here. This is 
dependent on whether or not your site is practicing a default deny or 
default accept policy with regards to mail. Many sites would rather 
trust unknown senders and reject known poor senders rather than 
increase false positive rates and associated support costs.

> Ideally, such a whitelist is VERY finely-grained, and with a 

Finely grained anything leads to scalability and complexity issues. 
That is not to say such solutions cannot work, only that the trade off 
between complexity and effectiveness often yields diminishing returns.

> fine-grained way.

In your proposed implementation, who controls this white list? The 
"you" appears to indicate the mail service provider, however, managing 
a finely grained permission set for millions of users quickly outstrips 
available resources. Another solution is to have service 
representatives default allow behavior when a customer complains, 
however this is expensive both in representative time and in the amount 
of churn it will cause due to dissatisfied customers. The most scalable 
solution is to have the customer control their settings. This most 
likely would fail as most customers will not understand the options of 
a finely grained control system.

> fine-grained whitelist discrimination should be followed up by a good 

Do content filters not weight based on the presence of HTML, scripting, 
and attachments? Does not automatically deleting matches to this 
blanket rule reduce, not increase, your amount of control over what 
mail you allow?

> attachments which carry viruses or worms, and other unwanted junk.

Once again, this is semantics. Default deny versus default reject.

> viruses using the victim's authorizations and certificates.

This is a remote site management issue. It is up to the remote site to 
manage whether or not their senders can forge "From:" fields. The 
domain based identification allows us make policy decisions based on 
administrative boundaries, that is to say we can either block poor 
senders or return mail to the administrators for further investigation. 
You cannot guarantee that the mail was send legitimately, but you can 
guarantee that your policies are affecting the responsible parties.

> name and still successfully pass the "authorized mail server for that 

Once again, "spoofing" is a domain based sender policy issue. If the 
remote site is only allowing "From:" fields to match the authenticated 
username this is a non issue. If the site is not authenticated mail 
sourced within their domain, then my external policies are in place to 
restrict this behavior.

> encrypted ZIP files, Javascript, ActiveX modules, etc etc) that make 

I disagree. Keeping state on specific senders will not scale to the 
whole internet. If you're discussing keeping state on specific senders 
in an edge model, this might be appropriate as the number of legitimate 
senders to a single receiver is small, however on an enterprise level I 
cannot fathom a manner to efficiently manage state for every sender 
destined to my customers. It is less complex to create stateless 
policies based on message contents and keep state on high traffic 
authenticated sender domains.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg