Changes have been made in Git for this ticket:

Fix Ticket #7361 - content-encoding on strip
Also, general fixes to stripping code (was broken in transition to IMP
5)
Rework stripping algorithm - only allow stripping non-body parts; and
only allow stripping of entire part - not subparts (since subparts may
be required to view parent part). Still a WIP.

http://git.horde.org/diff.php/imp/lib/Contents.php?rt=horde-git&r1=a5de175a9ee0c9d9d30123e1ce3321053285daa1&r2=150496c410d7c650a6e955c8bca758543f90341e
http://git.horde.org/diff.php/imp/lib/Message.php?rt=horde-git&r1=b0b3bce69358f5bed078c5cda76cd912aaf390f2&r2=150496c410d7c650a6e955c8bca758543f90341e
http://git.horde.org/diff.php/imp/message.php?rt=horde-git&r1=a5de175a9ee0c9d9d30123e1ce3321053285daa1&r2=150496c410d7c650a6e955c8bca758543f90341e

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.

Fixed in IMP 5 (or, at least, I could not reproduce with that message).

I was able to save a message before that happened. It's reproducable 
for me with the attached message.

I'm not sure under which circumstances exactly this happens, because 
it's always too late to check the preconditions when I see this. But 
sometime, if I strip (all) attachments from a message, the message 
body is rendered as base64 code.

I'm not sure whether the original message body was base64 encoded and 
the Content-Transfer is wrong after the stripping, or the transfer 
encoding changed to base64 during the stripping.