This patch changes the text/plain vs application/octet-stream type guessing code to count hibin characters as binary. Feedback welcome, but I think if mutt is guessing, it's probably better to be more conservative and not corrupt the attachment. (See ticket 2933)
-Kevin
# HG changeset patch # User Kevin McCarthy <[email protected]> # Date 1418764359 28800 # Tue Dec 16 13:12:39 2014 -0800 # Node ID cb3797549ad07d8ed9842690517965c8fc1d994b # Parent 39d3ddb56d340f66ffd0fe476003645f4cdc30bc Make attachment type guessing more conservative. (closes #2933). When guessing the type of an attachment (with no mime type or extension), mutt currently considers 8-bit characters as "text" when calculating the percentage of text characters in the file. In some cases, such as for the sample attachment in this ticket, it leads to a binary executable being labelled as text/plain, which results in the the attachment being corrupted when mailed. This patch considers 8-bit characters as binary for the calculation. In general, it's probably better to guess wrong on the conservative side than possibly corrupt attachments. diff --git a/sendlib.c b/sendlib.c --- a/sendlib.c +++ b/sendlib.c @@ -1379,20 +1379,21 @@ if ((info = mutt_get_content_info (path, att)) == NULL) { mutt_free_body (&att); return NULL; } if (!att->subtype) { - if (info->lobin == 0 || (info->lobin + info->hibin + info->ascii)/ info->lobin >= 10) + if ((info->lobin == 0 && info->hibin == 0) || + (info->lobin + info->hibin + info->ascii) / (info->lobin + info->hibin) >= 10) { /* - * Statistically speaking, there should be more than 10% "lobin" + * Statistically speaking, there should be more than 10% "binary" * chars if this is really a binary file... */ att->type = TYPETEXT; att->subtype = safe_strdup ("plain"); } else { att->type = TYPEAPPLICATION;
signature.asc
Description: PGP signature
