1730349 - E-mails containing rfc822 parts are mishandled by the GUI (naming, filing)

Status: RESOLVED INCOMPLETE

(Thunderbird :: Untriaged, defect)

Description

[tlhackque]

Attachment: Sample digest email

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36

Steps to reproduce:

Receive a digest format message from a mailing list.
This is Content-Type: multipart/mixed;... followed by (many) Content-Type: message/rfc822 parts

"Many" can be anything from 1 to 50+, depending on the list.

Actual results:

Each rfc822 part is displayed correctly, and also appears as an attachment named "ForwardedMessage.eml". E.g. a digest with three messages will have three "ForwardedMessage.eml" attachments.

It is difficult to identify which attachment corresponds to each message; it it would better if they had unique names - even "ForwardedMessage001.eml" would save counting.

But, once idenitified, out of a digest I sometimes want to file one or two of the messages. Typically, most have little long-term value, but some may be worth keeping, such as those that announce a project, describe a useful technique, or identify a worthwhile contact.

It is possible to save these attachments as files (with right-click "Save As" or "Detach". But it is not possible to save/copy/drag them to a mail folder.

If you double-click on the attachment, the message will open in a new window. But the "Message" -> "Move to" and "Copy to" options are greyed-out. "File"->"Save As" -> "File" are NOT greyed-out, but don't do anything.

You can drag the message from the attachment list to the desktop, but are blocked from dragging it to the message list or folder pane.

If you do drag it to the desktop, you get a filename like "INBOX180642" (with no .eml extension). If you rename the file to have a ".eml" extension, you can open it with Thunderbired. And, strangely enough, "Message" -> "Copy to" is active, and one can copy the message to a file folder.

These issues don't only happen with a digest email; a regular e-mail with an rfc822 attachment behaves the same way.

Expected results:

The attachments, should, ideally be named for easier identification - numbered, or the subject/author, or some combination.

Definitely, there should be a direct option from the attachment bar to copy a .eml attachment to a mail folder. The "Move to" and "Copy to" options should work when a message is opened in a separate window. And the "File"->"Save As" options should work.

Most of the current behaviors described seem to be bugs - though the ability to file a message/rfc822 attachment in an email folder could be considered an enhancement request. I'm calling this a defect report on balance.

The attached file is a sample digest email that exhibits this behavior.

Comment 1

[tlhackque]

Please don't change the bug title without reading the entire problem description. Saying that the issue is just naming trivializes a complex problem.

While naming is an issue, the main user problem is the inability to file attachements into e-mail folders. And the "Save As" and drag options that are active but don't work.

I've changed the title to a more generic form of "rfc822" parts aren't handled correctly.

Comment 2

[Wayne Mery (:wsmwk)]

Does problem reproduce when using newer version (91 for example) with Help > Troubleshoot mode?

Comment 3

[tlhackque]

(In reply to Wayne Mery (:wsmwk) from comment #2)

Does problem reproduce when using newer version (91 for example) with Help > Troubleshoot mode?

Short form: Yes, mostly. Some things seem to have improved, but the big issues remain.

Longer form:
I looked at TB 91.3.0, in "troubleshoot mode"

Open the original attachment in a separate window.

Note that there are 3 "ForwardedMessage.eml" attachments.

Try to drag one to , say, INBOX. You get the "no entry" icon.
Double click on one. Message -> {Archive, move to, copy to, move to ...again} are grayed-out. Mark is not, but all the submenu options are.

Drag to desktop. Now get a file with a .eml extension. The name is the subject of the outer (container - what I actually receive) e-mail, not that of the attachment. So if I try to drag a second attachment to the desktop, Windoze points out the duplicate name. Note this isn't that the attachment name is a duplicate (it is), but assuming that was fixed, the outer e-mail will be the same for all attachments. Dragging an attachment, the subject of the ATTACHMENT should be the file name.

GO-> Next Message is live - but doesn't do anything. Either it should go to the next RFC822 attachment, or be greyed-out.

There is still no right-click option on on the attachment to move it to a folder.

I'll attach a more recent digest from the same list In this case, 2/3 attachments are named for their Subject - but the third, mysteriously, is named "ForwardedMessage.eml". As it turns out, if you look at the message source, all three have the subject "Re: named service suddenly fails to start". Which is why a sequence number in the name would help. And/or the sender's name (though that isn't always unique).

The bottom line is that TB still doesn't consistently name message/rfc822 attachments; when it does, the name's aren't always useful, and the GUI has dead and missing options when viewing the embeded messages.

I may not have listed all the oddities - I encourage anyone to open the attachmed samples and try to work with them.

This isn't unique to this particular list - or to MailMan lists. I have a private application that sends an overview message customized to a recipient, with an attached invitation messgage containing details, a calendar item, etc. These are reliably named from the Content-Disposition header's ""filename", but all the GUI issues (can't file, drag, copy, etc) are the same. I could sanitize such a message if it would help - but I'm convinced that any message containing message/rfc822 attachments (including nested) will behave the same way.

One approach would be to treat the message/rfc822 attachment(s) as if they were in an unnamed, temporary mail folder - I would think that then the rest of TB would do the right things with respect to copy, move, file, etc. E.g. when an rfc822 attachment is encountered, TB might (internally) create an in-memory folder and put it, and any other rfc822 attachments to the main message into it. Then if TB displayed the folder's message list at the bottom of the message, a user could sort (like any other folder's message list), copy, move out, extract, etc. Not clear that copying IN to such a folder is meaningful... Note that this is recursive - an rfc822 attachment can also have rfc822 attachments... Of course, closing the outer message would make the temporary folder evaporate.

I'm not sure this is perfect, but it seems like a better model than "Oh, it's an attachment, you can't X, Y, Z, ..." A message containing message/rfc822 attachments does seem like a folder...

P.S. I thought I'd try dragging the new digest into this (bugzilla) composewindow - the browser decided to open it in a new tab. Perhaps interesting is that the URI was imap://<mailbox>@<server>143/fetch%3EUID%3E/INBOX%3E183059 - which is the same sort of name that TB used to use when dragging to the desktop.

Comment 4

[tlhackque]

Attachment: Another digest message exhibiting these issues

Comment 5

[Wayne Mery (:wsmwk)]

Reporter, does this still fail for you when using version 102 or newer version?

Comment 6

[Phoenix]

Resolved per whiteboard