The strip headers function fails when an attachment part has more than three lines of headers, causing base64 encoded attachments to become corrupted.

In my case, the attachment's body part appears like:


Content-ID: <1c0626f8957ec3fd38fee3f2b9defd43@localhost>
Content-Type: application/zip;
    name="Courier2_B816E6FE-E480-4CDE-9821-7FA792037C6F.zip"
Content-Disposition: attachment;
    filename="Courier2_B816E6FE-E480-4CDE-9821-7FA792037C6F.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAFKHzz71H0Z9BwEAALIBAAAxAAAAQ291cmllcjJfQjgxNkU2RkUtRTQ4MC00Q0RF
LTk4MjEtN0ZBNzkyMDM3QzZGLnhtbI2Qy2rDMBBF94H8g9FeluTEryIrpH5ACu2ijddBjkUqsCUj

...etc...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mattconnolly’s picture

Attached is a patch for 6.x-1.x branch which will handle this situation much better.

mattconnolly’s picture

And another one for the 7.x-1.x branch:

mattconnolly’s picture

Version: 6.x-1.0-beta5 » 6.x-1.x-dev
Status: Active » Needs review

Updating status to needs review (is that the right thing to do after submitting a patch?)

avner’s picture

took me some time to figure this one out
the Content-Transfer-Encoding: base64 is not removed from the data and is embedded as part of the file

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="drush-cheat-sheet.pdf"

ContentTransferEncodingbase64JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0x
lbmd0aCA1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdWMtu20YU3esr7q4...

i tested your patch
the function you created works on version 6.x-1.0-beta5,
however,
it seems to be created for the dev version,
when applying on dev i am getting the PHPMailer's error "Message body empty"
or am i missing something here?

I apologize for not debugging this more closely,
it seems that i do not need this function after all
hopefully i will have the time next week to work on this

mattconnolly’s picture

Yeah, the empty message body is another issue caused by the patch above, which I found a fix for. Basically the problem occurs where there is a multipart/alternative (html+text) part within a multipart/mixed message (for example, which may contain attachments). There is code there to explicitly handle this case, but the newer smarter stripping of the headers caused that processing to fail.

I'll submit a patch against 1.0beta5 including this fix as well shortly.

mattconnolly’s picture

TrevorBradley’s picture

Status: Needs review » Reviewed & tested by the community

This fixed my problem with attachments! However these patches are "reversed" and would patch the fixed version into the broken one. Be sure to use -R if you're using patch.

afox’s picture

+1 on the RTBC

Marked #1391736: Corrupted attachment via SMTP as a duplicate of this one.

wundo’s picture

Status: Reviewed & tested by the community » Needs work

Could someone please reroll for 6.x-1.x and 7.x-1.x?

benclark’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
2.48 KB
2.35 KB

Also +1 on the RTBC. Re-rolled 6.x-1.x and 7.x-1.x.

wundo’s picture

Status: Reviewed & tested by the community » Fixed

Committed, thanks! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ciwidda’s picture

Current function generates corrupted attachment with huge filename.
Causes: to respect the RFC822 rules about maximum line length of 60 characters reported in Mimemail module (mimemail.inc, func ' mimemail_rfc_headers', line 21) the mimetype and name of attachment got splitted onto 2 lines that the _smtp_remove_headers couldn't support and genereted corrupted attachment on base64 decode operation.
Solution: patch attached

regilero’s picture

Status: Closed (fixed) » Needs review

Seems patch on #13 has never been tested and never been ported to 7.x.

wundo’s picture

#13 was published AFTER the ticket was committed. If anyone can review I'd appreciate ;)

  • wundo committed cb23ce2 on 7.x-2.x
    Issue #1189940 by mattconnolly, benclark, afox, TrevorBradley: Fixed...
asrob’s picture

Issue summary: View changes
Status: Needs review » Closed (outdated)

I would close because Drupal 6 has reached EOL (https://www.drupal.org/drupal-6-eol).