The default bug view has changed. See this FAQ.

Fails to list attachment such as Content-Type:application/pgp-keys, when no Content-Type:name=, no Content-Disposition:filename=, no Content-Disposition:attachment

RESOLVED FIXED in Thunderbird 17.0

Status

MailNews Core
MIME
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: John, Assigned: squib)

Tracking

Thunderbird 17.0
x86
All
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

5 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120310193829

Steps to reproduce:

save the following in a.eml, and open it in thunderbird:

From: user@example.com
To: user@example.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_0_72114_1335034659_000"; charset="utf-8"

This is a MIME-formatted message.  If you see this text it means that your
mail software cannot handle MIME-formatted messages.

--=_0_72114_1335034659_000
Content-Type: text/plain; format=flowed; delsp=yes; charset="utf-8"
Content-Transfer-Encoding: 7bit


--=_0_72114_1335034659_000
Content-Type: application/pgp-keys; charset="utf-8"
Content-Transfer-Encoding: 7bit

mQGiBEmJN8MRBACWZl9AFgXMN20Dsjuwcp8yp5OCE9pqS/drvErLcXHXUxTEATlC
pMNoS5y4MTWtMF+GwkNLR4JxvR7Y6lsSfR2VgrcG/UnyajqZDf8u9YrQ9UWRGVOQ
EkuwpXhk9K0AoJTG5qR/pLbIcf1yqvgkgpyzFoSMAKC4oCZWFxuUtp8HfnDRXwwW

--=_0_72114_1335034659_000--



Actual results:

thunderbird list no attachment, as if no attachment is in this email.


Expected results:

thunderbird should list an attachment there.

If changing the line

Content-Type: application/pgp-keys; charset="utf-8"

to

Content-Type: application/pgp-keys; charset="utf-8"; name="pubring.gpg"

then thunderbird will be able to list the attachment.

However, RFC2045 does not require the "name=" field in Content-Type.  Ie, thunderbird did not follow RFC2045.

This is especially a problem when working with sqwebmail.  In sqwebmail we can export our pgp key by composing an email in sqwebmail and attaching our own pgp keys, then open the received email in email clients, save the attachment and import to desktop pgp software.  The mail produced by sqwebmail does not contain "name=" field, Outlook can list the attachment, but thunderbird doesn't list attachment so users get confused.
Currently, part shown as attachment at attachmen pane == ( has attachment parameter in Content-Disposition: ) || ( has filename in Content-Disposition: || has name in Content-Type: ), mainly for historical reason.
This produces problem like this bug in following two cases.
- Not-inline-displayable attachment part like application/pgp-keys etc.
- Not-inline-displayable application/octet-stream part
And next case is known on malused application/pkcs7-mime part.
- bug 705059
  even when Content-Disposition: attachment, part is not displayed
  as if attachment, per spec of application/pkcs7-mime.

In RFC, "filename of Content-Disosition:" is merely a file name recommendation by mail sender when attachment is saved as file by mail recipient.
In RFC, "attachment/inline of Content-Disosition:" is sender's request, but "inline of Content-Disosition:" never prohibits "save as file by mail recipient".
I also think "What shoul be shown as attachment at attachment pane" should be sorted out.

Currently available workaround.
- mailnews.display.show_all_body_parts_menu = true
  (via Tools/Options/Advanced/eneral, Config Editor)
  View/Message Body As/All Body Parts
- Save the attachment part
- Change back to mailnews.display.show_all_body_parts_menu = false for daily use
John are the workarounds working ?

Wada is this a duplicate ?
(In reply to Ludovic Hirlimann [:Usul] from comment #2)
> Wada is this a duplicate ?

Phenomenon itself is already known in other bugs by intentional test mail. However, IIRC, there is no clear bug report for actual "no filename/no name, no attachment parameter" case. Because "no filename/no name, no attachment parameter" is actually written in a RFC as "recommended" example in this bug's case, RFC violation of Tb is apparent. Duping to other bug is needed? I think duping of part of other bugs to this bug is better.
Status: UNCONFIRMED → NEW
Component: Message Reader UI → MIME
Ever confirmed: true
OS: Linux → All
Product: Thunderbird → MailNews Core
QA Contact: message-reader → mime
Summary: fails to list attachment when Content-Type has no "name=" field RFC2045 → Fails to list attachment such as Content-Type:application/pgp-keys, when no Content-Type:name=, no Content-Disposition:filename=, no Content-Disposition:attachment
(Reporter)

Comment 4

5 years ago
(In reply to Ludovic Hirlimann [:Usul] from comment #2)
> John are the workarounds working ?
> 
> Currently available workaround.
- mailnews.display.show_all_body_parts_menu = true
  (via Tools/Options/Advanced/eneral, Config Editor)
  View/Message Body As/All Body Parts
- Save the attachment part
- Change back to mailnews.display.show_all_body_parts_menu = false for daily use

Oh, a much easier workaround that we use is to forward the mail in tb, then the received mail will display the attachment.

Of course, these workarounds assume that we anticipate that email has an attachment.
(In reply to John from comment #4)
> Oh, a much easier workaround that we use is to forward the mail in tb,
> then the received mail will display the attachment.

Thanks for easy/simple workaround operation.
"Forward" looks to access the hidden part normally and looks to set filename/name and Content-Disposition:attachment.
> Content-Type: application/pgp-keys; name="Attached Message Part"
> Content-Disposition: attachment; filename="Attached Message Part"
For ad-hoc/one-time-only "save to local file" purpose, there is no need to send mail because "Save of attachment at Forward window" is possible, although file extension of .tmp should be changed manually after save.
(Assignee)

Comment 6

5 years ago
Created attachment 625454 [details] [diff] [review]
Fix this

This is easy enough to fix. The new behavior I settled on for when we show an attachment in the attachment pane is as follows:

1) if Content-Disposition is "attachment" -> show
2) else if the attachment can't be displayed inline -> show (this is the new
   condition)
