There should be a way to indicate that a specific folder does not need to be filtered for spam - I have some folders that I know my filters have done the right thing and that there will never be any spam in them. The filtering itself isn't so bad, but the problem is that when I am on a slow (dialup) connection and I open said folders, it takes forever to download each message to do spam detecting. I'd like to just download the messages on demand. The UI and implementation seems relatively straight forward - just copy the work that is done for the "offline download" property on mail folders, or any of the other per-folder properties. You could put another checkbox in the Properties dialog.

I do not quite understand what you mean. Spam filters only filter new messages, not old ones which you have already archived in folders.

I should clarify then - I have mail filters which filter messages into folders. When I open those folders, they have new messages in them, which subsequently get checked for spam.

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

Please add to the summary the "[junk] " string, it makes searching easier. Also, my comments on this feature request are: It would be nice to be able to mark an IMAP to be skipped by the Junk Mail engine. I use an IMAP server with server site email filtering. I have an IMAP folder with a traffic of 500+ emails per day and when I read the emails in that folder, I not always download all the bodies of the emails. But, the Junk Mail engine must download all bodies to look for SPAM and this cause: - more bandwidth being utilized - more local storage being used by the email bodies Maybe the option can be included in the dialog that appears by doing: 1. right-click on a folder 2. select properties There is already an option called: "Check this folder for new Messages" So, the new option could be named: "Don't check this folder for SPAM(Junk Mail)" Thanks

It would be nice if this bug can be solved in 1.4 (blocking 1.4b?), because the whole idea of having a JunkMail Filter is to not be bothered by Junk emails. Right now, Mozilla alert you every time a SPAM email arrive. :-( Thanks

Do you know that Queen song "I'm going slightly mad... It finally happened!". Well, that's how I feel about Mozilla's spam mail filter sometimes. (I even had problems with my employer because Mozilla classified genuine messages from customers as junk mail, and I never got to read them.) Although a VERY useful tool, I think Mozilla's junk mail filter finds too many false positives, and I'd like to be able to at least control (as in inhibit) false positives by specifying filters which, when applicable, should inhibit *any* kind of spam filtering. I might be digressing here, so here's my practical idea: filters should have a checkbox saying "Inhibit Junk Control". The filters should be applied prior to junk mail controls (which I think already happens), and if a filter with that checkbox checked applied to an e-mail, no further junk mail tests should be performed. Obviously, just my 2c, I don't expect you guys to consider each and every bug comment posted here--I think this one would make quite a lot of people happy, though.

"me too" comments are nice but really not that helpful - everyone agrees this bug should be fixed. We just need someone to actually spend the time and fix it... and that person could be you! Just pull the source and start hacking :)

Yeah, sure, let's start a flame here, great idea! Since you're the person who originally reported this bug, why don't YOU do that? Probably for the same reason I don't, you're illiterate in C programming.

Bogdan Stancescu, LOL, does your last msg refer to Alec Flett? Do you realize that he is one of the main *authors* of Mailnews and already spent far more time on it than reasonable? Is this a dup of bug 180855 (or vise-versa)?

ROFL, no, I obviously did not, nobody could be that retarded (as to know that and post the comment I posted). I was just annoyed because I was trying to suggest an alternate method for solving the same issue (setting an 'inhibit junk' property for filters instead of folders), and got that 'me too' message. Sorry Alec, great work! (Anyway, I hope you got a good laugh out of it)

Comment #9 Yes, this bug is a dupe of bug #180855 Please someone mark this bug as dup. Thanks.

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

Updating summary to include "junk".

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

From dup bug: > ninosckha hit this on her bugzilla bug email folder > blizzard hit this on his archived inbox folders. me too. I am scared to open new old folders (old IMAP folders never opened with this profile) with Mozilla, because the junk filters are too slow and (more importantly) too incorrect to have them run on known-good email. I'd like the ability to disable junk filters for *all* folders apart from selected ones (currently only INBOX in my case, but a few others may be added). Excluding folders one-by-one won't help me, because I have too many of them (a few hundred). I'd actually say that this should be the default. If mail is not really new (never seen by any client), it's most likely archived mail and has already been cleaned from spam or never had it (manual sorting).

I'm the one filing this bug so I obviously really want this to happen, but you shouldn't be afraid - mozilla only applies junk mail filters to new, unread messages.. existing messages shouldn't be marked as junk (and if they are, its a seperate bug)

>> mozilla only applies junk mail filters to new, unread >> messages.. existing messages shouldn't be marked as junk I keep seeing this posted so let me explain for all of us who share this problem. Many of us are using Server Side message filtering Because Mozillas filtering--though great--should not be the only method used to reduce SPAM. Since the server is filtering NEW INCOMING messages into a folder (in my case it is called SPAM) I do NOT need mozilla to DOWNLOAD, SCAN, MARK/NOT MARK all of these messages. There are hundreds per day. I feel sorry for those on dialup with this problem. Some of them are watching this bug and posting as well. The ability to tell Mozilla to ignore specific folders for junk filtering would solve this problem. A workaround for me was to set the SPAM folder to be the same as the junk folder . This way mozilla ignores messages in that folder--it seems. But there are other situations where someone may not want mozilla to scan everything. For example, recently we upgraded our mail server. During the upgrade all IMAP email was remarked as unread--an unfortunate side effect of the upgrade. I have 3000+ messages stored throughout a couple hundred folders. Each time I clik a folder I haven't been to since the upgrade, mozilla DOWNLOADS, SCANS, MARKS the emails. I DONT NEED mozilla scanning my archived email. I hope this sheds some light on the situation. NOt everyone who wants this bug has these same problems but some seem to from the postings. Thank you

> mozilla only applies junk mail filters to new, unread messages.. existing > messages shouldn't be marked as junk (and if they are, its a seperate bug) But they are, from what I see. Filed bug 234249. (FWIW, Mozilla *just* marked 1-2 posts to mozdev's project_owners ML, manually filtered into a special folder, as spam.)

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

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

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

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

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

From bug 309014 (as recommended by bug 309014 comment 5): Since other users might have filters to move e-mails to other IMAP folders, and want those e-mails to be checked for junk, this new feature should be a configurable (but unobtrusive) option. The UI could be similar to the "Subscribe" UI for IMAP and newsgroup accounts. The following suggestion would add only one button ("Folders") to the current UI: +--- Junk Mail Controls ---------------------------------------+ | | | Thunderbird has several ways to ... | | | | Configure Junk Settings for: [ <Account-Name> ] [Folders...] | | | ~ ~ +--------------------------------------------------------------+ Klicking on "Folders" yields: +-- Custom Folder Settings ------------------------------------+ | | | Custom Folder Settings for: [ <Account-Name> ] [Folders...] | | | | Select the folders that Thunderbird should check | | incoming messages for Junk mail: | |+------------------------------------------------------------+| || Inbox [x] || || Drafts [ ] || || Sent [ ] || || Templates [ ] || || Trash [ ] || || Personal [x] || || Computers [x] || || Ham Box [ ] || |+------------------------------------------------------------+| | Select: [All] [None] [Subscribed] | | | | [[ OK ]] [ Cancel ] | +--------------------------------------------------------------+ The account initially shown after "Custom Folder Settings for:" should the the one that was displayed in the previous dialog. This enables the user to customize the folders for all accounts in one go, without requiring them to go back and forth between the two dialogs, and without having to thouch this setting ("Custom Folder Settings for:") if they only want change the settings for the account displayed in the previous dialog. For IMAP accounts, clicking on "Subscribed" selects (only) the folders that are currently selected under "File / Subscribe". The tooltip for this button should say "Selects the folders that you have subscribed to." For POP accounts, the "Subscribed" button would not be visible. (Wow, this bug is old)

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

Seeing as bug #329569 is fixed, I find the fact this is not possible very, very annoying. I'd say this is a critical enhancement as the problem of my mailing list messages being junked is becoming very, very annoying.

I'd like to point out that the backend hook to allow this now exists in trunk builds, which means that it is very easy to do in an extension. I will try to add this to one of my extensions (probably JunQuilla) for the beta3 TB3 release.

An alternative way to solve this bug would be to have special headers that can prevent moving a message to the Junk folder. That would be in addition to checking if the sender is in a given address book. The Delivered-To header often has a value that is typical of the folder it gets delivered to. List-Id may also be used for this purpose. Authentication-Results (rfc5451) should only be trusted when they have been written by a trusted domain, like junk mail headers set by SpamAssassin, so as to avoid giving spammers an easy option to get whitelisted.

