[Tomas Fasth]

From: Harald Meland <Harald.Meland@usit.uio.no>

...

I haven't tried this, but wouldn't simply squeezing the mail text through the .unmimify() method of the `mimify' standard Python module before formatting it into HTML work (for the QP/base64 MIME issue, multipart messages is a whole other can of worms)?

In the general case it wouldn't, unless there also was some kind of 8bit-character-set -> HTML representation thingy, i.e. something to convert the ISO-8859-1 character "å" into the HTML element "å". Unless there is some standard Python module for doing this, I opt for leaving it all out until after 1.0 is out -- we might as well do this Right from the start.

That's probably one way to go. A good thing trying to use existing code. I'm not sure what exactly .unmimify() does, though.

It converts quoted-printable (and optionally base64) encoded parts to 8bit parts. I does not format it as HTML, though. It also does nothing with regard to "Content-Type:"-type things.

The minimum requirements for messages written in western european languages would be for the archiver's email-to-html conversion to honor the MIME header encoding (RFC 2047) and the basics of MIME body format (RFC 2045).

Do include all of RFC2045 when you say "the basics of MIME body format"? I really can't see the benefit of e.g. parsing multipart/alternative messages and such when formatting them as HTML.

...

Is there a problem with what headers are retained in the mbox-format version of the archive (i.e. are the headers needed for proper MIME decoding stripped from the archive)?

Not as far as I can see. Both Content-* and MIME-Version headers seem to be retained.

Duh, just me looking in the wrong place -- indeed, the listname.mbox/listname.mbox archive does include all headers. BTW, is there any way of configuring which headers (if any) should be removed when generating the static downloadable text files?

Harald