Subject: RE: [Asrg] HTML-burdened E-mail

From: [email-masked]
Date: Fri, 20 Jun 2003 10:25:42 -0500

>The users want html formatted mail.

Most of them have no idea what that means.

The main reason so many users end up sending HTML-burdened E-mail is because 
they don't know any better, and because it is the default.

Most HTML-burdened E-mail generated by the VAST majority of users never use any 
of the formatting (or other such) features at all.  For all of those messages, 
the HTML-burdening only just makes the messages bigger without conveoying ANY 
more information.

>They do not want rfc plaintext. 

The GREAT majority of them (probably 95%) couldn't care less.

For the rest, if their recipient agrees to accept the bulkier HTML-burdened 
stuff, they can continue to use it without the slightest difficulty.

I believe that, given the choice, the overwhelming annoyance of spam, viruses, 
and worms is a FAR greater issue to virtually all legitimate users than HTML 
'benefits' are.  If more users realized how crucial HTML-burdened messages are 
to spammers, the users would gladly give up HTML.

>This problem cannot be solved by solutions that only work for geeks.

Sorry, but to suggest that plain ASCII text E-mail "doesn't work" for other than 
geeks is one of the more ludicrous arguments I've see in this thread so far... 
:-)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 20 Jun 2003 11:41:20 -0400

>the HTML-burdening only just makes the messages bigger without conveoying ANY

#1: Majority of users and MUAs send HTML email by default
#2: Changing those settings can take months and years
#3: Spammers switching to plain ASCII will take days.
#4: It is easier and faster to have content filters do everything that MUAs 
can, than forcing users to stop using HTML email. Base64 encoding, HTML 
encoding, url encoded URLS, etc. can all be put into content filters.
#5: There is no consent architecture in place for users to make such choices.
#6: We are ignoring the problem. Blocking HTML,base64,attachements, etc. 
still does not fix the fundamental problem of SMTP able to accept email 
from forged senders.

Another example would be challenge response for spam blocking. One of the 
problem with challenge/response is the burden is puts on the sender to have 
to reply to every email. That's why Eric Dean is working on a CRI protocol 
that can do the verification automatically. An automatic CRI protocol that 
is transparent to the end users is something that solves the forged sender 
problem, while blocking HTML does not.

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
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)
---------------------------------------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 20 Jun 2003 16:57:44 -0500

>#1: Majority of users and MUAs send HTML email by default

That's what I just said.

>#2: Changing those settings can take months and years

It will take less if they're motivated to change the settings.  Actually 
changing settings in outlook (for example) takes less than a minute and only 
need be done once.

>#3: Spammers switching to plain ASCII will take days.

Would be nice.... would result in a HUGE reduction in spam volume and cost, in 
just DAYS (your claim!).  I don't see that as a negative.  :-)

>can, than forcing users to stop using HTML email. 

They don't have to stop using it, if they're communicating with people they have 
a current agreement with.  They could be 'grandfathered', perhaps.  That's a 
decision up to whoever implements the specific filter employed by a given ISP.

>Base64 encoding, HTML 

Of course they can.  The important thing is to decide how those are to be 
weighted, who gets around the restrictions, and how early in the E-mail 
distribution process the reduction in volume (and cost) takes place.

>#5: There is no consent architecture in place for users to make such choices.

Nor does there NEED to be, on any global basis.  Any ISP can choose to implement 
that any way they wish (and in fact, that's a PLUS, since the lack of a single 
approach to that problem makes it harder for abusers to find a loophole globally 
and take advantage of that).  It gives ISPs (otherwise mostly interchangeable) 
the opportunity to differentiate at a very low cost their product/service 
offerings from rivals in a meaningful way, and which will make a big difference 
to their customers (current, and potential).

>still does not fix the fundamental problem of SMTP able to accept email 

Most of that problem is greatly reduced if the spammer can't guess WHICH sender 
they need to forge in order to get their spam delivered to a given destination.

>that can do the verification automatically. 

Many publishers of free newsletters and mailing lists have made it ABUNDANTLY 
clear that they're not willing to answer all those "challenge/response" E-mails. 
That idea, I think, is totally DOA.

Again, I think that a recipients resources... their (maybe dialup!) bandwidth, 
their limited-size Inbox, etc etc... ought to be under THEIR control.  They 
ought to be able to choose who they allow to use it, or to stuff what into it.

And ideally, to cut the cost that the RECIPIENT must bear as much as possible, 
the filtering ought to be done as soon as possible after the spam or other 
undesired content reaches the destination domain.