Closed Bug 264270 (mid-urls) Opened 20 years ago Closed 4 years ago

thunderbird should support the mid: URL scheme defined in RFC 2392

Categories

(Thunderbird :: General, enhancement, P2)

enhancement

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
87 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: mail, Assigned: rnons)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Thunderbird version 0.8 (20040922) The mid: and cid: URL schemes, defined by RFC 2392 <ftp://ftp.rfc-editor.org/in-notes/rfc2392.txt>, permit applications to refer to messages or the body parts of messages. For your convenience, I give sample URLs in these schemes at the end. In particular, these two URL schemes enable applications to refer to messages in the user's mail store. Thunderbird does not presently appear to register itself as a handler for either of the mid: and cid: schemes. I speculate that this is because Thunderbird doesn't currently index Message-Ids and Content-Ids, and thus is unable to display a message given it's Message-Id in a performant manner. My request is that Thunderbird include this functionality & support. SAMPLE mid: AND cid: SCHEME URLs: mid:foo4-foo1@bar.net (refers to a message with Message-Id foo4-foo1@bar.net) cid:herringbone2-part5@nicedomain.net (refers to a body part of some message with Content-Id herringbone2-part5@nicedomain.net) mid:960830.1639@XIson.com/partA.960830.1639@XIson.com (refers to a body part with Content-Id partA.960830.1639@XIson.com, with the additional information that this body part is within the message with Message-Id 960830.1639@XIson.com) Reproducible: Always Steps to Reproduce:
To give an example of why this functionality would be very handy, let me describe the situation this morning that led me to filing this RFE: I received an email informing me of a forthcoming meeting. Notice of the meeting is not available on the web, only in the email message. I used Sunbird to mark an event in my calendar for the meeting. I would have liked to have been able to have entered into Sunbird's URI field for the event an mid: scheme url referring to the message (still in my message store) which notified me of the meeting. Having this mid: scheme URL entered into Sunbird would enable me to quickly recall the notification message (by pressing the Visit URI button for the event). (Of course, all this presupposes that Sunbird's Visit URI button works for other URI schemes, which does not appear to be true, at least for the version of Sunbird I'm using - Mozilla/5.0 (rv:1.8a4) Gecko/20040907 Sunbird/0.2a .. the most recently available build that's packaged with a Windows installer.)
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
I just checked Thunderbird 1.5 Beta 1 and this RFE has not been implemented. To check (in Windows): Start menu/Run... mid:abc@def.ghi where abc@def.ghi is the Message-Id of some message in your local message store. While, I admit, making Thunderbird capable of opening messages or body-parts from the command line is unlikely to be a 'killer feature', I think it's it's something the Thunderbird developers might like to consider adding.
Duplicate of #254015 ?
QA Contact: general
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 254015
Duplicate of bug 77195 ?
No.
Another way supporting CIDs is useful is for HTML bodies that refer to attached images. While most HTML messages use images on the web, there are occasional ones that package them in the message (usually from personal contacts). It would be very nice if this were supported.
(In reply to comment #7) > Another way supporting CIDs is useful is for HTML bodies that refer to attached > images. While most HTML messages use images on the web, there are occasional > ones that package them in the message (usually from personal contacts). It > would be very nice if this were supported. the libmime multipart/related code already handles cid: references. gloda enables mid support for message-id's, and could be used for mid purposes with attachment cid's too. Gloda does not index attachment content-id's, although that could be done. Having said that, the specific sunbird/lightning use-case could be met entirely using gloda, so I'm not sure what use-cases that would leave for more general exposure of this.
For mail threads with no web-accessible archive, it would be very handy to be able to refer to them from other threads using in-message mid links. I tried this myself, assuming it’d work, but SeaMonkey mailnews doesn’t navigate to the linked message when I click on a mid link. Given this use-case, it would make sense for the email composer to have a UI to guide the user when creating a mid link. At the very least, the user should be able to “Copy Link Location” and get a mid link through the context menu of a message in the Message Pane. Also, when I open the context menu of an image in an email and choose “View Image” (http://imgur.com/PRfqR9u), a very strange and, I suspect, unstable “imap://hostname/fetch>UID>/INBOX>1234?part=1.2.2” sort of URI appears in the Address bar. Copying that URI to a new tab and trying to visit it results in nothing appearing. It’s possible that, with multiple mailnews accounts, or even in the same account, multiple messages stored in the account might share the same Message-ID. The imap:// URI looks like maybe it should overcome this ambiguity. But if the browser would display to me a mid:Message-ID/Content-ID when I right-click an image and choose “View Image”, and if the browser could actually find and display that content part when typed directly into the address bar, that behavior would be more useful or at least feel more correct. Again, I don’t know how to solve the ambiguous Message-ID problem—unless maybe gloda already munges Message-IDs so that it isn’t a problem?
The Thunderlink addon is probably the closes thing available now: https://addons.mozilla.org/en-US/thunderbird/addon/thunderlink/ It works pretty well, but it's a bit of a pain to install. Not cid: urls though, just Message-IDs.
Blocks: 457177

Changes made in Thunderbird 78 have broken the mechanism Thunderlink uses to display a message when an external link is clicked. Detailed discussion of the problem may be found at github.com/mikehardy/thunderlink#64 "Compatibility with version 78 (next release)." Mike, the original author of Thunderlink, suggested that the easiest way to fix this would be to build the functionality into the core, and implementing this RFE was mentioned.

Thunderlink provides interoperability that I've found invaluable, I believe implementing this RFE would provide useful functionality to Thunderbird.

Let's keep this for the mid: url. (I don't see what cid would ever be used for). We want it for use cases such as bug 1667959, bug 457177. Another one is allowing opening the quoted message (message quotes have mid: urls)

Just a few notes:

Alias: mid-urls
Assignee: nobody → remotenonsense
Priority: -- → P2
Summary: thunderbird should support the mid: & cid: URL schemes defined in RFC 2392 → thunderbird should support the mid: URL scheme defined in RFC 2392
Status: NEW → ASSIGNED
Target Milestone: --- → 87 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/77452c9776eb
Support opening a message by mid url. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Regressions: 1696218
Blocks: 1704424, 1704421

(In reply to Magnus Melin [:mkmelin] from comment #12)

Let's keep this for the mid: url. (I don't see what cid would ever be used for). ...

Consider an email whose content is supposed to represent a rich-text document with embedded images, attachments, etc.

Some clients (Apple Mail, eg) use a MIME structure like this (say, a single PDF attachment):

multipart/alternative
    text/plain
    multipart/mixed
        text/html (1)
        application/pdf
        text/html (2)

This email has no visible attachments when viewing the text alternative.

With this structure, the attachment is visible regardless of text vs html view, but the position of the attachment link within the html part is lost, unless the attachment is included twice:

multipart/mixed
    multipart/alternative
        text/plain
        text/html (1+2)
    application/pdf

However with Content-Id: xxx specified for the PDF attachment, the html part could contain this <a href="cid:xxx">Attached PDF document</a> at the point where the attachment is referenced in the html part. When viewed as text, the message should have the plain text and a visible attachment in the attachment pane; when viewed as HTML, there would be a link in the hypertext that would open the PDF attachment according to the user's settings.

At least if that use of cid: was understood it might be possible to reformat the first structure into the second.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: