Jargons of Info Tech industry

[Matt Garrish]

Your post brings up a meta-issue. How long should posts be?
I note several schools of thought.

Your post brings up a usenetiquette issue. Why do you think that
perl/python/java/c people are interested in your personal discussions of
email?

Matt

 

[Stefaan A Eeckels]

I didn't say they were. Obviously you haven't been reading my emails,
just reacting against them mindlessly. I use a mail client that gives
me the choice of displaying or not displaying HTML emails. If there
is no alternative to HTML, then I may _choose_ to render the HTML.

Norm Reitzel said it all a while ago:

"I don't understand that attitude. Don't we want email that has dancing
bears, cute little videos, musical tunes, animated waving hands, sixty
fonts, and looks like it's been done with crayolas? Good grief, man,
think like a three year old!"

 

[Steven D'Aprano]

That is a hair shirt approach. What if someone is sending photos of
their new house?

Oh gosh, pictures of a new house. Why didn't you say so??? If you're
sending pictures named "my_new_house1.jpg" etc then OF COURSE they have
to be imbedded in a HTML email, otherwise how could anyone know what they
were?

What if I am sending diagrams to help someone repair
their computer? It is ridiculous to tie people's arms behind their
backs. What you do instead is work to prevent abuse. Captions in and
of themselves are not dangerous things.

I didn't say they were. Obviously you haven't been reading my emails,
just reacting against them mindlessly. I use a mail client that gives
me the choice of displaying or not displaying HTML emails. If there is no
alternative to HTML, then I may _choose_ to render the HTML.

But there is always an alternative. You can always send me a Word
document, a PDF, an Powerpoint presentation showing the steps one per
page, why the possibilities are endless.

You could even send me a URL to a webpage.

 

[Steven D'Aprano]

Imagine a main sending emailed floor tile samples to his wife on a
business trip for her final veto and not being allowed to caption
them.

I don't have to imagine it, I've done it, more or less something like this:

"Dear wifey,

here are five pictures of the tiles I like. My favourite is tile02.jpg.
They are all in the price range we can afford. You pick the one you think
suits best, then call Freddy at TileMart on blah blah blah and order them.
We'll need X square metres."

Sheesh Roedy, to listen to you go anyone would think that human
communication was impossible before HTML email was invented.

 

[Gordon Burditt]

And how do you fix the problem of unsolicited USENET articles?

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

I talk around those problems.

It requires a fresh start.

This URL does not work. However, from some of the other replies,
it seems that your suggestion involved identification of the sender
with digital signatures.

I think one necessary function of email and USENET is that it should
allow you to SAFELY communicate with strangers or, worse, people
you know but do not trust at all, and who are known to be malicious,
if you wish to do so, especially since meeting in person might
invoke the use of weapons of mass destruction (like, for example,
me and my hypothetical ex-wife).

For example, George W. Bush ought to be able to exchange email with
Osama Bin Laden without risking revealing nuclear launch codes.
Hitler and Winston Churchill should have been able to exchange email
(had it been available during World War II) without revealing state
secrets accidentally. I ought to be able to exchange email with
my boss without his being able to track if/when I read it. I ought
to be able to communicate with the Direct Marketing Association to
get them to take my name off a mailing list without risking spyware
installation or revealing my credit card numbers. Union leaders and
management should be able to negotiate by email without unwittingly
leaking information.

HTML is *mostly* dangerous. (links. Javascript. references to
other files on the user's computer. Forms.) It's a lot more than
text formatting. I suggest that if you want a text formatting
language, start with *TROFF* and take out the parts that refer to
other files. As far as I know, troff doesn't have any networking
references in it. Lots of people probably hate troff, but it's a
better start than HTML.

Gordon L. Burditt

 

[Mike Meyer]

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

HTML is a problem on *other* peoples crappy software as well. It
wasn't designed to carry code content, but has been hacked up to do
that.

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

Sure - just disable all the features that make people want to use HTML
instead of something else.

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

Which would mean that every open format that MS has had anything to do
with comes a vector for viruses. Somehow, I'm not buying it.

And HTML has more problems than just viruses - web bugs, for one. But
MIME's support for external bodies gives you that anyway.

<mike

 

[Mike Meyer]

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.

It's not confined to just people - software can do this as well. In
particular, you should expect that the users mail agent will have to
have access to the key, so it can automatically send out the change of
address notice when the user changes their address (it actually needs
it to send any mail). Viruses regularly make users mail agents do
thing. "Change my address" becomes much more entertaining when that
triggers sending out change of addresses notices to everyone in the
address book. More likely, though, there'll be an API for getting the
key so that users can change mail agents without invalidating the
public key that everyone they correspond with has for them, and the
virus will just use that API.

This is also why his plan doesn't stop spam. Most spam comes from
zombies already. This will just cause them to masquerade as the owner
of the owned machine rather than somebody the author has a beef with.

<mike

 

[Steven D'Aprano]

You might say what about those free 10 mb websites? That's not very
many images with today's megapixel digital cameras.

My system admins have a number of names for people who try to send
multi-megabyte files by email. The names start with "accursed of God"
and rapidly get worse. Email is not designed to cope with such large file
sizes, and if you are running virus scanners and spam filters -- and you
should be -- performance rapidly goes downhill from there.

I think we computer folk owe the public

We don't owe the public *anything* if they don't pay for it. We might
*choose* to build it for free, but that's our choice, not a duty.

[snip]

I wrote an essay years ago on how such an email system might work.

Ah, I see. Another pie-in-the-sky replacement for email. Well, good luck
with it. I wish you every success, but don't ask me to buy shares in your
startup.

 

[Mike Meyer]

Perhaps you could slow them down with some randomly chosen questions
to prove they know something about you. Companies could do the same
thing.

Challenge-response system are old hat. I use one, and it reduces my
spam by three orders of magnitude. Most of what's left is spam that
went to a list that I've subscribed to whose mail circumvents the
anti-spam feature, and nigerian scam type things, which violates one
of the assumptions that such systems make about spam.

The downside is that I have no idea how many people try to contact me
out of the blue, or from an address other than the one I sent mail to,
but don't bother to answer the response.

You can inconvenience the sender to a fair degree since most people
don't often write strangers with the expectation of a personal
correspondence.

Right. Nobody sends email to addresses that come off business cards,
or off a web site, or ....

<mike

 

[Giorgos Keramidas]

Normally you send photos to grandma with captions under each photo.
That is far more convenient for the technopeasant receiver than
dealing with multiple attachments.

I'd like to agree, but I haven't received *ANY* properly formatted,
captioned and readable list of photos in an HTML email message in a
long while. What I usually get it an email message with a completely
irrelevant subject -- usually a reply to a random thread that happened
to include my email address in the recipient list -- with a message
body as useless as:

Here's a photo collection

or even more useless, or empty.

This and other things, that show the original poster of the particular
HTML email message has _no_ intention to spend just *one* minute to
properly write a readable, useful email message, tend to be the main
reasons why I block all HTML email messages from non-work-related
email addresses, save them in a special folder and look at them only
when I really feel like spending some time to weed through the junk.

 

[Mike Meyer]

Since this is just a broad brush view, I find it odd you can predict
just what bugs there will be in the early implementations.

I'm not predicting bugs in the implementations. I'm predicting how
people are going to abuse *features* of the implementations.

You sound almost as if you were the author of the current system and
feel personally attacked by others looking for ways to improve it.

Nah, I've just know people who spend a lot of time - and money -
dealing with spam, and we've discussed these issues at great
length. You haven't proposed anything that hasn't been proposed
before, and rejected for various reasons.

In my scheme, every message is digitally signed, even a change of
address message.

Yup, I assumed that.

Surely for a virus to send out a digitally signed change of address
message is more difficult than sending out an unsigned one, which they
can do today.

Maybe yes, maybe no. They can use existing APIs to send mail now. If
there's an API to sign a message - and there just about has to be,
otherwise changing mail readers will require sending out a change of
address form to change the public key - what prevents the virus from
simply using that to send out an encrpyted message? Yes, it's more
difficult, just like it's more difficult to send out mail with an
attachment than one that's just plain text. But the difference is just
more work, not something fundamentally different.

You have two problems you want to avoid:

1. the practical problem: failure to inform your correspondents, not
just your address list, of your new address (at least the ones you
don't consider spam or pests).

2. the potential problem: rogue software sending out fake change of
address notices.

In my scheme, The receiver of the change of address message ignores
it unless it is properly signed. Surely that is a more secure system
than we have today and that handles (1) without effort. At worst, a
very clever virus could change the one address book entry, the one for
this computer, in other's machines. It could not generally corrupt
other machines.

Depends on how convenient you make things. The problems aren't
technical, they're social. For instance, people will want their
address book to automatically send out change of address notices to
every non-pest if their address is changed. A virus can exploit this
by changing the address in the address book. No need for it to send
out mail - the users mail agent does it all for them. Fixing this
requires convincing the users that they should do a lot of work to
achieve point 1 - which sort of defeats your purpose.

Personally, I don't believe that you'll convince people to take do
more work to get more security. So you've got to convince all the
authors who deploy mail readers - and/or key security systems - to not
allow that. Since such a feature will be requested by users, and will
make their software more popular, that's not going to be easy either.

To be really secure, you store the private key encrypted, and ask the
user for a passphrase to decrypt it every time you want to sign a
message. So you make your interface do that, and it asks the user for
a key every time a message is signed. For true security, you have to
include the recipient address in the signatture, otherwise you're
liable to replay attacks sent different addresses, so changing your
address will involve providing your pass phrase once for everyone you
notify. Someone else will decide that's to inconvenient, and provide
an interface that stores the passphrase to reuse for some
user-specified length of time. Existing systems do this, and get lots
of use even thought they are less secure than doing it right. Then
you'll get a interface that ask for the key once a session. Then
you'll get one that asks once, and just keeps it forever. We've seen
this happen with access to web site passwords.

Guess which one users are going to prefer. Guess which one makes it
simple for viruses to hijack they system to send out mail that "you"
have signed.

<mike

 

[John Bokma]

For how long. Surely attachments are a stop gap. Can you imagine
people sharing images that way 100 years from now?

No, but I agree with you I am not using HTML myself in email, but I
will when it makes things easier.

Why should we wait for the future? The problems blocking easy to use
photo sharing are not technological but social.

Yup, agreed. Like I already wrote, if I route all HTML email to /dev/null
I'll lose some customers, and some friends

 

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

And even more convenient is "Hey grandma, check out the latest
photos on my web site: www.example.com/rich/photos".

In principle you're right but you forgot:
"And hey grandma, use this account name and this password for accessing
this web page."

Ciao, Michael.

 

[axel]

No, but I agree with you I am not using HTML myself in email, but I
will when it makes things easier.

Yup, agreed. Like I already wrote, if I route all HTML email to /dev/null
I'll lose some customers, and some friends

What I find is that when I see emails which are obviously spam, I
simply do not read them and delete them immediately. But then I
use Pine rather than a web browser... and while some forms of HTML
may be rendered, nothing is automatically pulled down.

Axel

 

[axel]

What have you got against captions?

Giving photos captions is a *very* common practice.

Why not just put them on a web page? It is then possible to include
thumbnails so the recipient can chose to see which ones he cares to
look at in detail.

It also allows the web address to be sent to several people
without wasting bandwith.

Axel

 

[Alan Balmer]

I take it then you avoid browsers or use Lynx? No you FIX the
problems rather than wear a hair shirt. Same for email. Why should
rich expressions only be permitted to those with websites.

Some people use email PRIMARILY for sharing photos.

And they don't know about attachments?

 

[Alan Balmer]

She doesn't need captions in the album because she will explain the
pictures, at length, every single one of them, to anyone who comes
within grabbing distance.


If your photos are so banal then only people who would recognise the
people would care about them.

Captions are for people who won't recognise the subject of the photo.
When you send a photo of a house to Granma is she supposed to just
_know_ that it your new house, or the one across the road, or the one
that burnt down last week ?

You might try something truly innovative, like including a line in the
email that says "Hi, Grandma, here's a picture of our new house."

 

[Alan Balmer]

In any case, html email is here to stay. Or perhaps I should remove html
and say "richly formatted", whatever that might mean in the future.

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.

Deal with it.

And you're calling other people control freaks!

Sorry to burst *your* bubble, but no one has to "deal with it." For
centuries, intelligent people have managed to convey information using
plain text, and they'll manage for the foreseeable future.

I'm surprised that you can bring yourself to write articles in such a
humble venue as Usenet.

 

[Rich Teer]

But there is always an alternative. You can always send me a Word
document, a PDF, an Powerpoint presentation showing the steps one per
page, why the possibilities are endless.

Why saddle you with a proprietory format (M$ Office), when StarOffice
and OpenOffice do the job just as well, for much cheaper (and are cross
platform too)?!

You could even send me a URL to a webpage.

Indeed!

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

 

[Mike Meyer]

The "user mode" uses style sheets you specify.

There's a whole bunch of built-in ones - and you can cascade them:

Yup, saw those.

``There is also the inclusion of 12 packaged user style sheets and an easy
menu application interface (View > Style). These sheets can be cascaded
together, with or without the page's styles.

How do you set things to cascade those with the page's styles? I
couldn't see anything obvious in the UI, and the Opera help pages
didn't provide much help either.

Thanks,
<mike