Jargons of Info Tech industry

[Steven D'Aprano]

I would suggest then a better solution is to implement CSS in email,
the way you do in browsers to deal with that same problem.

Are you volunteering? Good. Let me know when your done, I'd love to see it.

In the meantime, I'll continue viewing emails in plain text, and if they
contain HTML I'll choose for myself whether to render it, or trash it, or
manually read through the code looking for content.

 

[Stefaan A Eeckels]

So from an aesthetic point of view, once people learn how it works,
CSS lets sender and receiver compromise on what the message looks
like. No other medium gives ANY control to the receiver about how a
message is formatted.

My mail reader renders HTML as text. Usually, that gets the message
through without the impediments the sender included.
Of course one can render anything in one's computer exactly the way one
wants, given comptence and time. Mutual agreement on a CSS is possible,
but for widespread usage it needs to be a standardised CSS, and then
we're back in the featuritis spiral.

One of the most important changes in the ability to select special
fonts for the those without prefect vision and larger fonts.

That's exactly why I don't want people to muck with the presentation of
an email. I've set up my machine to render standard ASCII emails
execatly the way I want, with the font that I can read, in a size that
optimises ease and visible text. I don't care that someone would like
to inline a 5000x3000 JPEG from their 15 megapixel camera, or render
text in white on black, or any other silly format. If they want me to
see a document in _exactly_ the way they prepared it, let them use PDF.
It's there, and it works well.

There is also the philosophical question. When my nephew sends me a
message, do I have a right to warp his intent even if I don't like the
aesthetics? That is part of his message.

That question is answered above - if your nephew wants you to see
exactly what he produced, let him use the format specifically designed
for the purpose. And yes, philosophically speaking the recipient can do
anything they like with the message, including not reading it at all.
Anything else would be preposterous.

Should my email reader fix the spelling mistakes in the emails sent me
by angry US soldiers? Or is that part of the message?

If you want it to do that, yes. Wheter including the corrected message
in the reply is a good idea is another question (mostly related to how
the relation is, how it should be, and how big the soldier in question
is).

There are three different issues getting muddled together:

1. avoiding spam

Which happens to use HTML to obfuscate the message and avoid getting
caught by filters.

2. making mail from well meaning but inept friends more readable.

Who happen to use HTML because they don't have a clue.

3. what constitutes a good general style for general correspondence.
How should you use rich text appropriately.

Which happens to be largely superfluous as far as conveying intent is
concerned.

Email works well without rich text, especially when combined with
attachments that use a format sender and recipient have agreed to.
We don't need more, and we shouldn't assume that more complex
technology equates to an improvement. Example: it's not because we can
use a gazillion typefaces in pastel colours that documents that we
should do so.

Take care,

 

[Mike Meyer]

Why don't you download a copy of Opera, see
http://mindprod.com/jgloss/opera.html

What makes you think I don't have a copy of Opera? Just so happens
I've got a registred copy on my newest computer.

Then try out the feature. Click View | style | user

My copy of Opera doesn't have that menu entry. I suspect you're making
platform-specific suggestions.

Trying it on a different platform, it looks like it does what I said
earlier: user mode simply disables the authors style sheets. None of
the "merging" you suggested was going on is actually happening

Can you demonstrate this "merging" you talked about? For example, show
me how to get the "Opera help" page to display with the authors layout
but my fonts.

<mike

 

[Steven D'Aprano]

that is like giving up Java because there was a bug in the Windows
JVM. FIX THE BUG.

Only Microsoft can do that. They designed their font system in such a way
that it ignored real typesetters measurements, probably so it would be
deliberately incompatible with font sizes on the Mac. Either that or just
through incompetence. Now, it is almost certainly unfixable in Win9x and
XP -- it would break too many people's Word documents and web pages.
Microsoft could maybe fix it in Vista, if they care too. As if it matters
what they put in Vista.

But that isn't going to stop lusers setting the font size to 5pt or 55pt
just because they think it is kewl. Until we can send fatal electric
shocks through the Internet, there is little we can do to stop that.

 

[Paul Rubin]

So the rest of the world should forgo rich communication because of
your obsolete software? How could anything every evolve with that
attitude?

There is nothing obsolete about lynx. It completely conforms to the
w3 standard. Anyway, email is a text medium and attempts to "evolve"
it almost always make it worse.

 

[Mike Meyer]

There is no fundamental reason that formatted spam should have an
easier time penetrating your defenses than plain text spam.

Formatted spam can include pictures of words. That's a common spam
tactic - send a multipart/alternative with a text part that look like
a letter from aunt jane - and mention that you're sending a
picture. The picture part is basically a jpeg of a flyer for the spam
companies product.

If you've got a spam filter that can determine that a picture of words
is spam, I'd like to know about it.

<mike

 

[Steven D'Aprano]

Now, if you want to get into a big huff because someone you knows use a
font that is "slightly oversized" because of Windows, then I think you
missed the point of the email altogether, which was probably to convey a
message.

Talk about missing the point, pun intended. The point isn't that there is
some tiny difference in font sizes. It is that small font sizes which are
just readable under Windows are unreadably small on Linux and Mac.

If you want to convey a message, it helps if the recipient can actually
read the damn thing without having to get out a magnifying glass.

 

[Steven D'Aprano]

Oh, and another point...

But trying to keep your email world into a pure text-based
no-formatting-whatsoever world, that's a fantasy bubble that is bound to
burst, sooner rather than later.

Nonsense. I can easily set up a filter to dump non-plain text email
straight into the trash. If I choose, I never need see a HTML mail. Ever.

In fact, since the single strongest predictor of spam is the use of HTML,
I predict that a lot more people than you think have HTML emails either
deleted or dumped in a spam folder.

 

[Mike Meyer]

Let procmail make all those decisions and transformations for you.

I prefer qmail dot-commands. It provides an architecture for
controlling the delivery of email, and lets you write the smarts of
the mail processing in whatever language you want.

I have a maildir called 'raw' where I keep a copy of all non-spammish
mail.

I call mine archives. I also remove duplicate email before it gets to
the mailbox.

Copies of the same messages also get delivered in the right mailboxes,
by procmail.

Yup, qmail does that for me.

A message that contains only html, is piped though lynx -dump -stdin.

I build a bounce message explaing that it wasn't read, and send that
back to the sender.

A message containing both HTML and a plain/text-part, is de-mime-d,
leaving only the plain/text-part (unless that part contains only a silly
remark).
Footers and long signatures are limited or even deleted. Etc., etc. (I
like my mail cooked.)

I don't do those things. Then again - my mail reader makes deals with
them on request.

One of the reasons that I started with Perl, is that I want to rewrite
procmail in Perl.

Try qmail - it may solve the problem with a lot less work.

<mike

 

[Steven D'Aprano]

Just how long do you want to stall evolution?

Evolution doesn't mean "use whatever broken solution Microsoft and Hotmail
popularized, just because all my friends are using it."

If and when somebody puts out a good rich text email format, I'll use it.
Until then, I won't use HTML.

Do you imagine people 200 years from now will be still be using pure
ASCII text unable to find a solution to JavaScript viruses (turn off
JS), pop-up( disable popups) etc.?

Firstly, I don't care what people will be using in 200 years. I don't care
if in 200 years the default email format is so big and bloated that it
takes three weeks to download even a single sentence, because I won't be
around to suffer.

If you think that people will be using the current data formats for email
in two centuries, you're crazy.

 

[Steven D'Aprano]

Normally you send photos to grandma with captions under each photo.

No, normally YOU send photos to grandma with captions under each photo.
My grandma doesn't put captions in her photo album, and she doesn't need
captions on her photos in email.

That is far more convenient for the technopeasant receiver than
dealing with multiple attachments.

Only if your photos are so obscure and confusing that they need captions.

"Here's Johnny with the dog. Here is Johnny with the dog again. This one
is Johnny on his own. Here is the dog. Oh look, it is Johnny with the dog
again -- that's the dog on the left, in case it isn't clear. Just for a
change, this is Johnny wearing a hat. It is blue with a feather in it,
in case you couldn't tell from, oh I don't know, looking at the actual
picture."

 

[Steven D'Aprano]

There is nothing wrong with formatted text. You are confusing
formatted text with spam.

No. YOU are confusing HTML email (broken, dangerous, bad) with formatted
text (maybe good, maybe bad).

I've hated HTML emails well before I received my first spam. I still hate
it, long after I've got my spam problem under control.

If and when somebody comes up with a non-broken, non-dangerous way of
allowing formatting in emails, I'll consider it. But HTML is not and never
will be that format.

 

[Steven D'Aprano]

So the rest of the world should forgo rich communication because of
your obsolete software? How could anything every evolve with that
attitude?

Hardly obsolete, any more than hammers are obsolete just because we have
Concords.

(The Concord... now *there* is an obsolete technology.)

You may have noticed that even Microsoft have acknowledged the power and
flexibility of text-based shells, and will be (if they get the technology
right in time) building one into Vista.

 

[Steven D'Aprano]

The photo doesn't have to be included (as in attached)? with the email?

I'll repeat the question: what do attachments have to do with HTML emails?

 

[Dr.Ruud]

Mike Meyer:

Try qmail - it may solve the problem with a lot less work.

I checked my .procmailrc, and saw that mail with qmail anywhere in the
headers, goes to a spambox here.

 

[Tim Tyler]

The technial problems have been solved for over a decade. NeXT shipped
systems that used text/richtext, which has none of the problems that
HTML has. The problems are *social* - you've got to arrange for
people to use mail/news readers that understand a rich text format
that isn't a vector for viruses.

It's not HTML that has problems, it's Microsoft's crappy software.

Writing virus-free HTML renderers is not hard - but of course
Microsoft can still screw it up.

Don't blame HTML for viruses - *every* document format Microsoft has
anything to do with becomes a vector for viruses.

They *even* managed to get virulent spreadsheets and word processor
documents!

 

[Tim Tyler]

No, normally YOU send photos to grandma with captions under each photo.
My grandma doesn't put captions in her photo album, and she doesn't need
captions on her photos in email.


Only if your photos are so obscure and confusing that they need captions.

"Here's Johnny with the dog. Here is Johnny with the dog again. This one
is Johnny on his own. Here is the dog. Oh look, it is Johnny with the dog
again -- that's the dog on the left, in case it isn't clear. Just for a
change, this is Johnny wearing a hat. It is blue with a feather in it,
in case you couldn't tell from, oh I don't know, looking at the actual
picture."

What have you got against captions?

Giving photos captions is a *very* common practice.

 

[Tim Tyler]

Actually, you present a design that forces a solution that makes them
do what you want down their throats, never mind what they want, or
what they've been doing. It shows an amazing ignorance about the
internet and how people behave on it. Like most antispam proposals, it
won't actually stop spam, just force spammers to concentrate on
different channels. You seem to have randomly broken quoting for
people who download mail and read it offline, and for any medium
that's unreliable or doesn't reliably deliver messages "in order" -
which includes mail and news. Virus writers will love the ability to
change peoples address books remotely.

Since - in Roedy's essay - messages are digitally signed, authority
to advise about any email address updates would presumably be confined
to those people with access to the sender's private key.

Even /without/ any form of authentication, a standard change-of-address
message - which is understood by mail readers - is a fine and sensible
idea.

 

[Tim Tyler]

Read my essay.
http://mindprod.com/projects.html/mailreadernewsreader.html

FYI, this bit:

``Like ICQ, someone cannot send you mail without your prior permission.
They can't send you mail because they don't have your public key to
encrypt the mail.''

....is pretty confusing - because "public key" is a term with a technical
meaning in cryptography - and a public key really *is* public.

If you want to allow email only from a list of senders, then you use
a simple white list. Cryptography is not needed or desirable if this
is the intended goal.

 

[Tim Tyler]

Roedy Green wrote:

People in their sky-cars turning off JavaScript in their browsers: what
a thought!

Javascript can be turned off in *mail readers* - by their manufacturers.