[rt-users] MIME parsing not recursive?

Ferguson, Kevin KFerguso at chi.navtech.com
Fri Jul 12 15:17:56 EDT 2002

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


More information about the rt-users mailing list