[Tickets #7361] Re: Wrong transfer encoding after stripping attachments

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7361
------------------------------------------------------------------------------
  Ticket             | 7361
  Updated By         | Aarno.Sandvik at helsinki.fi
  Summary            | Wrong transfer encoding after stripping attachments
  Queue              | IMP
  Version            | HEAD
  Type               | Bug
  State              | Resolved
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Aarno.Sandvik at helsinki.fi (2009-11-30 07:28) wrote:

This happens ( at least with imp 4.2.2) when both message body and  
attachment are base64 encoded. When stripping attachments the mail is  
copied over with the attachments stripped out and imp changes the mail  
body encoding to quoted-printable which renders the mail unreadable  
for the user.

The problem starts when on line 566 of horde/imp/lib/Message.php  
imap_append is called with $contents->toString($message,true) as one  
of the parameters. This call ends up(after several strange twists) in  
horde/lib/Horde/MIME/Part.php and it's getTransferEncoding-function.  
Within the second case 'text' elseif tries to find line feeds that  
have more than 998 characters in between them or 998 characters before  
"\n"-characters. After inserting some additional logging I found out  
that the mail has "^M"  instead of "\n" at this point and so the  
regexp returns true every time if the mail is longer than 998  
characters.

I fixed this by adding && $encoding!='base64' to the elseif-statement.  
I have not tried the latest imp5 edition so I'm not sure if this is  
fixed in it. Also I'm not 100% sure that this doesn't brake something  
else so use at your own risk.