[TriLUG] HTML e-mail (was Rant: Please trim responses)

[Tanner Lovelace]

On Fri, 2002-03-22 at 17:52, Rob Napier wrote:

> 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? 

Actually, I was just considering how I could patch my imap daemon
to read compressed mailboxes just yesterday.  It wouldn't be too
hard, and I think I'll go ahead and do it within the next few weeks.

> 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? 

That's assuming you save the message the ID is referring to.

> 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 think this argument is starting to reach ludicrous levels now.  If you
have anything more to add, please do, but reasonable responses please.

> 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. 

If your mailer has trouble with it, perhaps you should consider using 
something besides Outlook.  The extra stuff is beside the point,
however, since, if you thought about it for a minute, it's really 
epsilon compared to what html e-mail adds.  

> 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.

There are plenty of perl modules to read and parse mime.  Next question.
> 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.

Feel free to go write of the new functionality, since you obvious  want
it so bad.  I'm saying I don't want to use it myself, and I don't want
to read from other people.  

> 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."

Show me the code.  You want it bad enough, then quit arguing and start
coding.
 
> 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.

A novel use of the term garbage collection.  I would prefer reference
counting, but I see where you're coming from.
 
> 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.

And now you've hit the nail upon its head.  We *are* limited by our
infrastructure.  The only way to change this is to write something
different.  (Feel free..)

> 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, 

Well, I believe this entire thread started because of people who refused
to trim responses leading to six levels of >'s.  I don't actually
think there's *ever* a need for six levels of >'s so I don't buy 
that argument.  Formating tables, btw, is much easier in text, which
is usually fixed width (except in certain MS products like outlook...)

> 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). 

Noone says you need html e-mail to send pictures.  That's what
mime attachments are for. Mime and HTML are two totally different
things and the fact that you mix them up calls your entire argument
into question.


> So which hassle is more
> important? The point of technology should be to make things easier, not just
> backward compatible forever.

I'll agree on this point, but I still believe text is much
easier than HTML.

> 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. 

Compared to what?  Pine? yes.  Outlook, not even.

> 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.

Yes, they are resources to be used, but they are not infinite.
I chose to use my resources running X and evolution.  If you want
to use yours using Outlook and windows, go right ahead.  If you
even want to use HTML e-mail, go ahead, just don't expect me
to correspond with you.  If you really want things to change,
go out and fix it yourself.  Myself, I'd much rather spend
my time worrying about things that truly mean something,
like defeating the CBDPTA.

BTW, if you respond to me again, please remember to trim
your responses to only the portion you're responding too.
(i.e. there's absolutely no need to quote my entire
signature.)

Tanner
-- 
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
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
         http://www.petitiononline.com/SSSCA/petition.html
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
 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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20020323/0a808bba/attachment.pgp>