bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

NEW
Unassigned

Status

MailNews Core
MIME
3 years ago
2 years ago

People

(Reporter: Jeffrey Stedfast, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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.

Comment 1

3 years ago
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)
(Reporter)

Comment 2

3 years ago
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)
(Reporter)

Comment 3

3 years ago
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
Created attachment 8651346 [details]
Mail folder file. Contains 2 mails. Difference is "start parm of multipart/related" only.
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.
(Reporter)

Comment 8

3 years ago
I would argue that the correct thing to do is to compare canonicalized cid values (remove cfws and brackets)
(Reporter)

Comment 9

3 years ago
Has there been any progress on this?
(Reporter)

Comment 10

2 years ago
Any progress on this?
You need to log in before you can comment on or make changes to this bug.