Re: ARGH! Mutt 1.5. breaks attachments behind my back
On Wed, Oct 06, 2010 at 05:18:03PM +0200, Stefan `Sec` Zehl wrote:
I found an annoying bug in mutts attachment handling which took me 2
days to debug.
Whenever you attach a file of content-type "application/pgp", mutt
re-encodes every 0x0a in the file into 0x0d 0x0a before base64-encoding
and sending it.
The bug is not easily noticed, because if you save this attachment from
within mutt, it reverses this transformation.
Mutt currently assumes application/pgp parts are produced by Mutt itself, so
it is attempting to canonicalize the line endings. I suppose the solution is
to add a bitfield to the BODY structure where it can be indicated that the
user has manually set the content-type and not perform any automatic
conversion.
me
You can easily reproduce this:
echo 0: f00df00af00d0a | xxd -r > test.src
cp test.src test.bin
cp test.src test.pgp
mutt your@xxxxxxx
interactively attach "test.bin" and "test.pgp", for "test.pgp" make sure
that the content-type is "application/pgp" -- if not, change it by using
control-T.
Send the email (to yourself)
rm test.bin test.pgp
Open the received email in thunderbird(or any other mail-client besides
mutt) and save both attachments
run "openssl md5 test.*"
| karoshi:~>openssl md5 test.*
| MD5(test.bin)= 5937882f7a1431c4751d80d22dd4d2f4
| MD5(test.pgp)= c4ee0efbf416a7394681d01b96a0126a
| MD5(test.src)= 5937882f7a1431c4751d80d22dd4d2f4
the "application/pgp" file is clearly modified.
The interesting point is. If you use mutt to save the attachments again,
thy appear unmodified because mutt reverses the newline-encoding on
saving.
Note that mutt 1.4 doesn't do this (as far as I've tested)