#2933: erroneously QP-encoded for PE executable
--------------------------+----------------------------
Reporter: hubertwslin | Owner: mutt-dev
Type: defect | Status: infoneeded_new
Priority: major | Milestone:
Component: mutt | Version: 1.4
Resolution: | Keywords:
--------------------------+----------------------------
Comment (by kevin8t8):
I also see the md5sum of the unzipped file as
b649d4991851c2757734432ce3a0c773.
However, I think the problem hubertwslin was experiencing was that mutt
was setting the content type to text/plain. Since the file has no
extension, mutt has to scan the file and take a guess. If I don't adjust
the content type, then sending the file (as a text attachment) does indeed
corrupt it, so I think that's what this was about.
Taking a look at mutt_make_file_attach(), the key lines are
{{{
if (info->lobin == 0 || (info->lobin + info->hibin + info->ascii)/
info->lobin >= 10)
{
att->type = TYPETEXT;
att->subtype = safe_strdup ("plain");
}
else
{
att->type = TYPEAPPLICATION;
att->subtype = safe_strdup ("octet-stream");
}
}}}
I did a quick scan, and it looks like this file has (approximately):
hibin: 848351
ascii: 21851
lobin: 33596
which gives (l+h+a)/l of about 27 (~4% lobin characters). So the number
of "hibin" characters are what is causing the wrong guess in this case.
I wonder if it would be better to be more conservative when guessing, and
count hibin characters as "binary" too. (l+h+a)/(l+h) would be about 1
(~97% lobin + hibin), which would have given the correct content type
here. Does anyone have an opinion on that?
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2933#comment:3>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
