At 09:26 PM 6/22/2003 -0600, Vernon Schryver wrote:
>From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
[..]
Do you use an HTML-enabled mailer? I bet you do, because you would
otherwise not be so cavalier about the games spammers play with HTML.
For the record, I use Eudora which is not HTML friendly and I made sure to
have HTML disabled. You can search the archives and you will not find any
HTML posts from me.
[..]
> I think that we had plenty of arguments both ways, and both camps are
> staying were they are. I would suggest that either you or someone else,
> write up a BCP or RFC, plus create some working code and get back to the
> group. Not that I am advocating the banning of HTML, but there are plenty
> of people that are and it is important to get stuff past theory into
> practical useable code.
The working code already exists and is wide use. I think other
people have said that standard SpamAssassin penalized mail in HTML.
It's trivial to write a Procmail recipe that rejects HTML mail or
to modify a recipe that rejects by character sets named in SMTP or
MIME entity headers to reject "text/html".
Reread Gordon's original proposal - he is not simply proposing blocking
HTML email - he is proposing creating a tracking system where the receiver
can grant permission to the sender to send HTML email ONCE the initial
ASCII email got through. This permission code is not a trivial Procmail
recipe, and I have not seen a working copy of it yet.
The fact is that people are blocking HTML email currently and will be doing
so. Now if Gordon and you, and others, want to preach blocking HTML, then
do something about it. That's my point - the discussions have gone long
enough, every one expressed their opinions, now its time to do something
practical about it. Perhaps even create a central code repository with
patches and instructions for major email clients, similar to the efforts of
the Web Standards Project (http://www.webstandards.org/) - you can call it
the "Email Standards Project" perhaps. Maybe even a compliance program with
logos, etc. The possibilities are endless.
If HTML issue is dropped, will you promise to be try as hard to squelch
talk of even more hopeless efforts?
Its a research group - everyone is entitled to their opinions. I do not
think blocking HTML is hopeless - I don't think that anyone in the group
has argued that blocking HTML does not have SOME benefit - the question is
only how big is that benefit is, and whether it outweighs the costs.
Getting Microsoft to turn on HTML
in Outlook only when the user asks for formatting seems more promising
I don't think that Microsoft is budging anytime soon to do anything that
does not correspond with their own interests. Plus, even if they do so, the
damage has already been done - the installed user base is very large.
than getting Microsoft to add CR support to Outlook or changing the
terms and conditions for the use of Hotmail to prohibit sending from
any except Hotmail SMTP clients and so make RMX meaningful.
For the record, I had never advocated getting Microsoft to add C/R support
for Outlook. C/R systems are coming into wider use, I do not advocate for
or against their use, however once they are present I am just trying to
make sure that they are inter-operable - that's why I am collaborating with
Eric Dean on the CRI protocol. This is a research group - we are looking at
everything under the sun and I am glad that all these issues are coming up.
Yakov
---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research(_at_)solidmatrix(_dot_)com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg