Subject: [Asrg] "more readable"

From: [email-masked]
Date: Fri, 20 Jun 2003 18:12:55 -0500

>>  'Unnecessary' HTML (just P and DIV tags): 23

> This is not necessarily a valid measure of utility. It is often
the case that HTML is displayed using fonts which are different from
those used to display "ASCII" messages. Given that those fonts are often
variable pitch and given that variable pitch fonts are known to be (for
most people) much more readable, one can argue that there is utility in
sending HTML formatted messages even if that HTML doesn't include
special rendering of text. 

Most E-mail programs, if they have special font provisions at all, have the 
ability for the users to set their fonts to whatever settings they choose (size, 
color, typeface, whatever).  Again, the RECIPIENT should be able to set THEIR 
choice (e.g. they might be colorblind, and the sender's choice of colors might 
not be appropriate, etc etc.)

Likewise, a font which looks fine on the sender's machine might not even EXIST 
on the recipient's machine.  

If the recipient "feels there is value" in displaying incoming mail messages in 
(say) 18 point script, then THEY should set their mailer to that and it 
shouldn't be overriden by the sender.

> The utility comes from sending the message in a format which is likely to be 
easier to read as well as to be more readily understood by the reader.

I think you ought to let the READER be the judge of what the READER finds the 
most readable... based on THEIR screen, THEIR vision, THEIR color preferences, 
THEIR screen resolution, etc etc.

And if the reader chooses to give that permission to certain of their trusted 
senders, they ought to be able to do that if they wish.  But they shouldn't be 
subjected to the whims and nonsense chosen by some random spammer somewhere.

(such as a spammer who decides there is "utility and value" in putting some of 
their (perhaps legally required) message in 2-point white text on a white 
background...)

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: Kee Hinckley <[email-masked]>
Date: Sat, 21 Jun 2003 14:35:27 -0400

>THEIR screen resolution, etc etc.

This battle was fought and lost with HTML web sites.  Why do you 
think you'll have any more luck winning it with email?

99.9% of the people sending email really don't care.  Actually, I'd 
put it stronger than that.  When they make a document on the screen, 
they want it to appear the same way on the printer.  When the fax it 
to someone, they want it to come out the same on the remote side. 
When the paper mail it to someone, they want it the same way on the 
other side.  So not surprisingly they have this weird idea that the 
recipient should see the email the way they composed it.  That's how 
it works in real life.  That's how they want it to work on their 
computer.

And don't talk to me about bits.  Or dangerous content.  Having your 
computer on the internet is dangerous.  But we think it's worthwhile. 
You've made an apriori decision that HTML email isn't okay with you. 
Great.  Don't accept it. But don't try and massively complicate 
everyone's life just because of your personal preference.  You want 
to make everyone's machine keep track of who they have ever 
communicated with (On this machine?  With this email program?  With 
this email address?  With this ISP?).  You want to change the default 
behavior of 90% of the MUAs out there.  You want to change the 
behavior of every MTA out there that receives email (or else every 
MUA has to add the code for tracking and bouncing).  You want to 
explain to the users how to change these settings, and have *them* 
keep track of whether they have every sent mail to a particular user 
at this particular email address and from this particular address 
before, and then if not, have them change a setting that they don't 
even understand.

And all to bring about a change that spammers can adapt to in less 
than a week.  Because you know what?  They didn't need HTML to sell 2 
million Iraqi most-wanted cards in two weeks.  They didn't need HTML 
to con people into flying to Nigeria and getting killed.  And they 
certainly don't need it to sell penis expanders.

Sure, it would be wonderful if there were some directory of what 
formats people would accept, and if you could easily keep track of 
whether you've sent mail to someone before, and they could easily 
keep track of whether they've received mail from you before.  We 
abandoned those things when we abandoned X.400/X.500.  This is good 
old SMTP/MIME email.  No directories.  No concept of identity.  No 
concept of preferences.  That is the environment we are working in. 
And futhermore.  It has nothing to do with spam.  Please take the 
topic somewhere appropriate.

Your proposal doesn't amaze me.  I've seen lots of people make the 
same complaint, myself included.  What amazes me is that you think 
it's simple.  Email is an END-USER technology, it's not some buried 
network protocol.  NOTHING about it is simple.
-- 
Kee Hinckley
http://www.messagefire.com/          Anti-Spam Service for your POP Account
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 Jun 2003 16:58:18 -0400

Gordon Peterson wrote:
> I think you ought to let the READER be the judge of 
> what the READER finds the most readable... based on 
> THEIR screen, THEIR vision, THEIR color preferences, 
	Argh... I first had this debate over 20 years ago... It is one
of the classic issues in email... I really don't want to drag through
all the detail which would involve endless quotes from Aristotle on the
subject of rhetoric, etc... However, in "classic" communication systems,
the *speaker* is responsible for constructing communications in a form
which is most likely to be understood by his audience. Electronic
communications adds a twist to things, very different from traditional
forms of communications, in that the reader is able to reformat the
"utterance" upon receipt. Nonetheless, the speaker still has
responsibility to do the best he can in forming his utterances...
	There is a long set of arguments that would say that properly
formatted HTML would be the best form in which to construct a message
since the recipient of the message can alter the presentation to adjust
to his own preferences. Thus, a message should be formatted with "<em>"
tags (not "<b>" tags) and the reader will choose how he prefers to see
emphasis rendered in response to the speakers indication that emphasis
be shown. If all messages are sent in ASCII, then the reader has less
control over the message content than if messages are sent in HTML. It
should not be forgotten that the reader has the option, given
appropriate software, to take an HTML message and have it formatted as
pure ASCII... Lynx based HTML browsers have been doing that for a very
long time...
	I think the real issue here is not the sending of HTML, but
rather, the fact that most reader's email systems can't be trusted to
display HTML without risks. We wouldn't be hearing these objections if
more readers had systems that had the flexibility of web bugs, were
better protected against HTML born viruses, etc. It isn't HTML that is
the problem, it is the software that reads it.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 21 Jun 2003 17:04:03 -0400

Kee Hinckley wrote:
> easily keep track of whether they've received mail from 
> you before.  We abandoned those things when we abandoned 
> X.400/X.500.  This is good old SMTP/MIME email.  No 
> directories.  No concept of identity.  No concept of preferences.
	I think you do not understand X.400. While X.500 had much to do
with "identity," there was nothing in X.400 concerning identity,
preferences, etc. And, the issues being discussed in this forum had
nothing to do with any reason why X.400 is not successful today.
	(Note: I was part of the definition of and first commercial
implementation of X.400, etc... Don't get me started.)

		bob wyman

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 21 Jun 2003 15:31:24 -0600 (MDT)

> From: "Bob Wyman" <[email-masked]>

> ...

That's true of privacy and security complaints but not spam. 
A safe and sane HTML-enabled MUA that doesn't dereference URLs and
never executes scripts without the explict informed opinion of a human
user would be an irritant for spam filtering.  Spam filtering must
deal with <strange tags> and <!--comments-->, just to name two things
that are easy to handle and not mentioning other things that are more
hassle since there's no reason instruct the slower spammers reading
this mailing list.

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Sat, 21 Jun 2003 20:54:37 -0500

>think you'll have any more luck winning it with email?

Well, ONE difference is that a Web site is for the most part a public posting, 
which people have the right to visit or not visit as they choose, but at THEIR 
option.  The Web site is designed (and paid for) by the person posting it.  A 
Web site is normally made available without knowing in advance who might or 
might not someday come to view it.

E-mail, on the other hand, uses an inbox (of limited size, thus at least for 
some a 'scarce resrouce') paid for by the recipient.  While made available by 
the recipient for the convenience of others, the sender of the E-mail usually 
knows (of, at least) the people who will be receiving the mail.  There is 
generally a more direct relationship (other than in spamming, of course).

It's really like the difference between announcing an open public meeting 
somewhere to make a presentation, versus knocking on the door to someone's home 
to make the presentation at their house.  If you're making the presentation to 
them personally, you should normally expect to go to greater pains to respect 
the wishes of the people who are personally giving you their time and attention.

>they want it to appear the same way on the printer.  

HTML is not, and has never been, a precise or deterministic page layout 
language.  Postscript, TeX, and other schemes are [FAR!] better at that.

While obviously I can't prevent people from confusing that issue, I also don't 
take responsibility for their trying to turn HTML into something it's really 
not.  And I don't have to allow them to waste _my_ resources in their 
associated, [foolhardy!] attempt.

The issue, anyhow, isn't really whether people should or shouldn't use 
HTML-burdened E-mail... obviously, some people can (and do) send anything they 
could possibly want in their outgoing E-mails.  The issue before THIS group is 
whether we might encourage ISPs to provide filtering options to their 
subscribers which return control of the subscribers' E-mail inboxes to the 
subscribers, or if we leave them to continue to be victimized by spammers, 
fraudsters, and other abusers.

My observation is that spammers as a class are far more likely to use (and 
abuse) the various oddball things in HTML in their attempts to deceive, defraud, 
mislead, and confuse their victims.  Since the MOST universal (and safest!) form 
of E-mail is plain ASCII text, it just makes sense to (AT LEAST FOR AN INITIAL 
CONTACT) to employ that cross-platform, everyone-can-read-it style.

>When the fax it 

Fax by its nature is an IMAGE.  HTML is NOT an image, nor is it a page 
description language (no matter how strongly some of its users try to make it 
that).

>it works in real life.  That's how they want it to work on their 

They can do that using Adobe Acrobat, Word, TeX, and various other kinds of page 
composition languages.  HTML is NOT like any of those.

But in ANY case, there is a quantum, crucial difference about E-mail than about 
Web sites or E-publishing... E-mail is often between just TWO people, and it's 
not ONLY about what just ONE of them wants.  To be useful, it must be useful and 
correspond with the needs and wishes of BOTH of those parties.

>computer on the internet is dangerous.  

You do NOT get viruses/worms/trojans from plain ASCII text E-mails.  HTML and/or 
attachments are crucial components to virtually EVERY type of malicious E-mails 
(i.e. not just 'fraudulent' like the Nigerian scams).

Agreed that there might be other firewall-type attacks, but virtually every type 
of malicious code which arrives by E-mail comes in either HTML-burdened or 
attachment-carrying E-mail.  Restricting who can send you that to a subset of 
your correspondents will result in a probably-similar reduction in your 
vulnerability to attacks arriving that way.  We can probably agree that 
protecting your computer from malicious code isn't the focus of this group;  but 
it is a nice side benefit that the SAME mechanism which will help make the spam 
situation so much better will also help the malicious-code-attack problem too.

>You've made an apriori decision that HTML email isn't okay with you. 

I'm willing to accept it from SOME senders, those who use it responsibly and who 
I trust to not abuse it (and whose transmissions are unlikely to overflow my 
Inbox).

>everyone's life just because of your personal preference.  

The goal is not to "massively complicate" anybody's life, but we ARE trying to 
solve some problems here, and solving them IS GOING TO MEAN changing at least 
some characteristics of the status quo.

>You want 
>this email address?  With this ISP?).  

That is not a key part of my proposal, although if it's only just a matter of 
destination/origin name pairs I would suggest that "keeping track" of every 
correspondent you've exchanged mail with represents a terribly small database by 
today's standards (and that doesn't necessarily need to be on your own machine, 
it could well be at your ISP or domain provider).

> You want to change the default behavior of 90% of the MUAs out there.  

I think that just about everything we have been proposing represents at least 
SOME kind of change, AT LEAST at the ISP level.  One big advantage of what I 
propose is that it can be implemented at a *single* ISP (indeed, even at a 
single *recipient*) and virtually immediately yield a very substantial 
improvmement.

>You want to change the 

Senders don't *need* to change anything, depending on how the system is 
implemented and how the recipient sets things up.  It's possible to handle 
*everything* that's truly required from the sender's end.

(Indeed, you don't even HAVE to involve the ISP, although the Net-wide costs are 
less if you truncate the unwanted mail earlier in the transmission path).

>than a week.  

Changing to plain ASCII text E-mail will get the mail past THAT level, but it 
will (again) deny them the great majority of their most cherished tricks, AND 
make their stuff more readily filtered by content filters.  It makes it harder 
for spammers to confuse, deceive, and trick their victims.  So even when 
spammers "adapt", they _never_ get back to what they had before.

>Because you know what?  They didn't need HTML to sell 2 

No, and you know what?  Any SINGLE person can send any SINGLE fraudulent offer 
to ANYBODY for ANY reason, and there's damned little ANYBODY can do to prevent 
that.  (Hell, your brother-in-law could convince you to buy his lemon of a used 
car, too).  There's no substitute, ultimately, for being intelligent and not 
getting screwed in a bad deal.  What we're trying to do is to put a crimp in 
their gears, and to make life more difficult for spammers and abusers.

As for those who seem so determined to prevent that from happening... one has to 
wonder what their true agenda actually is, and whose side they're on.

>formats people would accept, 

Spammers should NOT be able to just look that up, I think.  It makes their life 
easier, and there's little reason for us to do that for them.  :-)

>and if you could easily keep track of 
>keep track of whether they've received mail from you before.  

Again, those things don't really have to be done, either.

---

From: [email-masked]
Date: Sun, 22 Jun 2003 03:14:46 -0500

>responsibility to do the best he can in forming his utterances...

And the reader or listener, if they don't like the form that the speaker has 
chosen to impose, has the absolute right to walk off or to refuse to listen.

Or, in the case of E-mail, to refuse delivery of E-mail that the recipient 
judges to be excessively bulky or otherwise unwanted, for any reason that makes 
sense to the recipient.

A successful speaker, who presumably wishes to be heard by as many people as 
possible, thus ought to accommodate as many recipients as they can.

>formatted HTML would be the best form in which to construct a message

And if the recipient agrees, they'll probably set their permissions list to 
allow that style of sending.  :-)

In my case (at present at least) my incoming mail filtering system simply (among 
its many other functions!) eliminates all HTML-burdened alternative attachments, 
and if the main body of the message is HTML-burdened then the body is either 
truncated entirely or else the great majority of the HTML tags are entirely 
removed.  [I'm not proposing that as a more general solution for Net-wide 
adoption, but it has been working fairly well for me here.]

tags (not "<b>" tags) and the reader will choose how he prefers to see
emphasis rendered in response to the speakers indication that emphasis
be shown. If all messages are sent in ASCII, then the reader has less
control over the message content than if messages are sent in HTML. 

Again if the reader agrees with you (and finds that the extra bulk and risk of 
HTML is less annoying than the utility to them) then they'll have the option of 
allowing HTML to come through, from anyone they trust and/or even 'everybody'.

The choice OUGHT to belong to the person paying the bill, which in this case is 
usually the RECIPIENT rather than the sender.

> It should not be forgotten that the reader has the option, given

Yes, although it first must be delivered to them (including occupying space for 
however long in the user's ISP-provided Inbox, and consuming bandwidth of their 
perhaps-dialup connection (particularly annoying for overseas users who often 
pay by the minute for their local calls to connect to their ISP... so it's not 
only just TIME, it's also REAL MONEY too).

rather, the fact that most reader's email systems can't be trusted to
display HTML without risks. 

You're ignoring the extra cost (bulk/bandwidth) all the way along the line, too. 
 Typically HTML-burdened E-mail is 3-5x larger than the same exact message 
content in plain ASCII text.

Another BIG issue for some users is how long they can be away from home 
(cruise/vacation/convention/business trip/camping/whatever) and letting their 
E-mail accumulate in their POP3 server(s) before their Inbox overflows and mail 
starts getting bounced.

> We wouldn't be hearing these objections if more readers had systems that had 
the flexibility of web bugs, were better protected against HTML born viruses, 
etc. It isn't HTML that is the problem, it is the software that reads it.

No, in MANY cases it is INDEED the HTML.  But in any case, the users simply need 
an EASY way to express their CHOICE of whether they wish to accept HTML-burdened 
E-mail (or E-mails bearing attachments) from senders from whom they have CHOSEN 
not to accept (or at least NOT chosen to accept) E-mails employing those 
features.

Once the option is available to them, we'd find out soon enough what percentages 
of users choose to keep their acceptance permission list 'how' open, and what 
impact that actually has in real life on the spams (/viruses/worms/trojans) 
arriving in their Inbox, and (eventually) on spams overall, Net-wide.

In any case, it's a cheap and quick thing to try, and is likely to take a 
substantial chunk out of spams, viruses, worms, and trojans.