Open Bug 398875 Opened 17 years ago Updated 2 years ago

Missing filtering action "Mark as not a scam"

Categories

(MailNews Core :: Filters, enhancement)

Product:
MailNews Core
Component:
Filters
Type:
enhancement

Tracking

(Not tracked)

Status:
REOPENED

People

(Reporter: tonymec, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.18.8-0.5-default; X11; i686; en_US) KHTML/3.5.5 (like Gecko)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071006 Thunderbird/2.0.0.7pre

Note: This is about "scam" (aka phishing), not "spam" (aka junk).

Currently, the only way to mark a message as "not a scam" is to open it, then click the button "This is not a scam" near top right.

I would like to be able to tell Thunderbird that email emanating from bugzilla-daemon@mozilla.org is not scam (or, alternately, that links to https://127.0.0.1/ are not phishing: the latter may be more "the right thing to do" but I guess the former is "simpler").

Rationale: I have recently received several bugmail messages which Thunderbird detected as "scams". They all had the above HTTPS link in the quoted "new comment".

Reproducible: Always

Steps to Reproduce:
1. Make sure you are subscribed to Bugzilla and that your account is set to receive bugmail even on your own comments.
2. Make a comment containing the string https://127.0.0.1/
3. Check your mail periodically with Thunderbird until bugzilla-daemon@mozilla.org sends you mail about the comment you submitted at step 2.

Actual Results:  
Thunderbird thinks that the mail at step 3 is a "scam". No filter can tell it otherwise.


Expected Results:  
Should be able to set "This is not a scam" as a filtering action.


Additional info: I'm already filtering bugmail with "Move to" and "Set Junk status as Not Junk" as the actions.
Bug 320739 fixed the https://127.0.0.1/ case. (Works fine on trunk.)

And with that fixed, I don't think a filter action is a good idea. It's exactly when you think you know it's not a scam you are most at risk at falling for it.
possibly combine with https://bugzilla.mozilla.org/show_bug.cgi?id=360742 ?

Regarding comment#1, I would respectfully disagree: I know I can trust certain senders (or their host/domains).
You probably can, but you don't have any way to know the messages come from the person/domain they say they come from.
Thunderbird should remember the sender when we tell it it is not a scam.  I repeatedly get emails from the same senders that are not scams but are ALWAYS marked as scam every time they arrive even though I tell it it is not a scam!
Why won't Thunderbird "learn".
As the reporter, I now agree with comment #1. Magnus, if you (or someone) marks this bug WONTFIX, I won't object. (You're a Thunderbird peer aren't you? Or should I CC dmose and/or Bienvenu?)

In reply to comment #5: a common tactic of spammers (and presumably of phishers) is to use fake, respectable-looking "From" lines in their emails. Anyone can fake a from-address, you can, I can, anyone can, it's as simple as creating a new identity in Thunderbird.
(In reply to comment #5)
> Thunderbird should remember the sender when we tell it it is not a scam.  I
> repeatedly get emails from the same senders that are not scams but are ALWAYS
> marked as scam every time they arrive even though I tell it it is not a scam!
> Why won't Thunderbird "learn".

Thunderbird's scam detection is not adaptive--which is probably a good thing. It simply checks to see if the link is misleading (claiming to send you to a different site than it really is) or a known phishing link.
There may be be a few reasonable use-cases for not-a-scam, when you know that the sender will never be forged for a phish because it would be pointless (nobody's ever going to send a phish purporting to be from your fantasy curling league's private mailing list, because frankly we all think you're just weird), but those are so very few (while you might initially think "nothing from my mom is ever a phish" combining a crack that steals contacts from a webmail program with some kind of "I need you to fill out this form for me" phish would be pretty effective) and explaining that "This is an option that you should almost certainly never use, no, definitely not for the case you're about to use it for" would be so difficult, that we just can't.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Philor: should I (the reporter) do anything more with this bug (such as VERIFY it, in the light of comment #6 above)? I'm not yet sure of all the fine points.
Comment #1 amounts to treating all Mozilla users as children who don't know
what's good for themselves.  The whole philosophy of Mozilla is, or should be,
never to do that.

Re. comment #6: Yes, faked "From" lines are very common, but there are plenty
of ways for filters to catch them.  Typically a faked From address will have a
garbage user name (z73k09p@aol.com), so "whitelist" filtering on specific
sender addresses will sort them out just fine.  Other times the subject line
will be garbage or won't make sense for the sender (for example, mail from
bugzilla-daemon@mozilla.org with subject "Order status").  It's easy to catch
these cases, and anyway it must rightfully be left up to the individual user.

Re. comment #7: Several of the political lists I have subscribed to for years
are always marked as scams by TB.  If the filter works as you say, then its
(and your) idea of a "known phishing link" is bogus.

Re. comment #8: Your remarks are too incoherent for me to make sense of.  But
clearly the behavior asked for -- making "Mark as not a scam" a filter action
-- does not require any difficult-to-implement intelligence on the part of TB. 
So I object to the WONTFIX.
(In reply to comment #10)
> Comment #1 amounts to treating all Mozilla users as children who don't know
> what's good for themselves.  The whole philosophy of Mozilla is, or should be,
> never to do that.

If you can successfully spot every single spam message, virus-laden email, or phishing email on your first try with neither false positives nor false negatives, I commend you. At least 95% of the public can't do it: even many so-called power users would have trouble with that.

> Re. comment #6: Yes, faked "From" lines are very common, but there are plenty
> of ways for filters to catch them.  Typically a faked From address will have a
> garbage user name (z73k09p@aol.com), so "whitelist" filtering on specific
> sender addresses will sort them out just fine.

"Typically" being the operative word here. It's not the easy-to-spot scams that are dangerous, it's the hard-to-spot ones.

> Re. comment #7: Several of the political lists I have subscribed to for years
> are always marked as scams by TB.  If the filter works as you say, then its
> (and your) idea of a "known phishing link" is bogus.

That's only one of the criteria (it's an OR criteria). The other one is a domain mismatch: i.e., if the link claims to be from amazon.com but in reality goes to uberh4x0rz.ru, it will be marked as a scam.

> Re. comment #8: Your remarks are too incoherent for me to make sense of.  But
> clearly the behavior asked for -- making "Mark as not a scam" a filter action
> -- does not require any difficult-to-implement intelligence on the part of TB. 
> So I object to the WONTFIX.

His main crux is that to implement the feature would leave a gaping security hole. Imagine if someone pretended to be your mother and asked you for confidential information. Your mom wouldn't send you a scam, but the sender is to all apparent purposes your mom. In other words, people would be using the feature for the wrong reasons.

The WONTFIX is because it's better to err on the side of paranoia than it is to give users a tool whose first usage would likely to be to shoot their own feet off.
Changing status to WONTFIX is a fatal mistake. It is useless if it can't be trained. Every time I decide to try it I end up disabling it again. Most of the emails I get that it identifies as a scam are legitimate. Having it on is way more of an annoyance than any protection it offers. With it on one starts automatically clicking on the not scam button since it is so rarely a scan.
(In reply to comment #12)
> [...] With it on one starts
> automatically clicking on the not scam button since it is so rarely a scan.

When I get that message (and I do, though not very often by now), I certainly don't "automatically" click the button. Quite the contrary: I inspect the mail with extra care (even with "View source" if otherwise in doubt) until I decide to treat is either as legitimate (and click "Not a scam") or as phony (and report it as spam using my SpamCop account). Automatically clicking that kind of button is never a good thing to do AFAIK, even though in a different (but parallel and also security-related) case IE/OE users have been known to be "trained" to always accept mismatched and expired certificates.
(In reply to comment #13)
> (In reply to comment #12)
> > [...] With it on one starts
> > automatically clicking on the not scam button since it is so rarely a scan.
> 
> When I get that message (and I do, though not very often by now), I certainly
> don't "automatically" click the button. 

Neither do I. BUT: Have you heard the story about the boy who was always crying wolf? That is the point I was making. Since it is not trainable, a large number of false positives leads to complacency. I turned it off because in its current state it is useless and a waste of time for me.
All we would really need to make this feature useful again is a "whitelist" of sites to which a message is allowed to link (for example, many of the political e-mails I get which the feature marks as scams link to the survey site capwiz.com).
Suggest this is a dup of bug 320351.
Resolution: WONTFIX → DUPLICATE
I always hate to reverse status, but it would be quite legitimate (and fairly trivial) to create a message filter action that would mark a message as not a scam.  The scam code looks like this:


3321   // Run the phishing detector on the message if it hasn't been marked as not
3322   // a scam already.
3323   var msgHdr = gMessageDisplay.displayedMessage;
3324   if (msgHdr && !msgHdr.getUint32Property("notAPhishMessage"))
3325     gPhishingDetector.analyzeMsgForPhishingURLs(aUrl);

So all the filter would need to do is to set that property, and the phishing would be bypassed. This is well within the capabilities of, say, a JS filter action on FiltaQuilla, even today. That could be useful if someone wanted to keep scam detection on, but had a common email they received that was always detected as scam.

I'm not saying that we would actually do that filter action, I've been fairly cautious about adding new filter actions that could be done with an addon, but we should discuss it from that perspective, not from the perspective of the learning issues in bug 320351. It might be better in the addon than core.
Status: RESOLVED → REOPENED
Component: Mail Window Front End → Filters
Ever confirmed: true
Product: Thunderbird → MailNews Core
Resolution: DUPLICATE → ---
(In reply to Kent James (:rkent) from comment #18)
> I always hate to reverse status, but it would be quite legitimate (and
> fairly trivial) to create a message filter action that would mark a message
> as not a scam.  The scam code looks like this: [...]

Fairly trivial, maybe, but how wise?

(In reply to Magnus Melin from comment #1)
> Bug 320739 fixed the https://127.0.0.1/ case. (Works fine on trunk.)
> 
> And with that fixed, I don't think a filter action is a good idea. It's
> exactly when you think you know it's not a scam you are most at risk at
> falling for it.

(In reply to Phil Ringnalda (:philor) from comment #8)
> There may be be a few reasonable use-cases for not-a-scam, when you know
> that the sender will never be forged for a phish because it would be
> pointless (nobody's ever going to send a phish purporting to be from your
> fantasy curling league's private mailing list, because frankly we all think
> you're just weird), but those are so very few (while you might initially
> think "nothing from my mom is ever a phish" combining a crack that steals
> contacts from a webmail program with some kind of "I need you to fill out
> this form for me" phish would be pretty effective) and explaining that "This
> is an option that you should almost certainly never use, no, definitely not
> for the case you're about to use it for" would be so difficult, that we just
> can't.
[sets RESOLVED WONTFIX]

When I declared this bug a dupe in comment #17, I, the reporter, certainly didn't want to reverse Philor's decision to RESOLVE it.
"When I declared this bug a dupe in comment #17, I, the reporter, certainly didn't want to reverse Philor's decision to RESOLVE it."

I understand that. I'm not saying that we should implement the filter action, I'm saying that this bug is not the same as learning what is a scam. Plus at this point the decision of status rests mostly with jcranmer and me.

The use case for this is not to perfect a mostly working scam filter, it is for people who would like to enable the scam filter but cannot, because some recognizable class of messages that they receive routinely are marked as scam. So while I would agree with part of comment 1 "It's exactly when you think you know it's not a scam you are most at risk at falling for it," that issue is moot in the common use case for this filter, because the only current option to a poorly working scam filter is to disable it completely. Then you are REALLY at risk of "when you least expect it."

That being said, I am still leaning toward WONTFIX again because I don't think the filter is important enough to warrant the UI space on the filter actions list, plus it has some degree of risk which inclines me to believe it should be in an extension.
I'd be just fine with it as an extension, if the Powers That Be don't prohibit the extension by refusing the digital signature it would take to install.
I have not tested this, but you could probably implement a "not a scam" message in current FiltaQuilla using the following code for a JS FilterAction:

for (let index = 0; index < msgHdrs.length; index++)
{
  let hdr = msgHdrs.queryElementAt(index, Ci.nsIMsgDBHdr);
  hdr.setUint32Property("notAPhishMessage", 1);
}
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.