wangp / bower

A curses terminal client for the Notmuch email system
Other
128 stars 11 forks source link

Multipart/mixed part of email hidden with no indication of attachments inside #111

Closed hgvhgv closed 1 year ago

hgvhgv commented 1 year ago

I received an email from a friend that had a number of attachments but bower only displayed the text/plain portion, hiding the relevant attachments. I think this happened because the first part was text/plain while the remainder (including the attachments) was within a multipart/mixed part. It was from Apple Mail, and IIRC, I've read a number of reports of Apple Mail emails being somewhat poorly formatted (see https://nmbug.notmuchmail.org/nmweb/show/87ty7tr1q8.fsf%40servo.factory.finestructure.net). But bower would still ideally indicate that it's not just an alternative that is hidden but has other relevant parts.

Notmuch emacs shows by default that there is a hidden multipart/mixed part. Alot has a cool feature where attachment parts are identified and listed right beneath the email header info, so it pulls the attachments out here (this would be an alternate solution but require identifying attachment parts and displaying them differently).

I dummied up a version of the email with an empty PDF attached and some info snipped, which has the same issue.

From: ***
Content-Type: multipart/alternative;
    boundary="Apple-Mail=_6C6AFCFE-158B-4CB0-AC27-E90D223AD440"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Subject: Multipart not displayed test email
Message-Id: <test-id-2022-11-30>
Date: Tue, 29 Nov 2022 18:42:02 +0000
To: ***
X-Mailer: Apple Mail (2.3445.6.18)
X-TUID: JtWgIe5AQeb6

--Apple-Mail=_6C6AFCFE-158B-4CB0-AC27-E90D223AD440
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
    charset=us-ascii

[snip] =
[snip] =
[snip] =
[snip] =20

--Apple-Mail=_6C6AFCFE-158B-4CB0-AC27-E90D223AD440
Content-Type: multipart/mixed;
    boundary="Apple-Mail=_5EE6D8B1-894B-4ABE-99E4-85DE33D993AD"

--Apple-Mail=_5EE6D8B1-894B-4ABE-99E4-85DE33D993AD
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
    charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span class="" style="font-family: Calibri, sans-serif; font-size: 14.666666984558105px;">[snip]&nbsp;</span><div class=""><br class=""></div><div class=""></div></body></html>
--Apple-Mail=_5EE6D8B1-894B-4ABE-99E4-85DE33D993AD
Content-Disposition: inline;
    filename="empty-pdf.pdf"
Content-Type: application/pdf;
    x-unix-mode=0644;
    name="empty-pdf.pdf"
Content-Transfer-Encoding: base64

--Apple-Mail=_5EE6D8B1-894B-4ABE-99E4-85DE33D993AD--

--Apple-Mail=_6C6AFCFE-158B-4CB0-AC27-E90D223AD440--
wangp commented 1 year ago

Bower is sticking strictly to the tree structure, which is:

multipart/alternative
 ├─ text/plain 
 └─ multipart/mixed
     ├─ text/html
     └─ application/pdf

If the alternative is a mixed part with attachments, we could hint "z for alternative (n attachments)" or something.

Or, as you say, we could collect up the attachments from the mixed part and show them under the text/plain part as well. I think (commercial) messages might like to include logos and other useless images referenced from the html part, that aren't particularly interesting. Maybe we could ignore parts with "Content-Disposition: inline" as not being "attachments" for this purpose.

hgvhgv commented 1 year ago

Right, makes sense, thanks for clarification. Very annoying of Apple Mail.

Your first suggestion would be a great help, though of course the second would be even more helpful (though, as you can see, Apple Mail at least labeled the attachment here as inline). As I keep learning Mercury, I'll see if I can get the second idea working.

wangp commented 1 year ago

I've added the hint.