NOTE:: Before reporting an issue, make sure you are running the latest version, currently 3.3.1

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015164phplist applicationAttachmentspublic31-07-08 12:0523-03-09 16:48
PlatformOSOS Version
Product Version2.10.5 
Target Version2.10.10Fixed in Version2.10.10 
Summary0015164: Attachment data is double-wrapped in MIME-encoded message
DescriptionSteps to reproduce.
1. Create a message
2. Add an attachment (eg a PDF file)
3. Send test message (or queue, doesn't matter)
4. View the message source as received.

Observed: - message data snakes like this:

Content-Type: application/pdf; name="test.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.pdf"



Note the first line is 76 chars with a blank line after it, second line is 75 chars, third is the 1 remaining, fourth line is 74 chars, then the remaining 2 etc.

Inline images (eg the Powerphplogo.png) are encoded 76 chars per line (plus LF), only attachments get this weird behaviour.

This may be the PHPList factor in the "microsoft exchange corrupt PDF" bug that many have alluded to.

I found this while trying to diagnose that perhaps 5-10% of recipients of a mailout reported "there were no attachments to the message" (or words to that effect). There were FOUR... I'm still looking for pattern there, but MS Exchange is not a factor for most. One user has a Mac using Apple Mail. (also they report the attachments are missing, not that they are corrupt)
Additional InformationI can think of one obvious cause for this: attachment data is being base-64-encoded and then fed through chunk_split() twice with a chunk size of 76.
(Another thought I had is that the data is encoded with 76-char lines, then wordwrapped at 75, but that doesn't seem to be borne out).

In lists/admin/class.phplistmailer.php is the following method

    function EncodeFile ($path, $encoding = "base64") {
      # as we already encoded the contents in $path, return $path
      return chunk_split($path, 76, $this->LE);

This looks dicey to me, if it is already encoded, why chunk_split again? However if I change this code to simply { return $path; } then attachments are correctly encoded, however inline images aren't wrapped at all.

Alternatively further up in add_attachment, change the line:

     $this->attachment[$cur][0] = chunk_split(base64_encode($contents), 76, $this->LE);

    $this->attachment[$cur][0] = base64_encode($contents);
This seems to work, but I'm not confident enough that it is the true fix, especially since there is ANOTHER "class.phpmailer.php" in the phpmailer subdirectory.
I'm leaving it on my server for now, but I'm keen on getting another opinion. Also the code in svn may have moved on - but 2.10.5 is the current stable release, and I'm running out of spare time to look into this issue.

TagsNo tags attached.
Attached Files

- Relationships
related to 0012126resolved Receiving corrupt PDF attachments 
related to 0015437closedmichiel content-type 'multipart/related' may result in problems with attachements 

-  Notes
wnicholls (reporter)
31-07-08 12:22

I'll just confirm this code appears (at first glance) to be the same in the current CVS head and so I expect my patch would also work on that.
wnicholls (reporter)
01-08-08 00:53

You can downgrade the severity to "minor" as I've logged the real issue as #0015165. Easy-looking fix though.
lwc (reporter)
04-11-08 18:47

No, this IS the real issue. It was also reported in #12126.

Anyway, I'd like to confirm I used the alternate solution, and it worked!

Thank you so much, wnicholls!

Now can someone please make this official (after answering to wnicholls' question in the end)?
michiel (manager)
23-03-09 16:47

thanks for finding that.

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker