Re: [Asrg] Re: White/black lists

[gep2 at terabites.com]

>> > 1) You can make a list of all those which you want to treat better (the
> >    whitelist)
> 
> > 2) You can make a list of all those which you want to treat worse (the
> >    blacklist)
> 
> > Generally, you will base your decision on whether you choose the
> > whitelist or blacklist approach on the size of the resulting list (you
> > especially don't want an infinitely long list) and on which side you
> > want to err for previously unknown entities: The whitelist approach errs
> > on the side of caution: Everybody who isn't on the good list is presumed
> > bad. The blacklist approach is optimistic: Everybody not on the bad list
> > ist presumed good.

>> Rather than the crude idea of a "whitelist" or a "blacklist", I prefer a more 
> nuanced concept I call a "permissions" list.

> Yes, we know that already :-).

People tend to forget, so I like to mention it again from time to time. :-)

> Conceptually, it's no different, though. Instead of one list, you have
several.

That's like saying that all collections of information are no different.  

My preferred approach basically is keyed off of who the sender is (or at least 
who they CLAIM to be).  Not (necessarily) an IP address or something, although 
one might create a composite based on both of those.

Based on that, an "expected E-mail profile" is found, and the E-mail message is 
checked to see if it matches the type of mail you EXPECT to get from that 
sender.  A given sender, for example, might always have their first name in the 
mail somewhere, or might have a characteristic signature block, or whatever.  
There is also stuff that you do NOT expect to find in mail from them... or take 
as a negative indication if it IS there... Aunt Mildred, for example, is never 
going to send me E-mail messages containing ActiveX or Java scripting, nor is 
she likely to ever send me 185K-.PIF files or .EXE attachments.

Initial contact E-mails (i.e. prior to negotiating more dangerous/bulky forms of 
mail from that sender) normally would not be expected to contain attachments, or 
HTML, or be 'very large'.

Most users, by default would not need to enable executable attachments coming 
from ANYBODY AT ALL.  The result of that fairly simple rule would all by itself 
very nearly eliminate E-mail as a vector for distribution of worms and viruses 
(at least, arriving in attachments!).

Eliminating HTML in E-mails from unknown/untrusted senders would force most 
"phishing" spams out into the open by making it harder to hide misrepresented 
URLs... by eliminating cases where a link looks one way but actually "under the 
covers" goes to some rogue server in Romania or the like.

>> The idea is that one would typically by default accept a "safe" 
> lowest-common-denominator E-mail from unknown senders.  I propose that this 
> typically be:
> 
[...]
> You could specify preferential treatment for specified, known senders... you 
> might allow them to send you certain types of attachments (say, JPGs are okay, 
> but .SCR or .EXE or .COM are not...).  You might allow them to send you some 
> types of HTML (colors and fonts and point sizes are okay, but scripting and 
> ActiveX etc are not), based upon the particular types of things you EXPECT to 
> receive from that specific sender, and that you TRUST them to send to you.

> That's a whitelist for JPG, a whitelist for "safe HTML", etc. 

I don't envision it as SEPARATE lists, but rather a grid which says what 
individual senders are allowed to send.  I guess you could envision it 
differently, if that is more comfortable for you.

>> Likewise, you could establish more restrictive rules for mail from other 
> senders... for example, to simply T-can mail from IP addresses or domains 
which 
> contains information that you simply don't want to receive anymore... (such as 
> mail from familiar folks who seem determined to not take you off their mailing 
> list, or who refuse to send plain text E-mails).

> And that's a blacklist (or possibly several).

Or, again, it's simply a default behavior for senders which are previously 
unknown (customer service organizations obviously expect to get a LOT of "first 
time" mail from consumers), along with a "permissions whitelist" which limits 
mail from a given sender to be no bigger than (say) 30 bytes.  :-)  It really 
doesn't have to be a separate list at all, it's just a set of restrictions that 
you view like a keyway, and the E-mail from a given sender has to fit the keyway 
that's assigned to that sender.  Mail that doesn't look "right" is efficiently 
and rapidly quarantined (or whatever) for later examination or immediate 
discard, as preferred.  

Even if Aunt Mildred's machine is turned into a zombie spambot which sends 
through her SAME habitual mail SMTP server, my approach will still quickly and 
readily differentiate (with high probability) the mail that Aunt Mildred REALLY 
wrote to me, from the spam mail the zombie spambot lodged and hiding in her 
machine sent out to me using her credentials.

And that, I think, is a highly desirable characteristic that NONE of these other 
antispam approaches shares.

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
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg