Open Bug 1149663 Opened 9 years ago Updated 2 years ago

multipart/related start parameter handled incorrectly(Tb expects start=cid-url instead of correct start="cid of Content-ID: header")

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

People

(Reporter: fejj, Unassigned)

Details

Attachments

(1 file)

Mail folder file. Contains 2 mails. Difference is "start parm of multipart/related" only.
4.82 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.104 Safari/537.36

Steps to reproduce:

Create a message with a multipart/related with the following header:

Content-Type: multipart/related; start="<content-id@example.com>"

And then add a child with a Content-Id matching the start parameter value.


Actual results:

Thunderbird displays nothing.


Expected results:

Thunderbird should display the MIME part with the specified Content-Id.
Hi, Jeffrey. Could you please create a minimum example message that shows the problem and attach it here? It would help developers to test the issue.

Thank you.
Flags: needinfo?(jeff)
For more context, see: https://github.com/jstedfast/MimeKit/issues/124

This is not hard to reproduce. I don't even have Thunderbird installed anymore, but something as trivial as this should suffice to illustrate the problem:

From: leofigueres@yahoo.com
To: leofigueres@yahoo.com
Subject: Test subject
MIME-Version: 1.0
Content-Type: multipart/related; start="<content-id@example.com>"; boundary="abc"

--abc
Content-Type: text/html; charset=utf-8
Content-Id: <content-id@example.com>
Content-Transfer-Encoding: 8bit

<html>
  <body>
    <p>Hello, world!
  <body>
</html>
--abc--
Flags: needinfo?(jeff)
Just downloaded and installed the Thunderbird 38.2.0 dmg and confirmed this. Thunderbird shows a blank white page for the above test message.

Apple Mail correctly displays "Hello, world!"

MimeKit correctly locates the root of the multipart/related based on the start parameter.

If you edit the message I pasted above and remove the <>'s from the start parameter value, then Thunderbird will display "Hello, world!".


It should be noted, however, that rfc2387 defines the start parameter syntax for multipart/related as:

3.4.  Syntax

     related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        [ ";" "type"  "=" type "/" subtype ]
                        ; order independent

     cid-list        := cid cid-list

     cid             := msg-id     ; c.f. [822]

and rfc822 defines msg-id as:

     msg-id      =  "<" addr-spec ">"            ; Unique message id



In other words, Thunderbird expects the syntax to be:

     related-param   := [ ";" "start" "=" addr-spec ]

instead of

     related-param   := [ ";" "start" "=" msg-id ]
(In reply to Jeffrey Stedfast from comment #3)
> and rfc822 defines msg-id as:
>      msg-id      =  "<" addr-spec ">"            ; Unique message id

rfc822/rfc2822 is already replaced by rfc5322. Refer to recent rfc, please.
  http://tools.ietf.org/html/rfc5322#section-3.6.4
  https://tools.ietf.org/html/rfc2045#page-26

> In other words, Thunderbird expects the syntax to be:
>      related-param   := [ ";" "start" "=" addr-spec ]
> instead of
>      related-param   := [ ";" "start" "=" msg-id ]

Confirmed this Tb's behavior with Tb 31.7.0 on Win.
> (A) Message is not shown by Tb :
>     Content-Type; multipart/related; start="<ABC.DEF>"; type=text/html; ...
>      Part-1 : Content-Type: image/png, Content-ID: <PQR.XYZ>
>      Part-2 : Content-Type: text/html, Content-ID: <ABC.DEF>
>               <img ... src="cid:PQR.XYZ" ...>   <= cid-url is used in html 
> (B) Message is shown by Tb :
>     Content-Type; multipart/related; start="ABC.DEF"; type=text/html; ...
>      Part-1 : Content-Type: image/png, Content-ID: <PQR.XYZ>
>      Part-2 : Content-Type: text/html, Content-ID: <ABC.DEF>
>               <img ... src="cid:PQR.XYZ" ...>   <= cid-url is used in html

As you say, confusion between msg-id/cid and mid-url/cid-url is perhaps a reaason.
  (if mid-url/cid-url, angle brackets is removed from msg-id/cid of Message-Id:/Content-Id: header)
See https://www.ietf.org/rfc/rfc2392.txt for "MID and CID URL Schemes".
> The URLs take the form
>   content-id    = url-addr-spec
>   message-id    = url-addr-spec
>   url-addr-spec = addr-spec  ; URL encoding of RFC 822 addr-spec
>   cid-url       = "cid" ":" content-id
>   mid-url       = "mid" ":" message-id [ "/" content-id ]
Confusing term of "content-id" and "message-id" was better avided in this document...

IIRC, some mailers generated start=cid-url instead of start="cid of Content-ID:", and problematic mail attached to bug for "start parameter of multipart/related is ignored by Tb", had start="cid-url".
Sorry for typo.
Confirmed this Tb's behavior with Tb 38.2.0 on Win.
Status: UNCONFIRMED → NEW
Component: Message Reader UI → MIME
Ever confirmed: true
OS: Mac OS X → All
Product: Thunderbird → MailNews Core
Hardware: x86 → All
Version: 39 → 38
Attachment #8651346 - Attachment description: Mail folder file. Contains 2 mails. Difference is "start parm of multipart/related" only. → Mail folder file. Contains 2 mails. Difference is "start parm of multipart/related" only.
Summary: multipart/related start parameter handled incorrectly → multipart/related start parameter handled incorrectly(Tb expects start=cid-url instead of correct start="cid of Content-ID: header")
When multipart/related start=..., subpart of it is processed at:
 http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimemrel.cpp#424
>   if(
>        (relobj->head_loaded) ||
>        (MimeStartParamExists(obj, child) && !MimeThisIsStartPart(obj, child))
>      )
>   { this subpar is not start part }
>    rlse { this subpart is start part }
MimeThisIsStartPart() is defined at:
 http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimemrel.cpp#338
Obviously, starting/ending angle brackets is removed from string of Content-ID: header(==cid) upon comparing with string in start parm of Content-Type: multipart/relted start="...".

Some mailers set start="<addr-spec>"(recent this bug's case) but some other mailer probaably use start="addr-spec"(old bug's case).
Logic like following is neded?
> If start parameter of "Content-Type: multipart/related" begins with "<" && ends with ">",
>      compare start parameter with cid in Content-ID as-is.
> Else compare after removing enclosing "<" and ">" from string in Content-ID:(==cid)
>    as done curently.
I would argue that the correct thing to do is to compare canonicalized cid values (remove cfws and brackets)
Has there been any progress on this?
Any progress on this?

This is still unfixed in version 91.9.0, stripping angle brackets works.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: