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;

Attachment: signature.asc
Description: PGP signature

Reply via email to