Maintaining white lists for users in places other
than their computers raises privacy issues as
mentioned many times prior.
First, let me point out that traditional "whitelists" have a number of problems
with them. I think that many of those problems are mitigated by a
PERMISSIONS-based whitelist such as I propose.
Specifically, people willing to send plain ASCII text without encoding or
attachments (and without any HTML tags) would have their messages (by default,
at least) go through without any problems at all. This would enable those
wishing to receive unsolicited messages (say, from consumers of a company's
products, or from prospective new clients for my consulting services) to do so
without any problems.
HTML, attachments, and encoded text HUGELY magnify not just the bulk and
bandwidth of E-mail, but also create VASTLY increased risk and opportunity for
obscuring mail content, malicious code, and other fraud and deception. These
features are simply not needed in basic E-mail (and that should include ALL
unsolicited E-mail).
Therefore, it makes sense in the "whitelist" to specify SPECIAL PRIVILEGES that
are granted by a recipient to familiar, trusted, and justified senders of those
kinds of costlier, riskier E-mail. Those untrusted/unknown/unfamiliar senders
who [ab]use these features without prearrangement to do that ought to find
their
E-mail bounced or even just simply discarded.
The GREAT majority of spam (and certainly the most
dangerous/malicous/fraudulent), not to mention nearly all viruses and worms,
are
blocked virtually immediately by this simple, straightforward strategy... and
one that can be implemented without major technological breakthrough or global
re-engineering consensus. Even better, most of the spam/fraud E-mail remaining
can be rather readily dealt with using various content filters.
As has also been mentioned many times in the past, the use of
"virtual" or "implicit" whitelists
I don't like anything that precludes unannounced delivery of (ordinary, plain
text) mail from unexpected senders. Those mails can commonly include inquiries
from potential new clients and customers.
...by means of using single-user
addresses or passing authentication tokens as part of messages
Authentication tokens typically require special software provisions on the part
of both the sender and the recipient. It likewise requires coordination and
agreements on methodology and techniques so that we don't end up with a
crazy-quilt patchwork, which doesn't suit ANYBODY.
One nice thing about what I propose is that it can be implemented at the
recipient ISP and is a single-ended system which doesn't require concurrence or
adaptation by anybody else, other than merely sending unanticipated/unannounced
E-mail in plain ASCII text (which should be the case, really, anyhow).
can give the effect of whitelists while reducing significantly the privacy
issues. (since the whitelist is distributed, it is harder to
reconstruct.)
The whitelist I propose NEVER needs to be sent to anybody, other than (if the
restriction is done at the ISP or domain provider, which has the advantage of
truncating the spam sooner in the delivery chain) only just the point where the
filtering is done. I don't think that the sender should be told by any
automatic means what their permissions are (other than unacceptable mail MAYBE
being bounced) and CERTAINLY nobody should be able to retrieve a copy of the
ISP/domain provider's overall permissions list. Another advantage of my
approach is that there is NO NEED to make any of that information available to
anybody else.
When discussing "whitelisting" we should not confuse the
mechanism with the concept. The concept is that some subset of the
entire universe of senders is given preferred access to an inbox.
Up to that point, at least, my approach matches your definition of "whitelist"
as a concept...
This can either be by checking against an explicit whitelist which is
represented as a monolithic list of senders and privledges or it can be
done algorithmically by checking properties of the sent message (i.e.
tokens in headers or in addresses) to determine if the sender is on an
"implicit" or "virtual" whitelist.
I don't like that sort of approach because it means that senders must make
special provisions to send to specific users, leading either to the "crazy
quilt" patchwork thing I mentioned before... or to the need for some kind of
global agreement for some new kind of E-mail, which will inevitably break many
currently operating (legitimate) senders.
I'd like to see the permissions be changeable by the recipient at any time,
besides, and that speaks against a token they'd deliver to an "approved sender"
should that previously trusted sender betray that trust.
It's really rather like using an answering machine to screen your calls...
where
the sender calls and presents their case, and the recipient can listen silently
and decide whether or not (based on caller ID, perhaps, and the message format
and content) they wish to pick up and accept the message.
The GREAT majority of techniques used by spammers to obscure, defraud, mislead,
deceive, and confuse are based on tricks of HTML, attachments, and encoding,
including message-as-text, tricked-up obscured URLs, bogus HTML tags in the
middle of words, misleading links, teeny 1-point text the same color as the
background, and other such nonsense. Denying them *all* of those techniques in
one fell swoop will deliver a _serious_ blow to spammers and fraudsters, at a
minimum cost (indeed, at a considerable BENEFIT) to both legitimate users and
ISPs.
And the availability of the "whitelist" still allows (by prearranged agreement)
any trusted sender to continue to send any of those features in their E-mail to
willing recipients.
I *really* do believe that this offers the best combination I've seen of
safety,
effectiveness, and low cost (implementation/operating) of any approach I've
seen
to date.
Gordon Peterson http://personal.terabites.com/
1977-2002 Twenty-fifth anniversary year of Local Area Networking!
Support the Anti-SPAM Amendment! Join at http://www.cauce.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