Bug #20536 for Email-MIME-Attachment-Stripper: Nested multipart messages are not handled correctly (I think)

Tue Jul 18 12:03:29 2006 DROLSKY [...] cpan.org - Ticket created

Subject:

Nested multipart messages are not handled correctly (I think)

Ok, I haven't actually tested this, but I think this is true from reading the code. Basically, the module seems to assume that you're always stripping attachments from relatively flat structure, basically a message where the main content type is multipart/mixed, and it contains a text/plain body and then some attachments. I think that if it were given a more complex structure it would produce some weird results. Imagine the following: multipart/mixed | |-- multipart/alternative | | | |-- text/plain | | | |-- text/html | |-- application/pdf I think that in this case the multipart/alternative part would be considered an attachment, which is not a good thing. I think the fix for this is to make sure that the content-disposition header matches /attachment/, not just that it _doesn't_ match /inline/. Of course, this means that the part in question would be entirely thrown away, but I think that's okay, as this module seems to be designed to be destructive of the original structure.

Thu May 29 22:18:27 2008 rt.cpan [...] sartak.org - Correspondence added

From:

sartak [...] gmail.com

I'm seeing this bug as well. It causes Hiveminder to lose attachments on forwarded messages (particularly from gmail). Attached is a copy of an email that does not have its attachment correctly detected, if you're in need. :) Shawn for Best Practical

From: Sartak <sartak@gmail.com> Subject: Fwd: This is a banana MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_347_2143023.1212112482563" ------=_Part_347_2143023.1212112482563 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: Sartak <sartak@gmail.com> Date: May 29, 2008 9:53 PM Subject: This is a banana To: sartak@bestpractical.com, sartak@gmail.com Peel it before you enjoy. ------=_Part_347_2143023.1212112482563 Content-Type: application/octet-stream; name=banana.pl Content-Transfer-Encoding: base64 X-Attachment-Id: f_fgu4erjf Content-Disposition: attachment; filename=banana.pl IyEvdXNyL2Jpbi9lbnYgcGVybAp1c2Ugc3RyaWN0Owp1c2Ugd2FybmluZ3M7CgpkaWUgImJhbmFu YVxuIjsKCg== ------=_Part_347_2143023.1212112482563--

Thu May 29 22:18:30 2008 The RT System itself - Status changed from 'new' to 'open'

Thu Jun 26 17:43:19 2008 dougbitcard [...] claar.org - Correspondence added

From:

dougbitcard [...] claar.org

In this rather common case: Show quoted text

> multipart/mixed > | > |-- multipart/alternative > | | > | |-- text/plain > | | > | |-- text/html > | > |-- application/pdf

The problem is th t the code recurses into the multi-part, finds the plain text, and drops it on the return. There's a pretty simple fix: return that part from the recursive call. I've attached a diff -c/patch file.

*** Stripper.pm.1.314 2008-06-26 13:30:39.000000000 -0700 --- Stripper.pm 2008-06-26 13:41:11.000000000 -0700 *************** *** 121,127 **** push(@keep, $_) and next if $ct =~ m[text/plain]i && $dp =~ /inline/i; push @attach, $_; ! $self->_detach_all($_) if $_->parts > 1; } $part->parts_set(\@keep); push @{$self->{attach}}, map { --- 121,130 ---- push(@keep, $_) and next if $ct =~ m[text/plain]i && $dp =~ /inline/i; push @attach, $_; ! if ($_->parts > 1) { ! my @kept=$self->_detach_all($_); ! push(@keep,@kept) if @kept; ! } } $part->parts_set(\@keep); push @{$self->{attach}}, map { *************** *** 137,142 **** --- 140,147 ---- : ($_->filename || ''), } } @attach; + + return @keep; } 1;

Tue Jul 08 21:27:25 2008 rjbs [...] cpan.org - Correspondence added

fixed in 1.315 thanks, all -- rjbs

Tue Jul 08 21:27:28 2008 rjbs [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #20536 for Email-MIME-Attachment-Stripper: Nested multipart messages are not handled correctly (I think)

Preferred bug tracker