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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg