From bug 370141: A real problem are marketing mails which try to track links using external sites, e.g. http://registerclicks.trackercompany.com/track?companyid=7856785675&recipientid=435447476?url=http://www.playdoo.com/ This is really bad behaviour, I'm not sure whether we should care much. Even worse it is if the link *text* then says "http://www.playdoo.com", but luckily that's done with only maybe 10% of these links, and I wouldn't mind yelling for that. The marketeers should really stop that - they know people don't like it anyways. See also bug 370141 comment 6.

Facebook (bug 691901) is one instance of this. rsx11m 2012-10-10 03:24:11 CEST Ideally there should be three supporting mechanisms, one being a fixed list that could be bundled to the TB installation (which would need to be maintained by Mozilla), another a global phishing list similar to what Firefox does (which may require a separate agreement with Google, that issue is tracked in bug 368924 and bug 347218), and then a learning list trained by the user (bug 320351). Switching off the scam filter by default for the time being is bug 623198. Neither of those shows any significant recent activity, thus I don't know what the current status of this feature is.

squib wrote: > If we could parse the tracking URL to see where it redirects and then check that against the link text If you mean: "intended target appears anywhere in the URL", then that's not a safe check, because it would be trivial for a phisher to make that happen. If anything, we need to query the URL and check the actual redirect target. But at that moment, we have already triggered the tracking and might just as well not warn at all. The only solution I can see is a hardcoded list of known tracking domains.

I meant "we should have a list of the formats for various popular tracking URLs and figure out what they'll actually redirect to based on our understanding of the URL". This does require us to know the format of every tracking URL we care about, which could be a lot of work, but if we just handled some of the more popular ones, we'd still be making things quite a bit safer for users. Essentially, we want a function whose purpose is to take a tracking URL and tell us where we think it will go. Then we can compare the result of that function with the URL's text.

(In reply to Jim Porter (:squib) from comment #3) > Essentially, we want a function whose purpose is to take a tracking URL and > tell us where we think it will go. Then we can compare the result of that > function with the URL's text. Another bonus to having such a function is that we could allow the user to go directly to the redirect target and skip the tracking step.

For tracking vs. phishing, all we care about is that the domain of the tracker is whitelisted. If the intended URL then appears anywhere in the target URL, it should be OK. BUT you have a great idea! Avoiding trackers entirely would be great. To parse, I think we have only 3 cases: trackers that * put the target URL in the query, so we need the query parameter name * have the target URL directly as part of the path * don't have the target URL at all (we can't do anything for them) In both cases, we also need the encoding (raw, QP, etc.). I think that's non-trivial, though. It also gives trackers a choice between being treated as phishers and embarrassed or not being able to do their purposes, and I don't know which one they'll choose, if they care about us at all.

(In reply to Ben Bucksch (:BenB) from comment #5) > For tracking vs. phishing, all we care about is that the domain of the > tracker is whitelisted. If the intended URL then appears anywhere in the > target URL, it should be OK. I don't think that's sufficient, actually. Suppose we have a tracking URL formatted like so: http://whitelisted-tracker.com/redirector?url=http://funnycats.com If I were a scammer, I'd take advantage of this and then compose a URL like this: http://whitelisted-tracker.com/redirector?url=http://evil.com&foobar=http://funnycats.com And then presto, I've defeated Thunderbird's phishing detector. (Of course, eventually whitelisted-tracker.com will probably get wise to this and stop it on their end, but by then it'll be too late for a bunch of users.)

Trackers don't redirect arbitrary URLs, for this very reason to not be abused by phishers. If one does have this vulnerability, it won't be added to our whitelist.

That's good to know (it sure beats the days of using Yahoo's redirector to send Slashdot users to Goatse!), but I think it would be better to be safe than sorry here, unless we're concerned that the format of tracking URLs will often change but that the domains they use won't change.

I suppose it would also be possible to use, say, Facebook's redirector to post a malicious link by posting the link within Facebook, grabbing the redirection URL and then appending the fake URL you want to masquerade as. If the malicious link is something new, Facebook wouldn't know about it yet, and the scammer would be free to use the redirector for however long it takes Facebook to realize something is up. For instance, suppose this is the URL Facebook gives you (taken from bug 691901): http://www.facebook.com/l/nAQHSLG9c/www.youtube.com/watch?v=P6wkjWxEbKY I can mess with that URL and Facebook is still perfectly happy: http://www.facebook.com/l/nAQHSLG9c/www.youtube.com/watch?v=P6wkjWxEbKY&foobar=http://www.funnycats.com A scammer could use that to trick us into thinking a link is legit. We could argue that Facebook is being insecure here, but it we can't even make this feature work with Facebook, I'm not sure there's a ton of value. Hence, I think we should go all the way and extract the redirect target to be safe (and maybe let users bypass the tracker).

I can follow your thoughts. I just think that it's a lot more difficult, and not really worth the effort. Most redirectors should have a abuse reaction mechanism, large ones like Facebook automatic checks. OTOH, if you can remove the tracking for some large URLs, that would be a benefit. But remember that many redirectors don't have the target URL in the redirect URL at all. See all the shortcut URL services, and others that just have a very long ID. I think the real problem will be that there will be too many "legit" trackers out there that we can't list enough of them to make a big difference, even with the simple implementation.

The next step is probably to figure out what services we could detect and validate just by examining the URL. If we can come up with a decent list, it'd probably be worth doing. We could probably discuss that on tb-planning. I'll send out a brief message summarizing things to see what others think.

FWIW, i don't recall seeing facebook mails being detected as scam lately. It used to be the case at some point though. Maybe they changed their ways, or I just haven't got a suitable type of mail anytime recently.