[TriLUG] Rant: Please trim responses

[Rob Napier]

> -----Original Message-----
> From: trilug-admin at trilug.org
> [mailto:trilug-admin at trilug.org]On Behalf
> Of Tanner Lovelace
> Sent: Thursday, March 21, 2002 2:27 PM
> To: trilug at trilug.org
> Subject: RE: [TriLUG] Rant: Please trim responses
>
> On Thu, 2002-03-21 at 11:49, Rob Napier wrote:
> > Which brings me to my next abbreviated rant (I've been thinking of writing
this
> > up at length, but haven't really wanted to dive into it): computers and the
> > internet do not exist only for geeks. The rest of the world considers them
tools
> > to get a job done. To this end, most of the geek complaints about email
> > ettiquite revolve around the fact that we're worried about how the system
works,
> > while most users are worried about how to *use* it to get their work done.
>
> I disagree.  I believe most of the rants (at least mine) are
> about things that make it take longer for me to get things done.
> Whether that corresponds to how the system works or not is
> irrelevant.
>
> > Consider HTML mail. We scream about it. Why?
>
> Hmm... maybe because when you send an html e-mail the e-mails
> are anywhere from 30% to 60% larger than they would be if you
> sent the equivalent e-mail using plain text.  You may have unlimited
> disk space and bandwidth, but don't automatically assume everyone else
> does too.

This is precisely the kind of argument that I'm discussing in the first
paragraph, tied up with how the system works rather than how people want to use
it to get work done. Holding to the lowest common denominator (9600 baud modem
vt100) prevents us from ever moving forward. If bandwidth/diskspace were really
the concern, why aren't we geeks screaming for compressed POP? Why isn't mbox
compressed? Couldn't we save another 30% to 60% by saying don't quote text at
all; just refer back to the MessageID and an offset; your mail client can
recreate it at read time? We don't care about the handful of bits; we just want
something to hate HTML for. There are tons of things we could do to reduce
bandwidth and disk usage much more than forbidding HTML, but we don't go there
(why don't we compress /etc? why do we install X at all?) I'm not even
mentioning your 12 line signature ;D I will mention that you add an extra 248
bytes to every message with your GPG signature, something that my mailer doesn't
handle particularly well and adds extra space to every mail. That kind of stuff
can be a pain if I'm pulling mail via perl scripts (MIME is a pain). But that's
ok; it adds good functionality for you and others, so I adapt my tools to deal
with it. I don't consider you rude for using it. I consider my mailer lacking
for not handling it well, and look for ways to fix my mailer, not you.


> > HTML is a free, open standard. It
> > has readerers on every platform you could want. And it adds useful
> > functionality. Is it a good formatting language? No. But the usual
complaints
> > aren't that we should be using SGML or TeX or the like. The complaints are
"I
> > can't read it conveniently with my mailer."
>
> No, my main complaint is the size.  Oh, that and many spam companies
> send me html e-mail with image links that point back to their website.
> One of the main reasons I switched to evolution was that there was no
> way to get netscape/mozilla not to load these images.  Why is this a
> problem?  Consider, if you will, a spamming company.  They have this
> list of e-mail addresses.  They don't know for sure if they all work
> or not.  But, they send an HTML e-mail with an img tag that points
> back to their server, perhaps with a special tag for each user they
> sent it to.  I receive it and load it up in my HTML enabled mail
> program.  It gladly goes and downloads the image from the spammer's
> server.  Bingo!  The spammer now knows that my e-mail address is
> valid and I get a lot more spam.  Don't believe me?  This is exactly
> what happened to my wife recently.

And saying "I demand that my HTML reading mailer include a don't follow offsite
links" option is reasonable (kmail does this). Or better yet, asking permission
on a domain-by-domain basis, much the same way that Konqueror does with cookies.
That has nothing to do with HTML itself. We should be demanding (and writing via
OSS) better ways to implement new functionality; not just saying that new
functionality is bad or wrong to use.


> > Then get a mailer that can. This
> > idea that everything has to be readable on a vt100 is insane (even though
HTML
> > will render just fine on a vt100), and completely misses the point of using
> > computers to get work done. It's *good* that they can do new things, and
> > formatting is valuable. You may have found ways around it (note the *'s I
use
> > above because I can't use bold), but why should the entire world "work
around"
> > the problems of people who will never upgrade. This is common of many geek
> > complaints. We've worked around not having something, or we don't need it
for
> > our jobs, so it isn't important. I say this as a recent HTML-ranter who has
> > recently realized what I hypocrite I was being. Can HTML be overused? Sure.
So
> > can 10-line ASCII signatures. But that doesn't mean that formatted text
isn't a
> > good thing (and something we had for years before email; and now we're
supposed
> > to give it up?)
> >
>
> Whether formated text is a good or bad thing is beside the point in my
> arguments above.

Not at all. If formatted text is good, then I say it's up to us (the geeks) to
design how it should be implemented, not say "don't use formatted text."


> > I'm not going to go into the detail here (may later), but another one to
soul
> > search about is attachments. User mails attachment to 100 other users. This
is
> > bad for the system, but it's what the user meant to do (and has lots of
> > advantages over "posting to a web page and sending a link"). Are the
problems
> > with the system evidence of a dumb user (doing the obvious), or is it
evidence
> > that we haven't developed an infrastructure that handles what users want to
do.
> > Think for a few minutes about how you would design an email system that
*could*
> > handle this kind of use. Shouldn't take long (I'll send you the answer if
you
> > like, but we're all smart geeks here. Hint: garbage collection). Who's fault
is
> > it that we don't have that system?
> >
> Garbage collection?  Okay, you through me there.  Please explain.  I
> don't believe, however, that you can actually explain it to my
> satisfaction.  (How's that for a challenge? :-)

I send a message including an attachment (actually, this works equally well for
the mail message itself, so pretend that's an attachment, too). My server notes
that some of the addressees are its clients. It saves a copy of the message and
sends a link to its clients. It forwards the whole message on to other mail
servers, who do the same thing. It might also just send links to the other mail
servers, rather than the entire mail message. There are tradeoffs that should be
tunable by the administrators.

When a user decides to read the message (versus just filtering it into the trash
for instance), the user fetches it from the server, but just the attachment that
is actually being read. The user's mail client can choose to cache the
information locally, or even copy the whole thing down and remove its link to
the server copy.

Whenever the server copy's link count goes to zero, it garbage collects the
message.

This means that for a given set of users on a single mail server, there is
generally just one copy of an attachment. And it isn't sent to the users until
they actually need it. Tradeoffs of responsiveness versus disk space should be
tunable by users and admins. So for instance, closely related mail servers with
fast links might just keep one copy of the message among them and forward users
around, while unrelated mail servers might copy the message the first time a
user actually requests it. Truly distant mail servers might just forward the
mail when its first sent, to reduce latency on the first read.

This kind of mail system can add additional functionality, such as pulling back
messages that were sent too quickly, status of message functionality (printed,
saved, deleted, etc; obviously privacy needs to be considered here, but could be
defined by the user's mail client). All these were features we had in the first
mail system I installed, WordPerfect Office in 1989 or so. They were lifesavers
in many cases.

Our sendmail infrastructure is extremely decentralized and lightweight. In the
1980s it was enough for the purposes intended. But it's time we asked our mail
system to do more, and the fact that sendmail can't handle it is an indication
that it's time we moved beyond sendmail, not that the functionality isn't
needed.


> > It's time to stop blaming users for wanting to get their jobs done without
> > having to always worry about how the tool is implemented. It's time we
started
> > implementing better (and more functional) tools.
>
> I believe my arguments above stand on their own merits and
> are completely independent of your complaints.

Your first argument was that it was harder for you to deal with. That argument
extends all the way to email itself, since many people don't have access to it.
The point is that you actively choose not to deal with HTML mail; the tools are
all readily available (and free). Your move to Evolution demonstrates this as
well as anything. The other side of the argument is that text mail is harder for
many people to deal with. Formatting tables, dealing with six levels of >'s and
the associated wrapping, setting up a web site so that you can post the two
little pictures you wanted to send, it's all a huge hassle (as well as having
other disadvantages that I can go into later). So which hassle is more
important? The point of technology should be to make things easier, not just
backward compatible forever.

The second argument was related to bandwidth and disk space. And you switched to
Evolution? That's a juxtaposition ;D The point is the same. You moved to
evolution to get more functionality. That required moving to a big, bloated
system. Linux won't run worth anything on an 8M box anymore (can you even boot
the latest kernels in 8M?) X Windows is a pig; we should stay 100% on the
command line, right? Memory, bandwidth, disk space. They're all resources. We
shouldn't waste them, but they are meant to be *used*, and by themselves do not
damn functionality to the scrap bin, even functionality that we have found ways
to get by without.

Rob


> --
> Tanner Lovelace | lovelace at wayfarer.org | http://wtl.wayfarer.org/
> --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
> GPG Fingerprint = A66C 8660 924F 5F8C 71DA  BDD0 CE09 4F8E DE76 39D4
> GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
> --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
>  Those who are willing to sacrifice essential liberties for a little
>  order, will lose both and deserve neither.  --  Benjamin Franklin
>
>  History teaches that grave threats to liberty often come in times
>  of urgency, when constitutional rights seem too extravagant to
>  endure.  --  Justice Thurgood Marshall, 1989
>