Closed
Bug 632961
Opened 14 years ago
Closed 13 years ago
invalid "Content-type: multipart/related; boundary=..." mime multipart handling
Categories
(MailNews Core :: MIME, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 674473
People
(Reporter: raoul, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: testcase)
Attachments
(1 file)
|
3.06 KB,
message/rfc822
|
Details |
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b12pre) Gecko/20110206 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110209 Thunderbird/3.3a3pre
i got a forwarded message from an @me.com account (X-Mailer: MobileMe Mail (1C3224))
thunderbird does not correctly parse the message and the attached pdf is not correctly displayed.
other email clients do not seem to have this problem, e.g. roundcube 0.5.1
(http://roundcube.net/)
header:
> Content-type: multipart/alternative;
> boundary="Boundary_(ID_5c6pircyQbJYZpbzNs1n6A)"
body:
> --Boundary_(ID_5c6pircyQbJYZpbzNs1n6A)
> Content-type: text/plain; charset=utf-8; format=flowed
> Content-transfer-encoding: quoted-printable
>
> ...
>
> --Boundary_(ID_5c6pircyQbJYZpbzNs1n6A)
> Content-type: multipart/related;
> boundary="Boundary_(ID_7pYDdsXEkQHKIifWF3ucAw)"; type="text/html"
>
>
> --Boundary_(ID_7pYDdsXEkQHKIifWF3ucAw)
> Content-type: text/html; charset=utf-8
> Content-transfer-encoding: quoted-printable
>
> <html>...</html>=
(this html part is correctly displayed)
>
> --Boundary_(ID_7pYDdsXEkQHKIifWF3ucAw)
> Content-id: <7e087dab-5cbb-e6e6-b224-c0a01d29bd78@me.com>
> Content-type: application/pdf; name=einladung.pdf
> Content-transfer-encoding: BASE64
> Content-disposition: inline; filename=einladung.pdf
>
> JVBERi0xLjYNJeLjz9MNCjM0IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDI2MTc2My9PIDM2
> L0UgMjU3MDQwL04gMS9UIDI2MTQ2Mi9IIFsgNDk5IDE4Ml0+Pg1lbmRvYmoNICAgICAgICAg
> ZG9iag1zdGFydHhyZWYNMTE2DSUlRU9GDQ==
(this pdf is not displayed at all)
>
> --Boundary_(ID_7pYDdsXEkQHKIifWF3ucAw)--
>
> --Boundary_(ID_5c6pircyQbJYZpbzNs1n6A)--
i'll attach a test .eml file to illustrate the problem
(.pdf document has been shortend - it will not be
valid pdf anymore)
Reproducible: Always
|
Reporter | |
Comment 1•14 years ago
|
||
|
||
Updated•14 years ago
|
Component: Message Reader UI → MIME
Keywords: testcase
Product: Thunderbird → MailNews Core
QA Contact: message-reader → mime
|
||
Comment 2•14 years ago
|
||
(In reply to comment #0)
> thunderbird does not correctly parse the message and the attached pdf is not
> correctly displayed.
Where can we see *attachment" part in the mail?
(In reply to comment #1)
> (snip) multipart/related mime boundry handling problem
Is your boundary handling correct?
As multipart/alternative;
(A) View/Message Body As/Plain Text :
(A-1) Tb shows text/plain in multipart/alternative,
(A-2) multipart/related part is ignored because of multipart/alternative.
(B) View/Message Body As/HTML :
(B-1) Tb shows multipart/related(contains text/html) in multipart/alternative,
(B-2) text/plain part is ignored because of multipart/alternative.
"Ignoring of whole multipart/related of (A-2)" is by change of Bug 351224, and is RFC compliant behavior, and is never incorrect behavior of a MUA.
Part called "attachment" can not exist in multipart/related. Part in multipart/related is mail body(text/html) and segments of mail used by the mail body only.
AFAIK, when (B), Tb showed application/pdf part in multipart/related at Tb's attachment pane, because the application/pdf part in multipart/related is not used(pointed) by text/html part(mail body) in the multipart/related, in order to provide a way to save "non-used part in multiple/related" to file.
Is this "show non-used part in multiple/related at attachment pane" not executed by Tb?
Bug 490640 is for "not pointed image/jpeg by text/html in multipart/related". In that bug, it looks that no icon was shown at attachment pane. "not pointed part by mail body part in multipart/related" may be simply ignored and it may be current design.
|
|
||
Updated•14 years ago
|
Blocks: multipartfailtracker
|
|
Reporter | |
Comment 3•14 years ago
|
||
wada, i'm sorry but i do not understand what you want from me right now :)
|
|
||
Comment 4•14 years ago
|
||
(In reply to comment #3)
> wada, i'm sorry but i do not understand what you want from me right now :)
I wanted to know;
(i) Which View/"Message Body As" did you use.
(ii) Difference between "Original HTML or Simple HTML" and "Plain Text".
And,
(iii) Whether you agree on that this bug is INVALID, or not.
If not, acceptable reason why "not INVALID" for developers of Tb.
(iv) Even when this bug is INVALID, you think something is needed to provide a way to see or save hidden/ignored application/pdf part in wrongly structured mail, or you think that there is no need of such enhancement for mail of bad structure which is produced by other mailer's bug or by other mailer's unpleasant-for-Tb expectation of "same mail display as Outlook who frequently ignores RFCs for mail including RFC what is implemented by MS himself". :-)
|
||
Comment 5•13 years ago
|
||
(In reply to comment #4)
> (In reply to comment #3)
> > wada, i'm sorry but i do not understand what you want from me right now :)
>
> I wanted to know;
> (i) Which View/"Message Body As" did you use.
> (ii) Difference between "Original HTML or Simple HTML" and "Plain Text".
> And,
> (iii) Whether you agree on that this bug is INVALID, or not.
> If not, acceptable reason why "not INVALID" for developers of Tb.
> (iv) Even when this bug is INVALID, you think something is needed to provide
> a way to see or save hidden/ignored application/pdf part in wrongly
> structured mail, or you think that there is no need of such enhancement for
> mail of bad structure which is produced by other mailer's bug or by other
> mailer's unpleasant-for-Tb expectation of "same mail display as Outlook who
> frequently ignores RFCs for mail including RFC what is implemented by MS
> himself". :-)
Build identifier: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2
I'm not familiar with RFCs that deal with this issue; but, it is something
that is used by Outlook.
But to answer your questions:
1 & 2) Viewing as Original HTML/Simple/Plain does nothing to show the
attachments.
3) I think the validity of this bug depends on whether the MailNews team
wishes to support Outlook's usage of "Content-Type: multipart/related"
MIME header.
I just got hit by this today on SeaMonkey 2.2. Changing the
"related" to "mixed" worked (shows the attachments).
|
|
||
Comment 6•13 years ago
|
||
Enhancement by Bug 602718 may resolve your case.
|
||
Comment 7•13 years ago
|
||
FWIW: In current versions of Thunderbird (8.0 and later) and SeaMonkey (2.5 and later), there is a "View → Message Body As → All Body Parts" menuitem in the 3-pane and Message windows and tabs, but only if mailnews.display.show_all_body_parts_menu is true (not the default) in the Thunderbird Config Editor (see "Advanced" preferences menu) or the SeaMonkey about:config.
With this option selected, all attachments (even "uninteresting" ones such as GPG hashes or attachments already displayed inline) are shown in the Attachments box, but HTML is implicitly displayed as plaintext.
For details, see: bug 564423, bug 602718, bug 677905.
Please retest with a current mailer, and tell us if this bug can be RESOLVED WORKSFORME.
|
|
||
Comment 8•13 years ago
|
||
This bug is for "non-used/non-displayable pdf part under multipart/related". This case is being processed by bug 674473.
Duping to bug 674473.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•