Re: [Fsfe-uk] Administrivia: html duplicates

[Chris Croughton]

On Sat, Jan 26, 2008 at 11:06:01PM +0000, Alex Hudson wrote:
> 
> On Sat, 2008-01-26 at 22:10 +0000, Jon Grant wrote:
> > I don't think there is any noticeable difference in Thunderbird loading 
> > my mailbox or email msg which are in HTML (CPU increases in last decade 
> > eliminated any conversion time cost). Perhaps this is just mutt "not 
> > being very good"? ;) If it is, why not just swithc to a "better" client?

No, I'm running mutt on my home machine, which fetches it using
fetchmail.  CPU time is not a problem, disk reading time is.

What 'better' client?  Oh, mutt isn't perfect but it works over ssh in
text only mode just fine.  I tried pine and Do Not Want.  Way back elm
wasn't bad but it was a pig to build (no autoconfigure and on several
systems I never got it to build at all).

> In technical terms, there shouldn't be vast difference between loading
> plain text mails and loading HTML mails - for the most part, that
> information comes from an index, so the actual size/content of a mail is
> inconsequential.

I don't know what keeps an index, mutt certainly doesn't because it uses
straight .mbx format with all emails in a file (OK, multiple files which
I sort into using procmail, but for instance AFFS list is a single
file).  So when it reads it in it has to read the whole file.

> Ditto the actual on disk storage: in terms of file size, sure, HTML is
> bigger. In terms of file system blocks, it's less clear - for the most
> part, HTML mails take the same number of blocks in storage.

Only if you have one email per file and that is less than an allocation
unit (inode, bock, whatever).  However, since a typical email on this
list is a little over 5kB (23704903 bytes / 4617 mails = 5134) that's
just over a 4k inode on average as pure text which would be probably 3
times that with the same in HTML.  Unless your blocks are 8kB or above,
in which case you are wasting most of the space anyway.

> And in terms of bandwidth: to be honest, unless you're blocking spam
> mails based on envelope, it's irrelevant anyway, because hams make up
> such a small proportion of overall mail.

That depends where you do filtering.  Yes, in terms of total net
bandwidth (or for an ISP) it's insignificant, but for those who do their
spam filtering at a server it is significant compared to the spam which
gets through.

> I don't think the pure technical argument is persuasive. The practical
> argument is much more relevant - in terms of the HTML actually emitted -
> but on technical grounds, I actually think HTML wins the theory.

Well, how about a social argument -- it gets people annoyed and they
don't bother reading the messages?

Chris C