At 04:53 PM 6/15/2003 -0500, gep2(_at_)terabites(_dot_)com wrote:
[..]
During the discussion it struck me that a better approach to the problem
is the
following:
A recipient should be able to create a specific-permission "whitelist" which
lists the senders (by E-mail address) to which they wish to assign "special"
privileges. Senders who are not on the whitelist would only be allowed to
send
that recipient plain, unencoded, ASCII text E-mails without HTML, scripting,
encoding, or any kind of attachments.
[..]
The whitelist would be maintained either at the recipient's mail server, or
local ISP's mail server, or else (for their own domain) at the domain
provider/mail forwarder... probably, as soon as the mail resolves to the
addressee domain.
Maintaining white lists for users in places other than their computers
raises privacy issues as mentioned many times prior.
You'll note that this scheme does not provide for the blocking (at this
level,
anyhow) of plain ASCII text spams. True. More on that later.
But the great majority of spams use a variety of tricks to get past content
filters, and to deceive recipients. A *large* subset of those tricks are
based
on HTML:
1) HTML comments (and bogus HTML tags) to break up and obscure mail
content,
and to confuse content filters;
HTML email is also used by many companies for legitimate purposes.
2) graphic-mode-text (likewise);
Same comment as above.
3) links which purport to be one thing but where the actual hyperlink
in fact
(and usually invisibly) points somewhere else;
Many spammers own their own domains and will not lose out from this.
4) scripting where the message displayed only can be viewed as a
result of
the computational process, again to make things difficult for content filters.
Attachments (especially in unsolicited E-mails) tend to frequently contain
viruses, worms, "background music" that's actually a PIF or EXE file, and
things
of that sort. Getting attachments from someone who doesn't ordinarily send
those is a warning sign that it might well be malicious.
Not all attachments are bad.
[..]
By enabling a user to simply t-can any unexpected HTML-burdened (or
attachment-carrying) incoming message (and ideally as soon as it got to their
domain provider or ISP), spammers would be denied many of their most
cherished
and valuable tricks. Content filters would be far more useful and
efficient.
And much more of the remaining unsolicited spam that WOULD still be sent
would
be sent in plain ASCII text (knowing that sending unsolicited HTML E-mail was
the kiss of death...) meaning it would reduce wasted bandwidth for such
remaining spam mail net-wide by at least a factor of three to five.
[..]
Thus proposal addresses many of the tricks that are used by spammers TODAY.
As Vernon and many others mentioned on the list before spammers change very
quickly and can adapt their practices very quickly as well. This scheme
would be just a band aid to block some forms of spam until spammers will
figure out a way around it just like many other proposals.. Additionally,
many of the "Nigerian Scams" arrive as plain ASCII emails already and this
scheme will not stop them.
Another concern with this sceme is the fact that email will go back to the
dark ages with no support for attachments and no HTML support. This may
increase people's use for email which is already under attack by spammers.
Is the medicine as bitter as the problem?
Also, blocking base64 encoding would block email schemes where digital
signatures are used.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg