Re: [Asrg] Introduction and another idea

[Yakov Shafranovich <[e-mail]>]

At 04:53 PM 6/15/2003 -0500, [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg