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...
Comments
Comment #1
mattconnolly commentedAttached is a patch for 6.x-1.x branch which will handle this situation much better.
Comment #2
mattconnolly commentedAnd another one for the 7.x-1.x branch:
Comment #3
mattconnolly commentedUpdating status to needs review (is that the right thing to do after submitting a patch?)
Comment #4
avner commentedtook 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
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
Comment #5
mattconnolly commentedYeah, 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.
Comment #6
mattconnolly commentedUpdated patch for 6.x-1.0-beta5, 6.x-1.x-dev and 7.x-1.x-dev
Comment #7
trevorbradley commentedThis 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.
Comment #8
afox commented+1 on the RTBC
Marked #1391736: Corrupted attachment via SMTP as a duplicate of this one.
Comment #9
wundo commentedCould someone please reroll for 6.x-1.x and 7.x-1.x?
Comment #10
benclark commentedAlso +1 on the RTBC. Re-rolled 6.x-1.x and 7.x-1.x.
Comment #11
wundo commentedCommitted, thanks! :)
Comment #13
ciwidda commentedCurrent 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
Comment #14
regilero commentedSeems patch on #13 has never been tested and never been ported to 7.x.
Comment #15
wundo commented#13 was published AFTER the ticket was committed. If anyone can review I'd appreciate ;)
Comment #17
asrobI would close because Drupal 6 has reached EOL (https://www.drupal.org/drupal-6-eol).