MIME parsing not recursive?

RT Users
1

I often send attachments in MIME to RT and they are parsed fine: Web
users see the attached document, they can click on it and it works
(depending on their browser’s setup).

But, if the attachement is itself made of parts (MIME is recursive),
such as when I forward a multipart message from mutt with
"mime_forward" set, RT only displays the “top level” part, when the
user clicks on it, it sees the encoded subparts.

Is it a limit of RT, a feature or a misconfiguration from me?

2

I often send attachments in MIME to RT and they are parsed fine: Web
users see the attached document, they can click on it and it works
(depending on their browser’s setup).

Speaking of which, http://www.amsterdamned.org/~bc/rt/mimefind.pl (and
mimefind.usage) may help in dealing with annoying Microsoft mail programs
and ‘application/octet-stream’ for any attachment.

But, if the attachement is itself made of parts (MIME is recursive),
such as when I forward a multipart message from mutt with
“mime_forward” set, RT only displays the “top level” part, when the
user clicks on it, it sees the encoded subparts.

Is it a limit of RT, a feature or a misconfiguration from me?

I think RT is only going one level down. The table structure encourages
nested attachments, but the process putting them in doesn’t. RT bug.

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security
3

Bruce Campbell wrote:> On Fri, 12 Jul 2002, Stephane Bortzmeyer wrote:

But, if the attachement is itself made of parts (MIME is recursive)
… RT only displays the “top level” part, when the user clicks on
it, it sees the encoded subparts.

Is it a limit of RT, a feature or a misconfiguration from me?

I think RT is only going one level down. The table structure
encourages nested attachments, but the process putting them in
doesn’t. RT bug.

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.

The result of the above is that we have a tendency to ignore messages
from people who send HTML mails with ‘Word’ documents attached.
Actually, maybe that isn’t such a bad thing …

[*0] And I fear that I’ll have to find a Windows computer with a
sufficiently broken MUA to try it out.

Smylers
GBdirect

4

-----Original Message-----
From: Smylers [mailto:smylers@gbdirect.co.uk]
Sent: Friday, July 12, 2002 9:46 AM
To: rt-users@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

5

From: Smylers [mailto:smylers@gbdirect.co.uk]

  • … 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. …
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.

Yes, I also get that: the plain text part is displayed fine in the
history section. However, it isn’t included in messages sent out by
scrips activated by the arrival of such a mail.

Watchers receive mail with an apparently blank message content, but if
they go to the URL for the ticket they can see what the message should
have been. (That however relies on the watchers realizing what has
happened, and not merely dismissing the message to them as spam.)

Smylers
GBdirect