[rt-users] MIME parsing not recursive?

[Ferguson, Kevin]

> -----Original Message-----
> From: Smylers [mailto:smylers at gbdirect.co.uk]
> Sent: Friday, July 12, 2002 9:46 AM
> To: rt-users at lists.fsck.com
> Subject: Re: [rt-users] MIME parsing not recursive?
>
...snip... 
> 
> I think we've encountered another 'RT' limit with nested mime parts.
> I'm not completed sure yet[*0], but it's possibly something like this:
> 
>   * If somebody sends an attachment the mail has a media type of
>     multipart/mixed, the first part of which is text/plain and gets
>     forwarded in templates as {$Transaction->Content()}.
> 
>   * If somebody sends plain and HTML mail then the media type is
>     multipart/alternative, the text/plain part of which gets forwarded
>     in {$Transaction->Content()}.
> 
>   * If somebody has the temerity to do both of the above then the mail
>     has a media type of multipart/mixed, the first part of which has a
>     media type of multipart/alternative, which in turn contains the
>     actual message.  {$Transaction->Content()} is empty, so the
>     forwarded mail appears to be messageless.

Actually, this last combination of events works on my system.
Unfortunately, everyone's desktop is Windoze and a lot of them 
like to send html mail along with plain text.  I'm looking at a
ticket right now that matches your description.  The plain text
diplsys just fine in the history section.  Along the right-hand 
border, I see a link to Download (untitled) 423b, which is the 
plain text, a link to Download (untitled) 1.1Kb, which is the 
html text, and a link for the attached word doc 75Kb.  Selecting
the first two links and viewing the source does show that these
are the alternative parts.

Anyway, FWIW...

kevin