User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051130 Firefox/1.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051130 Firefox/1.5 It is common for email newsletters sent in HTML format to fake URLs in order to track users. For example, <a href="http://click.email-publisher.com/maadlPlabfCjXa9kuYYeafpJ6A/">http://www.example.com</a> When the user opens such a link, Thunderbird should open the URL the user sees rather than the link in the href attribute. If the user thinks they're clicking on http://www.example.com, then that's what should be opened. Reproducible: Always This might also close one avenue for phishing attacks. This is not a full solution to the problem. It does not address the common case of <a href="http://click.email-publisher.com/maadlPlabfCjXa9kuYYeafpJ6A/">something that's not a URL</a>. However it is a minor improvement, and it arguably improves the case where the link is actively deceptive.
Related to Suite bug 143179?
It is related to bug 143179 but defintiely not the same thing. That proposes following the redirects through to the ultimate end. In this case we can see the ultimate end without following the redirects so we might as well jump straight there.
When I click on Thunderbird Help, I am redirected to a haircare site. Also, all of my e-mail folders suddenly disappeared one day when I logged onto my e-mail. What is the story?
(In reply to comment #3) Alfred, your issues aren't related to this bug. Asking support questions in a random bug in bugzilla probably won't help you find the resolution to your issues. You can visit the support forums and knowledgebase on mozillazine <http://forums.mozillazine.org/>, <http://kb.mozillazine.org/Knowledge_Base> where someone might be able to help you diagnose the cause. Then, if it is an issue with Thunderbird, file a separate bug on your particular issue so it can be discussed and analyzed separately.
This won't happen as requested in comment 0 (wontfix), we can't just use the URL text as a link target because we'd be reproducing the problem we're trying to cure (unexpected discrepancy between URL text and actual href URL), which is also a security risk. We need to find better ways of informing/warning users about difference between URL text (link caption) and actual href URL. I think we have some better RFE's in this corner -> dupme
Per comment 5, this is wontfix. However, it comes with good intentions of protecting users against mismatch between linktext URL and actual URL in href attribute, which is same intention as bug 651334.