View Issue Details

IDProjectCategoryView StatusLast Update
0015164phpList 3 applicationAttachmentspublic23-03-09 16:48
Reporterwnicholls Assigned To 
Status resolvedResolutionfixed 
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.


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



31-07-08 12:22

reporter   ~0050145

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.


01-08-08 00:53

reporter   ~0050147

You can downgrade the severity to "minor" as I've logged the real issue as #0015165. Easy-looking fix though.


04-11-08 18:47

updater   ~0050241

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


23-03-09 16:47

administrator   ~0050594

thanks for finding that.