Created attachment 2216 [details] simple shell script In "Compose Message" window, I added an attachment (attached here). This is a small shell script, which should be (for me) be 7bit encoded, there is no reason to have it base64 encoded. However, it is sent as base64 attachment (that we can change to correct encoding in "Attachments" tab, then right click/properties on attachment). But, if I attach the same file, but renamed as "lastmatch.txt" instead of "lastmatch.sh", it is correctly encoded as 7bits. For me this is a bug, there is no reason why the same file should be differently encoded when the filename differs. In fact I don't understand at all why a filename extension should be used for encoding decision (for me only the contents of the file should be used, not its name).
It's because Claws Mail only encodes text/* ASCII files (and message/rfc822 files containing only ASCII) as 7bit. if (!g_ascii_strncasecmp(content_type, "text/", 5)) { ainfo->charset = g_strdup(charset); ainfo->encoding = procmime_get_encoding_for_text_file(file, &has_binary); } else { ainfo->encoding = ENC_BASE64; } That's more of an enhancement request than a bug, though.
for how you can influence this behaviour, see https://www.claws-mail.org/faq/index.php/Installation_and_Configuration#How_can_I_change_the_suggested_mimetype_for_attachments_I_am_sending.3F
Colin, Paul, thanks. I will change manually the encoding of attachments when sending source code: my scripts are sometimes ".sh", ".bash" or even have no extension, changing /usr/share/mime/globs will simply not work. Still, the decision to encode according to text/* instead of file contents and to find out mimetype from extension instead of file contents are both questionable for me. In fact, if I copy a binary file (e.g. /bin/ls) to "file.c", Claws will correctly use "application/octet-stream" and base64 encoding, so there are already some content checks beside extension. For me, ideally, if a file (contents) fits in 7bit, 8bit specifications, this encoding should be used. I mean when multiple encodings are possible, the preference should be given in this order: 7bit, 8bit, quoted-printable, base64. But (unrelated to Claws) mime types are always messy for me. Some examples : - Debian states that shell scripts "mime type is nowadays text/x-shellscript but other systems may still use application/x-shellscript" (https://wiki.debian.org/ShellScript), but their /etc/mimes.types and /usr/share/mime/globs don't know about text/x-shellscript. - "file --mime" and "xdg-mime query filetype" give different results for shell scripts (text/ vs application/). - etc... In French I would say "on y perd son Latin" (sorry, cannot find an adequate English wording for that).