[composer] inline attachment's name and mime type are not being handled properly on reply
Bug Summary
Actually, general speaking, Geary doesn't handle inline attachments, inserted from files, pretty well, because the original file name is used interchangeably as the CID, which is not the case for those inline files coming from a message being responded to that uses a CID not equal to the file name.
Geary composer handles inline files as buffers stored on a map whose key is the CID (Content-Id) completely forgetting about the original file name (and mime type if available) if it was inserted from a path or loaded from an attachment when replying (also paths to the “cached” files).
This is a problem when responding to a message with, let's say, an
inline file whose CID is something like email-like@code.com
and
the file name is my-signature.jpg
, i.e. (copied from here):
To: email@email.de
Subject: ...
Content-Type: multipart/related;
boundary="------------090303020209010600070908"
This is a multi-part message in MIME format.
--------------090303020209010600070908
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#ffffff" text="#000000">
<img src="email-like@code.com" alt="">
</body>
</html>
--------------090303020209010600070908
Content-Type: image/png;
name="moz-screenshot.png"
Content-Transfer-Encoding: base64
Content-ID: <email-like@code.com>
Content-Disposition: inline;
filename="moz-screenshot.png"
[base64 image data here]
--------------090303020209010600070908--
If you try to reply to the message before, Geary Composer Widget will handle the inline file as an attachment like:
Content-Type: application/octet-stream <-- The mime type is replaced to Geary.Mime.ContentType#ATTACHMENT_DEFAULT, also no `name=` field
Content-Disposition: inline;
filename="email-like@code.com" <-- Geary uses the CID as file name before sending, the composer doesn't have context about the original file.
Content-Transfer-Encoding: base64
Content-Id: <email-like@code.com>
This message, once sent, will be flagged as INSECURE since the file is interpreted to be a COM file (executable).
Your installation
To obtain installation information, copy it from Geary's Problem Report dialog if shown (or else open the Geary Inspector by typing Shift + Alt + I) by selecting System, and clicking the Copy button, then pasting here.
- Geary version: 44.1 (tags/44.1-0-g37c378a56)
- Installation method: Package
- Desktop environment: GNOME
- Operating system and version: Archlinux
- Email provider: N/A
Steps to reproduce
- Receive a message containing an embedded (inline) image whose CID is different from the file name.
- Reply to that message (keep the full quote).
- The new message, containing the full quote, replaces the inline file name to the CID and completely forgets about the MIME, replacing it to
application/octet-stream
- If the CID of the original-message-inline-file ends with
.com
(likesome-hex-hash@provider.com
) your reply message will be flagged as INSECURE (some time silently) and probably will never get to your addressee because of the “extension” being the same as the one used by COM files.
What happened?
Geary uses CID as file name, and forgets its original MIME, of inline attached files (images).
What did you expect to happen?
Geary should handle CIDs and file names, of inline attached files, as different properties. Also should about guessing the MIME from those files inserted from a PATH or from a message part (when replying a message)
Relevant logs and/or screenshots
N/A