Bug 4066 - font/ttf mimetype attachments get attached with no Content-Type
Summary: font/ttf mimetype attachments get attached with no Content-Type
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-08-07 08:16 CEST by martin hosken
Modified: 2018-09-12 12:06 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martin hosken 2018-08-07 08:16:18 CEST
When a .ttf font is attached to a message, the multipart header does not contain a Content-Type and so receiving applications do not recognise the attachment.

For example:

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=Test-Regular.ttf

This seems to be because the top level font mimetype is not recognised by Claws-Mail and the data is treated as unknown/ttf and that results in no Content-Type being output.
Comment 1 Ricardo Mones 2018-08-07 12:58:31 CEST
Here (latest git in Debian stable) ttf files are attached with MIME type “application/x-font-ttf”.

Are you sure you have an up to date MIME database in your system?
Comment 2 martin hosken 2018-08-07 15:48:31 CEST
In Ubuntu 18.04 /usr/share/mime/globs has font/ttf:*.ttf

I remember there being something about giving .ttf a proper mimetype rather than a private use code and this must be it.
Comment 3 martin hosken 2018-08-07 16:05:23 CEST
BTW here's the list of what's in that new font/ top level:

font/collection:*.ttc
font/otf:*.otf
font/ttf:*.ttf
font/woff:*.woff
font/woff:*.woff2

I wonder if we just say: unknown maps to much like application but with the mimetype just copied in?