(In reply to comment #29) > An alternative way to solve this bug would be to have special headers that can > prevent moving a message to the Junk folder. That would be in addition to > checking if the sender is in a given address book. > > The Delivered-To header often has a value that is typical of the folder it gets > delivered to. List-Id may also be used for this purpose. Authentication-Results > (rfc5451) should only be trusted when they have been written by a trusted > domain, like junk mail headers set by SpamAssassin, so as to avoid giving > spammers an easy option to get whitelisted. This doesn't work for the use case I have in mind. I am interested in keeping the junk mail filters from running on IMAP folders to which I have manually saved a message. So, I read an email, decide what to do about it, and then I file it to a separate IMAP folder based on its subject matter. I do not want those IMAP folders to be junk mail filtered --- the junk mail filtering has been done when the mail messages are delivered to my inbox. Anything filed to these topic folders is known not to be junk mail. I used Thunderbird's view all headers command to check an arbitrary message I had filed to an IMAP folder. There was no Delivered-To nor List-Id header.

Robert, this use case shouldn't be a problem at all. When the msg is delivered in your Inbox, Thunderbird runs the Junk filter on it and decides spam/ham. Once it has decided ham, that is stored with the message. The Junk filter will not run on it again when you move that message in a difference folder (on that same IMAP account). If you see something else, please file a new bug (it would be a separate bug from this). Similarly, if you see this when moving messages from the Inbox of one account to the folders of another account, please file a new bug. In both cases, cite the bug number here for reference. Thanks.

(In reply to comment #29) > An alternative way to solve this bug would be to have special headers that can > prevent moving a message to the Junk folder. To recapitulate, we have - messages delivered to folders by external applications and appearing as new, - old mail that has never been scanned by any application, but is known ham, - IMAP mail that has never been seen by TB because of a migration from another mail client to TB, - switching on TB's junk filters for the first time on an existing account, and probably several other situations in which it is undesirable to spam-scan any mail other that in the inbox. Personally, I fail to see how TB could make smart decisions of its own on whether to scan or not without running the risk of making the wrong decision. Therefore, any solution that relies on headers or any other markers added by TB to the mail is bound to make some of us happy, but many others not. What is needed here is a broad solution that covers all possible situations. AFAICS, the ability to manually configure which folders get scanned is the only way to solve this is a way that works for everyone.

(In reply to comment #31) > Robert, this use case shouldn't be a problem at all. When the msg is delivered > in your Inbox, Thunderbird runs the Junk filter on it and decides spam/ham. > Once it has decided ham, that is stored with the message. The Junk filter will > not run on it again when you move that message in a difference folder (on that > same IMAP account). If you see something else, please file a new bug (it would > be a separate bug from this). Similarly, if you see this when moving messages > from the Inbox of one account to the folders of another account, please file a > new bug. In both cases, cite the bug number here for reference. Thanks. I believe that this arises for me for a reason that was revealed by Zenon's comment. I moved to using Thunderbird after using the mail reader VM (in emacs) for many years. So I have folders that have many emails that were never scanned by Thunderbird's junk mail filters --- the messages there were filed by VM (and then translated from local storage to IMAP). That would account for my problem without a separate bug --- those messages were never scanned, but are known to be ham nevertheless. My use case may be odd enough that I should just try to figure out how to inject headers into these messages in order to make them look like they were once scanned....

(In reply to comment #32) > To recapitulate, we have > [...] > - IMAP mail that has never been seen by TB because of a migration from another > mail client to TB, I'd note that migration is not strictly required. One can use multiple clients concurrently, including multiple copies of TB running on different boxes. > [...] any solution that relies on headers or any other markers added by TB The "added by TB" detail makes it unusable. I made a few attempts at adding some X-Mozilla-Status* fields in the header to prevent scanning, and it does not work. If it worked, all spammers would do it. Authentication-Results should be guarded against forgery by compliant servers, as discussed in http://tools.ietf.org/html/rfc5451#section-7.1 . TB should probably use a yet undefined method. The attractiveness of this way is that it provides a means to whitelist a message independently of its destination folder, so that it would also work in INBOX or in POP3. > the ability to manually configure which folders get scanned is the only way to > solve this in a way that works for everyone. It is *one* way. It should store some folder flag on the server, otherwise accessing it from another client --even the same version of TB-- may unexpectedly discard some messages. Both methods would work, possibly simultaneously, with functionality orthogonal to one another. Personally, I'll adopt the first that will come.

> An alternative way to solve this bug would be to have special headers that can > prevent moving a message to the Junk folder. That would be in addition to > checking if the sender is in a given address book. The request to store junk status in the headers, like is currently done with tags, is bug 195737, but is not implemented yet. But that is only a partial solution to the current bug. The implemented solution is an inherited folder property As I said in comment 28, the backend support for this already exists, added in bug 471833 . Additional work has also been done on the front end since that comment was made (if you disable junk processing for a folder, then the junk/unjunk UI is disabled). The only thing that is not implemented is UI to set the folder property on a folder to disable junk processing. That is implemented in the development version of my extension JunQuilla, and will be available in the released version when I post it in a few weeks (the posted version on AMO does not have this at this moment). This is a special enough use case that I doubt if it will ever make sense to do this in the core UI. If Mozilla had a bug status of "We won't do this in core, but is available in extensions" I would nominate this bug for that at this point.

(In reply to comment #34) > It is *one* way. It should store some folder flag on the server, otherwise > accessing it from another client --even the same version of TB-- may > unexpectedly discard some messages. The current TB stores junk status in per-message flags on IMAP servers that support that, as most do. So if you mark a message as junk or good in one copy of TB, another copy will also see that status.

There's another solution to the "old mail" problem than a per-folder flag: Have Thunderbird only scan new mail. Where "new" is defined by POP3 download, or by IMAP unseen (or however it's called) flags.

I filed bug 526268 for that.

In reply to comment #37) > There's another solution to the "old mail" problem than a per-folder flag: > Have Thunderbird only scan new mail. Where "new" is defined by POP3 download, > or by IMAP unseen (or however it's called) flags. This bug as far as I understand it is not about the new mail/old mail problem. It is mostly about new mail that was preprocessed by server-based filters, so that the first time that TB sees it, it should not receive junk processing.

3 of the 4 cases listed in comment 32 where "old mail" and would hopefully be solved by bug 526268. I also think that this is problem most users here have, given the comments. It's also the case I ran into. If your server does server-side spam filtering, you should simply disable TB spam filtering entirely. The only reason I can see why you'd want this bug here is that there's some server-side filtering of new mail, and you know that none of the filtered mails are junk. I think that's a corner-case (not many use server-side filtering to start with, because there's no UI for it), but nevertheless conceivable.

(In reply to comment #34 and comment #40) > It is *one* way. It is the way that would be simplest to code *and* would have the broadest coverage of different scenarios. WRT simple, there is a trade-off between a good-enough solution somewhat soon, or a fantastic solution sometime in the astronomical future. After all, let's not forget that this bug is already almost seven years old. If the entire functionality we are discussing here is already implemented, as Kent says, and only the UI part is missing, the likelihood of the missing link getting coded is much higher than the likelihood of a completely new solution being implemented from scratch any time soon. Therefore, economy of effort and time speaks for a simple checkbox too, suitably under folder properties -> general. > 3 of the 4 cases listed in comment 32 where "old mail" and would hopefully > be solved by bug 526268. Or vice versa. If the UI we are talking about was implemented, it would solve 3 out of 4 cases where bug 526268 is valid.

(In reply to comment #40) > The only reason I can see why you'd want this bug here is that there's some > server-side filtering of new mail, and you know that none of the filtered mails > are junk. I think that's a corner-case (not many use server-side filtering to > start with, because there's no UI for it), but nevertheless conceivable. Alas it's a corner case. Let's not forget that spam is queer, not regular mail. Certified mail, vouched servers, PEC (in Italy), are example of mail that requires no scanning to determine it legitimacy. Hopefully, we'll have more of these, eventually. For those who use Courier-IMAP and Maildrop, the TB-specific workaround --after Kent's clarifications-- is the following delivery recipe: if ($CONDITION) { KEYWORDS="NonJunk" to "./Maildir/.WhateverFolder" }

> Certified mail, vouched servers, PEC (in Italy) Yeah, but how many of those get filtered in a separate folder, not in Inbox? And how likely are users to *manually* configure their TB to exempt this folder? Both of these are the reason why I'm in favor of bug 526268. But I'm not stopping anybody from fixing this one...

(In reply to comment #43) > > Certified mail, vouched servers, PEC (in Italy) > > Yeah, but how many of those get filtered in a separate folder, not in Inbox? This bug is specifically about the case where the items of interest are in a separate folder. Another option that you have in TB core is to mark the messages as not junk in a filter action, which works whether or not the messages are in a single folder. There is a lot of confusion in terminology in TB between "marking" a message as junk/good, or "training" it as junk/good. The filter action just sets the junk status, without doing training. The UI actions to junk or unjunk messages always train the messages as well as change their status. The existence of this option is one reason why this bug, and similar bugs, have not received much attention. Of course, if you can do this at the server level, as suggested in comment 42, that is even better. In comment 40, Ben said "If your server does server-side spam filtering, you should simply disable TB spam filtering entirely." I'd like to mention that this is not the policy that I promote - and I am the main guy that is currently maintaining the spam management backend in Mozilla mailnews. I think that the best results are achieved when you use a server-based filter that is configured to only reject certain spam, and perhaps also give hints in the message itself as to its evaluation of the spam status of the message. These hints can then help the local bayes filter to make its final determination. Then the bayes filter in Mozilla mailnews makes the last determination, using user-specific information to help evaluate messages that are uncertain, and perhaps also rejecting user-determined unwanted messages, that are not perhaps considered certain spam to everyone. For example, because I ran a business in Azerbaijan for a few years, I get a lot of messages that are from that part of the world, where the senders do not maintain US standards for opting out, but would have been legitimate if I was still working there. At this point, I want my local spam filter to reject them, which requires the personal customization that a client-based bayes filter can provide.

(In reply to comment #42) > the following delivery recipe: > > if ($CONDITION) > { > KEYWORDS="NonJunk" > to "./Maildir/.WhateverFolder" > } doesn't work. When I posted that, I had tested it with a different keyword, and just checked that TB recognized it. I trusted that the presence of "NonJunk" would have prevented scanning, as it has often been said. It doesn't. Hence, I filed a new, more specific, enhancement request as bug 527430. Please subscribe/ vote/ discuss that according to your liking.

(In reply to Alec Flett from comment #2) > I should clarify then - I have mail filters which filter messages into folders. > When I open those folders, they have new messages in them, which subsequently get checked for spam. What kind of account? If POP3, it may be (a) "Junk filter is applied to filter moved mail" after design/implementation change. If imap, and if relevant msils are Unread mail, it may be (a) + (b) bug 770137. As I wrote in bug 1215933 comment #55, CallFilterPlugins() is called after header fetch for newly detected mail(new UID, Unread==no \Seen flag). Junk filter may be executed in this case, although I'm not sure.

> Bug Summary : Ability to block certain folders from junk filters Design itself is pretty simple: Folder Properties : [ ? ] When getting new messages for this account, always check this folder <= already exists [ ? ] When applying Junk filter, always exclude this folder <= new After that, if Jujnk filter respects this setting, your request is fulfiled :-)

As easily known by simple test of bug 1215933 comment #50 and code refererred in bug 1215933, set of "message filter(before)/Junk Classification/message filter(after)" is requested on any newly detected UID(without \Seen flag) in any imap folder(except Junk etc.) after header fetch of newly detected mail(when no Body condition) or after fetch body[] of newly detected mail(When Body condition is used). Is it design from since initial of Junk filter/message filter(currently called "Filter before Junk Classification")?

What is actual problem/request of this bug? (1) If imap, Junk Filter(and "Filter after Junk Classification" too from Tb 3) is invoked on any new UID(without \Seen flag) in any imap folder(except Junk etc.) => need a way to stop Junk filtering at user-requested folder (2) If imap, Junk Filter(and "Filter after Junk Classification" too from Tb 3) is invoked on any new UID(without \Seen flag) in any imap folder(except Junk etc.) => It should be invoked on new mail detected by new mail check(and via. IDLE) only. (3) Junk filter(Bayesian Filter) is not reliable => need a way to stop Junk filtering at user-requested folder (4) Junk filter(Bayesian Filter) is not reliable => improve it (5) other issue in Junk filter/other request on Junk filter FYI. "Filter after Junk Classification" was implemented, and it can be used as a complement of hard-to-control-for-us Junk Filter. So, there is a way to alter Junk filtering result from Tb 3, although it can produce infinite filter move loop by special/intentional but pretty simple test of bug 1215933 comment #50. "Junk filter application on filter moved mail" is not applied to "mail moved by Filter After Junk Classification", so it's convenient for us, although bug 1215933 can currently occur by combination of (1)=bug 770137 and bug 1320676.