3) else if there's no filename whatsoever -> hide
4) else if the filename was provided by the user -> show
5) else if "Show All Body Parts" is on AND we don't want metadata only -> show
6) else -> hide
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Attachment #625454 - Flags: review?(dbienvenu)
(Assignee)

Comment 7

5 years ago
Created attachment 625456 [details] [diff] [review]
Fix this (properly)

Oops, I forgot to update ProcessBodyAsAttachment as well. Fixed.
Attachment #625454 - Attachment is obsolete: true
Attachment #625454 - Flags: review?(dbienvenu)
Attachment #625456 - Flags: review?(dbienvenu)

Comment 8

5 years ago
Comment on attachment 625456 [details] [diff] [review]
Fix this (properly)

looks reasonable, thx for the tests!
Attachment #625456 - Flags: review?(dbienvenu) → review+
(Assignee)

Comment 9

5 years ago
Checked in: http://hg.mozilla.org/comm-central/rev/f0d80c468f79
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 14.0
(Assignee)

Updated

5 years ago
Target Milestone: Thunderbird 14.0 → Thunderbird 15.0
Looks like this broke unit tests in gloda:

https://tbpl.mozilla.org/php/getParsedLog.php?id=11936731&tree=Thunderbird-Trunk
Backed out due to the unit test failures:

https://hg.mozilla.org/comm-central/rev/dba50267fd10
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 12

5 years ago
Created attachment 626267 [details] [diff] [review]
Fix gloda tests

Argh, gloda; I thought I'd checked that, but apparently not. This patch fixes gloda tests locally for me. protz, you wrote the tests for this, and the original "Part 1.2"-hiding code; do my test changes look ok to you?

Try build in progress: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=68c46c12dd86
Attachment #625456 - Attachment is obsolete: true
Attachment #626267 - Flags: feedback?(jonathan.protzenko)
(Assignee)

Comment 13

5 years ago
Comment on attachment 626267 [details] [diff] [review]
Fix gloda tests

It looks like the try tests are passing, so flagging this for review.
Attachment #626267 - Flags: review?(dbienvenu)
Comment on attachment 626267 [details] [diff] [review]
Fix gloda tests

Both the test in libmime and the new gloda tests look fine to me! Does

+    name: 'test message with part 1.2 attachment',
+    attachments: [{ body: 'attachment',
+                    filename: '',
+                    format: '' }],

still generate a MimeUnknown container?
Attachment #626267 - Flags: feedback?(jonathan.protzenko) → feedback+
(Assignee)

Comment 15

5 years ago
(In reply to Jonathan Protzenko [:protz] from comment #14)
> Both the test in libmime and the new gloda tests look fine to me! Does
[snip]
> still generate a MimeUnknown container?

Based on the documentation for MimeUnknown, it should.

Comment 16

5 years ago
Comment on attachment 626267 [details] [diff] [review]
Fix gloda tests

gloda tests pass with this, thx.
Attachment #626267 - Flags: review?(dbienvenu) → review+
(In reply to David :Bienvenu from comment #16)
> Comment on attachment 626267 [details] [diff] [review]
> Fix gloda tests
> 
> gloda tests pass with this, thx.

Jim , did you forget to land this ?
(Assignee)

Updated

5 years ago
Duplicate of this bug: 778750
(Assignee)

Comment 19

5 years ago
(In reply to Ludovic Hirlimann [:Usul] (away until August 5th) from comment #17)
> (In reply to David :Bienvenu from comment #16)
> > Comment on attachment 626267 [details] [diff] [review]
> > Fix gloda tests
> > 
> > gloda tests pass with this, thx.
> 
> Jim , did you forget to land this ?

So I did. I'm going to push to try again and then land this.
(Assignee)

Comment 20

5 years ago
Try build in progress at https://tbpl.mozilla.org/?tree=Try&rev=60768152bb99
(Assignee)

Comment 21

5 years ago
Pushed to comm-central: http://hg.mozilla.org/comm-central/rev/c18a0f719011
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 15.0 → Thunderbird 17.0
You need to log in before you can comment on or make changes to this bug.