User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 This is a very serious problem as the average user who receives a spoof/phish email and notices the status bar message will in all likelihood assume that the message is valid and click through. If an email contains the following valid HTML: <a href="https://www.looks-like-a-valid-site-url.com/login/"> <map name="pphu"> <area coords="0, 0, 646, 569" shape="rect" href="http://211.62.125.100/.../e3b/"> </map> <img SRC="cid:part1....."> </a> The status bar displays https://www.looks-like-a-valid-site-url.com/login/ whenever the mouse is positioned over the <AREA> tag's clickable area. In this case the user is deceived twice, once because of the incorrect URL in the status bar, and once because they notice the HTTPS:// and probably assume that they are okay because they have been given to believe that HTTPS corresponds to a secure website connection. This problem is easily dealt with, from an end-user standpoint, by paying closer attention to email they receive and by taking the time to educate themselves of the various ways phishing, spoofing, and spamming occur. Realistically this just is not going to happen. Reproducible: Always Steps to Reproduce: Please see the details section for a description of how to reproduce the behavior. Actual Results: The statusbar displays a URL that is not the actual destination the user's default web browser will navigate to if the user clicks within the <AREA> tags coordinates. Expected Results: The URL of the actual destination should be shown in the status bar, not for the bounding <A> tag. This represents an opportunity to add a strong layer of protection with very little impact on the ability of Thunderbird to accurately render HTML content! If nothing else is fixed and/or modified other then the status bar text then at least the end-user will have something that may give pause to them before clicking through. However, why not go one step further. It would be a very simple matter for Thunderbird to parse the HTML prior to rendering in order to determine if just this sort of questionable code exists in the message. If so the program can flag the message as spam so that the end user has a CLEAR indication of a possible problem with the message, allowing them the opportunity to investigate. I understand the use of <AREA> tags within <A> tags is valid HTML. However, of the many HTML emails that I receive daily I have yet to encounter a valid message that uses <AREA> tags within <A> tags. The worst thing that will occur if my suggestion is implemented is that the end-user will, hopefully after verifying the validity of the suspect message, will need to add the message's sender to their collected addresses list. Given the growing number of people affected by more and more sophisticated and authentic looking spoofing/phishing attacks, it would seem to me that the benefits will far outweigh the minor inconvenience the end-user may experience.

Thunderbird version 1.0.6 (20050716) Occurs on systems running Windows XP SP1, SP1a, & SP2

*** Bug 316899 has been marked as a duplicate of this bug. ***

From the dupe: this happens on 1.5 also, and may require the mail being classed as spam or a scam to get this rendering.

This is a special case of bug 266932.

Moving off bugs that didn't make the deadline for Thunderbird 2.

Keeping this bug hidden obviously isn't helping get it fixed

If I'm doing it right, this is now pretty well mitigated, probably by bug 234455 - even sending myself this email, so it's marked as scammy, I get the inner URL in the statusbar on mouseover, and that's the URL that's opened on click or copied, so the only remaining issue is that the outer URL is shown onclick. I'm having trouble picturing a successful scam that can be worked by showing a URL that won't be loaded, only while the mouse is down in a (left or right) click.