Closed Bug 254913 Opened 18 years ago Closed 16 years ago

add "phishing" detection to mail client


(Thunderbird :: Mail Window Front End, enhancement)

Not set


(Not tracked)



(Reporter: sspitzer, Assigned: mscott)


(Blocks 1 open bug, )



(2 files)

add "phishing" detection to thunderbird

Talked to mscott, benb and lorenzo about this on friday.

perhaps we could add some code to help detect potential phishing emails to

for example: if href url is an ip address or if href url domain doesn't match
href text domain, then it might be a phishing email.  (or something, we could
read up on for what makes a phishing email.)

We could then display a bar (like the "junk" or the "remote images" bar) to let
users know "this could be a fake email intended to xyz."

if we think it is a phish email, we could display in simple html, like we do
when we think something is junk.

the order of importance would be junk, phish, then remote images, so that we at
most show one "bar" at a time.
*** Bug 254965 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> *** Bug 254965 has been marked as a duplicate of this bug. ***

Because your bug was for MailNews this one is not TB only, is it?
all: see also the descr of the dup bug.
ostgote: Seth and me were talking about the same thing. This feature should be
available in both Seamonkey and Thunderbird.
Summary: add "phishing" detection to thunderbird → add "phishing" detection to mail client
Here is a snippet that turned up in my inbox today:

<strong>Click here &gt;&gt;</strong> <a
href="" onMouseover="window.status=''; return
true" onMouseout="window.status=' '; return true"></a><br>

This would have been caught by the idea we were discussing of running the URL
parser on the link text and seeing if it matched.

This particular email also uses JS to obscure the link target. But if JS is
enabled you're pretty much toast anyway, I think. In fact maybe we should have a
warning there in the preferences panel?
See also Bug 264850 and Bug 264629
*** Bug 264629 has been marked as a duplicate of this bug. ***
Trying to do "rules based" detection of Phishing and Spam URLs is pretty hard,
we try a lot here, and it's always an arms race. Open redirects (like google and
to some extent Yahoo), HTML escaped characters, embedded images, javascript etc.
makes these things hard to detect (without some significant amount of FPs).

Since Mozilla/Firefox has knowledge of all URLs (after any encoding/JS etc.),
and subsequent redirects, it might be easier for us to do something "clever". It
might be expensive, but one idea could be to use an existing DB of known
phishing IPs and URLs (e.g. something like SURBL, We'd have
to deal with redirects, something like:

0. Get the "requested" URL, normalize/parse it
1. Check the URL domain/IP against some DB (e.g. SURBL, or some other Phishing
specific clearing house)
2. If marked as phishing, warn/stop before loading (allow for manual override)
3. If not, do a HEAD request on the URL, and see if it's a redirect (e.g. HEAD
4. If it's a redirect, normalize/parse the new URL, then go to step 1. and start
5. Continue loading the URL if no phishing detected.

Like I said, quite a few network roundtrips involved here, but it could be
pretty effective. Even if we don't do a network DB lookup, it would still be
useful to traverse the redirection "links", before making the "final" decision
if it looks like a phishing URL or not.
solid phishing protection probably cannot be realized short of equipping the
user with a (personally transferrable) security token - see RFE Bug 268835 for
how mozilla could enable such a protection.
I was about to post a new bug (feature request) along these lines when I
discovered this one.

Here is my suggestion:

- Whenever the text of an html link begins with "http(s)://" check to see if the
linked text is equal to the target url.
- If not, display a warning. It can be an icon next to the link or a "links in
this email have been dissabled top screen as we have for extension installations
in firefox).

I think this should be rather simple.
 - If a link is something like <a href="">Text</a>, no action
is taken.
 - If <a href=""></a> (Linked text begins
with http://) it is checked to see if both are the same. If they are the same,
do nothing. If not, give a warning or disable links till aproved (as for

This would be a great security feature, I belive.
Bug 116242 would be useful for this, it should find anything that looks
reasonably like a URL to humans, even when in the middle of other text.
Didn't there used to be a Keyword for "other competing apps have this feature"?

Eudora 6.2 ScamWatch:

Google GMail:

Some fairly simple patterns to start with:
 * linked text is a valid URL but different from the href
 (thunderbird is already able to detect valid URLs in text,
 since it does so in received plaintext emails)
 * javascript changes/overrides the link to a different URL,
 or calls window.status in any way.

If adding a separate "phishing" flag and UI is prohibitive,
 increasing the junk score for these patterns would work too.
Hardware: PC → All
*** Bug 274171 has been marked as a duplicate of this bug. ***
Blocks: 278490
Some IMAP Anchors seem to trigger the phishing warning when using an internal IP
address ( as IMAP server address.

The anchor link was:
And triggered the anti-phishing dialog reporting that the link was directed to (our internal mail server).

I think this warning should not be triggered when the target address is the same
as the IMAP server.
an other bad email i saw while browsing through my Junk folder: (just the
relevant part)

<html><p><font face="Arial"><A
name="FPMap0"><area coords="0, 0, 623, 349" shape="rect" href="(phishers Adress
border="0" usemap="#FPMap0"></A></a></font></p><p><font color="#FFFFFC">in 1998
AOL BMW Male Will you, please... </font></p></html>

when i moved over the image i saw the adress in the status bar, not
the actual one

PS i dont know if i sould post it here, or in Bug 279191

Re: comment 17.  There is a specific bug for showing the wrong URL with MAP
*** Bug 297001 has been marked as a duplicate of this bug. ***
I'd second the suggestion in #12 -- agressively highlighting the situation where
the URL in the text doesn't match the link would be a significant improvement. 
An option that disabled links with a mismatch (possibly restricting the
comparison to the link's domain) would be excellent... 
*** Bug 302023 has been marked as a duplicate of this bug. ***
Excuse me for the lame question, but how does this bug differ from the
(resolved) #279191?

*** This bug has been marked as a duplicate of 279191 ***
Closed: 16 years ago
No longer depends on: mailphish
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.