User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Build Identifier: Mozilla/1.5 After updating user.js file to allow Thunderbird to 'trust' to open links to documents on our network, when users receive the email message with the link to the document, they can click on it and open the document; however, there is a second link that appears in the email message, a CID link, that I can't seem to find how to remove it so it never appears in the email message: Here is an example of the link that shows after the correct link to the file on the network: <cid:part1.07070108.00090302@ncmail.net Reproducible: Always Steps to Reproduce: 1.open write window 2.click in body of email 3.click in insert 4.Search for the .doc file (or .xls, etc) on the network 5. Click on OK. 6. Link to file shows up in body of email message 7. user receives email, with two links. One being the correct link to the document on the network, the second being the link to some content ID that doesnt need to show in the email message. Actual Results: See above Expected Results: See above Never shown the 'second' link for the content ID

Here's what's happening: You drop a file into the (HTML) message body. It creates a link. By default, the file is included when the message is sent -- if the message is sent as HTML. In your case, it's being sent as plain text. So, the link is converted to its plain-text representation: the original text, which in this case happens to look like a link, and the link's href, which is the cid: pointer to the document part of the message. However, the document part is dropped when the message is converted to plain text (which is another bug), so the cid: pointer isn't even valid. xref bug 241572. Now that bug 132257 is fixed [TB 2.0], this problem can be worked around: when the link is in the message body, select it, Ctrl+L, and clear the (new) checkbox "Attach the source of this link." When you do this, and the message is converted to plain text, you only get the link text. (If you change the text in the message from the file: link to something more descriptive, but don't change the link's href, then you get New descriptive text <file://blahblah.txt> which can be useful.) > After updating user.js file to allow Thunderbird to 'trust' to open links > to documents on our network This does open the client to potential security breaches.

I don't have time to examine this, but I suspect it's another fallout from unwarranted downgrading of HTML messages to plain text caused by Delivery Format > Auto-Detect.