Re: MIME and hypermail1a15-pl0 (from CVS)

From: Daniel Stenberg <Daniel.Stenberg_at_sth.frontec.se_at_hypermail-project.org>
Date: Sat, 13 Mar 1999 14:10:30 +0100 (MET)
Message-ID: <Pine.GSO.4.10.9903131308270.20904-100000_at_metal.sth.frontec.se>

On Fri, 12 Mar 1999, Craig A Summerhill wrote:

> I am really pleased to say that the version of 2a15-pl0 I pulled down
> from the CVS server this evening has good fixes for all the things I sent
> in earlier. Thanks for the work to clean it up!

Thank you for all the reports, and for always supplying excellent details.

> http://www.cni.org/hm2a15/0012.html
>
> The text contain this MIME Content-Type definition:
>
> Content-Type: multipart/report; report-type=delivery-status;
> boundary="visible_string"
>
> and each part has a Content-Type: of its own.
>
> These are multi-part messages. Each part is ASCII, but the parts are
> being stored as bin files.

This is a complicated problem to which I don't have a clear answer. I need you input, and perhaps we need to study some standards here.

The reason for them being stored is that hypermail only "inlines" text it knows is text. Currently that means that the content-type has to be plain "text" (as mentioned previously here, and which is a violation of the header format) or "text/plain". All other content-types are unknown and therefore will be stored.

In the 0012-case, the types were "text/rfc822-headers" and "message/delivery-status".

As I see it, we have 3 different choices:

1 - Leave it as it is.
2 - Allow all "text/*" and "message/*" headers to be shown.
3 - Make another config file item where you can list all types you want

    hypermail to show "inlined".

I think I favour #3.

> Foreach file (0042) in

 [snip]
> If you look at the HTML markup of this message, you can see that
> hypermail didn't correctly handle the "quoted-printable" encoding. The
> '=' stuff (e.g. =09 for a tab, the =20 for paragraph marker, '=<NL>' for
> continuation of line, etc.) should be removed when hypermail marks up the
> message, shouldn't it?

An obvious bug. The problem was that the parser wrongly set the "decode" type when it found the text/plain content-type. If the headers had appeared in another order it would've worked... :-)

A fixed parse.c is in the CVS repository...

--
             Daniel Stenberg - http://www.fts.frontec.se/~dast
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Received on Sat 13 Mar 1999 03:16:12 PM GMT