Closed Bug 806308 Opened 13 years ago Closed 11 years ago

Message filters not automatically applied for folders

Categories

(MailNews Core :: Filters, defect)

Product:
MailNews Core
Component:
Filters
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 428574

People

(Reporter: abugreporter, Unassigned)

Details

(Whiteboard: dupeme)

Attachments

(2 files)

for comment #5
2.11 KB, text/plain
Details
for comment #5
7.36 KB, application/octet-stream
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5 Steps to reproduce: Take a Gmail account. Add Gmail filters which move mail from one folder to another, e.g. one named "MyTestFolder". The preceding is done in the Gmail web-interface. Then create some filters in Mozilla Thunderbird 16.0.1 as distributed by Ubuntu LTS 12.04.1 which match messages arriving in MyTestFolder. These filters have all been configured with the 'Checking Mail or Manually Run' option and they do apply to the account with the associated GMail account. Actual results: Now, when e-mail is fetched either manually or automatically, the Mozilla filters are not applied to such mail arriving in MyTestFolder. The filter log does not display that it has ever processed these messages in MyTestFolder. Expected results: It should have applied the Mozilla message filters automatically, thereby moving some messages to the Trash, like I configured it to do. If I manually apply the filters using the 'Run Now' button, it does work.
Can you paste a msgFilterRules.dat file with a sample filter that does not work for you?
My description of the problem has been more than clear enough. If you say that you have tried to reproduce this (which takes 10 minutes, even when including the create a gmail account step), then I can consider to debug this further, but since I haven't seen you say, that I doubt this. Like I said, the filters work perfectly fine when I manually apply them. I also told you when the filters are configured to run. If it then doesn't work, and assuming you trust me, there would be no need for me providing the msgFilterRules.dat file. I am not reporting this for no reason and my 'false bug report'-rate has been extremely low.
No problem with that. So let's wait for somebody with a gmail account. But I think you have not said yet if you use it in IMAP mode and if you have set the folders for offline use.
(In reply to :aceman from comment #3) > No problem with that. So let's wait for somebody with a gmail account. > But I think you have not said yet if you use it in IMAP mode and if you have > set the folders for offline use. I use it in IMAP mode and I have set the folder in Thunderbird for offline use.
Hi, I am facing a quite similar issue with my corporate IMAP server. When I use filters based on message headers, all of them work cool, but when I add additional filters, based on matching of some pattern in message body, ALL filters stop to work. Please find additional information regarding the OS, Thunderbird versions and my msgFilterRules.dat in the attachments.
Attached file for comment #5 —
info regarding software versions
Attached file for comment #5 —
Thunderbird filters
His analysis matches my experience (I also filter based on contents). You can mark this CONFIRMED now.
(In reply to v-baskoff from comment #5) > I am facing a quite similar issue with my corporate IMAP server. What part is QUIT similar? This bug: IMAP Filter is not applied(or fails to find mail) when new mail is fetched. "No filter log which is relevant to the filter rule" when problem occured. If I manually apply the filters using the 'Run Now' button, it does work. Note: Opposite to bug 184490. "What kind of filer rule" is not provided yet. "Offline-use=On was used when problem occured or not" is unclear. "Offline-use=On was effective workaround or not" is unclear. (sounds problem occured with Offline-use=Off ) (and sounds changed to Offlin-use=On around 10/30, but unclear) Your case: IMAP Filter rules on message header work cool. Filter rule on "Body" doesn't work. when I add additional filters, based on matching of some pattern in message body, ALL filters stop to work. Following is a Web document easily found by Google search for "thunderbird message filter imap body". > http://kb.mozillazine.org/Filters_%28Thunderbird%29#Filtering_the_message_body > Filter rules on message header work cool. > Filter rule on "Body" doen't work. Is somthing stated in above ducument applicable to your problem? Nothing is relevant to you problem and your problem is "*ALL filters stop to work* merely by adding some filter rules which refers to Body" part?
(In reply to abugreporter from comment #2) > My description of the problem has been more than clear enough. What part is "more than clear enough"? (In reply to abugreporter from comment #0) > Actual results: > Now, when e-mail is fetched either manually or automatically, the Mozilla > filters are not applied to such mail arriving in MyTestFolder. > The filter log does not display that it has ever processed these messages in > MyTestFolder. >(snip) > If I manually apply the filters using the 'Run Now' button, it does work. It's opposite to bug 184490. AFAIK, there are two kinds of problem. (a) Run Now doesn't work. Filter works if filering upon new mail fetch bug 184490 is an example. When fetch of new mail, multi-line headers(folded) is unfolded, so filter works, but if mail already held locally, multi-line header is kept as-is, then fails to find string. (b) Run Now works well. Filter doesn't work if filering upon new mail fetch. Your case. (In reply to abugreporter from comment #8) > His analysis matches my experience (I also filter based on contents). This looks your first information about "characteristics of your message filter rule". If Body is relevant to your problem, and if you are looking your problem even atter change to Offline-use=On from Offline-use=Off, phnomenon may be; new mail is detected -> fetch messsage headers(saved in .msf, MsgDB) -> filter is excuted before fetch of entire mail data to Offline-store file by auto-sync, -> because body data is not downloade yet, filter can't find body data -> after a while, entire mail data is downloade to offline-sore by auto-sync -> Run Now can find data in message body
If you are the developer of this application, you should have a test setup which tests for all the cases separately and for random combinations. If you would have such a setup, you would immediately have seen this bug. Releasing broken code just shows you are incompetent. Blaming *me* for not giving enough information is something only weak developers do. The way to fix this and other problems is to write a good test framework, or to simply prove that it always works. Since your whole software architecture depends on on poking memory the latter might prove to be to difficult for you. Please explain why I have to explain to you how to develop software which doesn't have such basic issues; it's a message filter, not a game-engine, FFS. I am not interested in spending time on solving this. I only reported the bug, which has now been confirmed. You want to run around with your Thunderbird branding and your annoying default search engine choices (yes, I know that a tiny fraction of the population knows that this can be changed), so *you* fix it or you (as in the Mozilla organization) get a reputation for not even being able to implement message filters correctly (which is something a 10 year old can do).
(In reply to WADA from comment #9) > Following is a Web document easily found by Google search for "thunderbird > message filter imap body". > > http://kb.mozillazine.org/Filters_%28Thunderbird%29#Filtering_the_message_body Thank you for appointing the link, it cleared the vision of reported behaviour. > > Filter rules on message header work cool. > > Filter rule on "Body" doen't work. > Is somthing stated in above ducument applicable to your problem? > Nothing is relevant to you problem and your problem is "*ALL filters stop to > work* merely by adding some filter rules which refers to Body" part? Only possible pattern for matching some mails in my company is "<Status: xxxx, Priority: Normal (XX)>" which is placed in the letter body. According to the provided link I have added the "<Status" pattern as a custom header but the issue still exists - incoming mail doesn't match the filter which searches a "open" text-pattern in this new header using "contains" logic. So, the only possible workaround for this issue is to add an additional header on the IMAP server side. It is right?
(In reply to v-baskoff from comment #12) > So, the only possible workaround for this issue is to add an additional > header on the IMAP server side. It is right? That docuent refers to "Body custom header" and that document seems to say "the Body custom header is a workaround for Body filter in IMAP". But I think the "Body in custom header of Tb's message filter" is "BODY: header in mail data stream", although Tb may fetch entire mail body if "Custome header of Body" is reuested in message filter of Tb(I can't thnk so.) I think "header by server" is simplest/easiest workaround if possible. > (1) Add "X-MyCompany-Header-1: <Status: xxx, ..." at server > (similar to header added by SpamAssasin, AVG etc. for virus scan result) > (2) Custom header definition of X-MyCompany-Header-1 in Tb's filter definition > (held in mailnews.customHeaders) > => X-MyCompany-Header-1: is retrieved upon fetch of message headers. > (3) Filter rule of "If X-MyCompany-Heade-1 contains, ... If Offline-use=Off(entire mail data is not held in local offline-store file by auto-sync), and if "Run filters on Folder", "Run Now" etc. is also needed in adition to "filtering upon new mail fetch", setting the header in mailnews.customHeaders is needed in order to hold header data in MsgDB(.msf).
Sorry, typo. Setting in mailnews.customDBHeaders is needed if custom header data should be saved in .msf.
(In reply to v-baskoff from comment #7) > Thunderbird filters > condition="AND (body,contains,<Status: closing, Priority) AND (\"x-rt-queuename\",contains,WEB-Devel)" If server side action is possible, "adding IMAP flag by server side application" is also a simple/easy workaround in your case. (1) Server application adds IMAP flag of closing, frozen, ..., open, new to mail (2) Tag definition in prefs.js of all Tb users mailnews.tags.closing.tag = "closing", or "Closing" or localized "closing" mailnews.tags.new.tag = "new", or "New or localized "new" (3) Filter rule of "if Tag contains ..." in Tb I prefer IMAP flag/Tag way to message header way, because it's always visible for mail client user, and because "changing IMAP flag(Tag for Tb) of existent mail by server application" can be used for notification of status change, without sending new mail, although server side IDLE support, Tb side IDLE use, and server side correct "flag status change notification to IMAP client via IDLE" is perhaps currently needed. WEB-Devel (mails are moved by "x-rt-queuename contains WEB-Devel") Saved search folder = 01-new : Tag is "new" Saved search folder = 02-open : Tag is "open" | | Saved search folder = 11-frozen : Tag is "frozen" Saved search folder = 12-clsed : Tag is "closed"
(In reply to v-baskoff from comment #7) > Thunderbird filters > condition="AND (body,contains,<Status: closing, Priority) AND (\"x-rt-queuename\",contains,WEB-Devel)" Because message body data is not fetched to offline-store file when Offline-use=Off folder, message filter of "Body" won't work if IMAP Offline-use=Off folder. So, "Body" was hidden at Message Filter definition panel if folder is IMAP Offline-use=Off, and is still hidden to avoid user's confusion or misleading of users. v-baskoff, how did you create the filter rule? (a) IMAP Offline-use=On folder, so Body could be selected at UI. (b) Didn't care about IMAP Offline-use=On/Off. Edited msgFilterRules.dat file. (c) Defined while IMAP Ofline-use=On is set, but folder is changed to Offline-use=Off. In message filter UI, "Body" is shown in grayed-out to warn, but you ignore it. Perhaps answer is (a). If IMAP folder, "Body" should be hidden at message filter definition UI except when "Manually Run" && "Offline-use=On".
In the case of abugreporter's automatic filters for "MyTestFolder", I should think this is not expected to work. My recollection is automatic filters operate by default on the *Inbox* only.
Wayne, that is for POP3. I am not sure how IMAP is supposed to work. Maybe there any folder is checked for new messages.
Product: Thunderbird → MailNews Core
(In reply to :aceman from comment #18) > Wayne, that is for POP3. I am not sure how IMAP is supposed to work. Maybe > there any folder is checked for new messages. sometimes the memory works :) reference bug 428574
Symptom itself is already known issue by not so small number of already opened bugs, but I couldn't find specific bug for the issue. Confirming per undertandable report by v-baskoff@baks-lab.org.ua(and per additional information of "Body filter" from bug opener after the report), with adding some words in bug summary, for ease of tracking and search. Request of "hide Body" is bug 199689. Setting dependency for ease of tracking.
Status: UNCONFIRMED → NEW
Depends on: 199689
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Summary: Message filters not automatically applied for folders → Message filters not automatically applied for folders (If IMAP, "Body message filter upon mail fetch" is meanngless regardless of Offline-use=On/Off, because message body is not fetched yet upon filter execution)
Whiteboard: dupeme
Because of current mechanism, Body filter can't work upon new mail fetch from IMAP serer. I believe "Filtering always after fetch of entire mail data" can't be usable as design/implementation of Thunderbird. And, Bug 199689 is not for resolving the issue. That bug is to reduce user's confusions and to reduce bug open by general users like this bug. To resolve problem, some new mechanism is needed. Just an idea. (a) When Offline-use=On, entire mail data is downloaded to offline-store file sooner later by auto-sync if auto-sync is enabled, or upon mail view if auto-sync is disabled. In this case, as bug openers says since initial bug open, "manual filtering after download to offline-store" works well. So, mechanism like following can be a solution. (i) if a mail satisfies all conditions other than "Body" of a filter rule, set "delayed filtering is needed" flag for the mail, and stop further filter rule application to the mail. (ii) after fetch to offline-store file by auto-sync or mail view, invoke filter for the mail of "delayed filtering is needed" flag. (b) above (a) can be modified. (i) if a mail satisfies all conditions other than "Body" related condition in a filter rule, and if the rule has new condition of "if Body is not available", and if action is new "delayed filtering", set "delayed filtering is needed" flag for the mail, and stop further filter rule application to the mail. (i-x) Change meaning of current "if Body ..." condition. "if Body ..." == "if Body is available && if Body ..." (ii) after fetch to offline-store file by auto-sync or mail view, invoke filter for the mail of "delayed filtering is needed" flag. I prefer explicit (b)-way to implicit-(a) way, because (a) involves hidden action by Tb which user can't usually know, and because (b) like one is easier to enhance or improve for Offline-use=Off case than implicit (a) like one.
v-baskoff@baks-lab.org.ua, what do you think about proper solution of problem?
For Offline-use=Off case. I think there is no reason to absolutely prohibit offline-store file use all the time simply because folder property is Offline-use=No. - If Work Offline mode, draft save utilizes offline-store file - If IIRC, copy/move utilizes offline-store file when target is offline-use=On So, change like "fetch to offline-store file if Body filter is beeing applied to a mail of IMAP folder" may be a solution of Offline-use=Off case, although some change like "don't discard offline-store file data when folder is changed from Offline-use=On to Offline-use=Off" is perhaps needed. Other reason to utilize offline-store file even for Offline-use=Off folder. Existence of problem like bug 184490 In this case, mailnews.customDBHeaders="required header list" can be a work around of the problem. But it increases .msf file data(i.e. easily increases memory requirement), so I don't think applying it always to any custom header is safe. I think "storing all headers or all cutome headers in offline-store file" is a reasnable solution of problem like bug 184490, because large HDD is pretty popular nowadays and environment of "40MB HDD" or "80MB HDD" like one is already rare.
Another way. If user requests Body filter for IMAP folder, ask user to change the folder to Offline-use=On or not, and if answer is no, reject Body filter.
Hi WADA, I think that variant (b) logic from "Comment 21" together with additional check from "Comment 24" is a most suitable way to handle this issue, because not everybody have permissions/ability to handle this on server side by adding additional headers for matching some correspondence. I can done QA part for this ticket if someone take development part.
I'm really confused what this bug is about. Comment 0 describes a server-side filter that moves a message, then complains that the message is not processed by IMAP incoming filters. This is by design as noted correctly in comment 17, so that bug should not have been confirmed. I believe there is another bug somewhere that this bug could be duped to that requests an enhancement to allow that. Also, there are underlying hooks in the core code that allow extensions to change this behaviour, and my extension FiltaQuilla allows specifying non-inbox folders where incoming filters may be applied. v-baskoff@baks-lab.org.ua's comment 5 introduces what appears to me to be a different issue concerning the effect of body searches, and one that I am not familiar with. Most of the remaining history and analysis seems to deal with this issue. WADA is trying to understand if this is related to offline mail folders, but I don't see any word from v-baskoff@baks-lab.org.ua whether his IMAP folders are set for offline use. Is it? I just did a quick test of IMAP body filters, and it is working fine for me. That is, if I have a filter "Subject contains test" AND "body contains star" THEN "Add Star" it is working fine for me. So I do not have a reproducible test case.
(In reply to Kent James (:rkent) from comment #26) > I'm really confused what this bug is about. > Comment 0 describes a server-side filter that moves a message, then > complains that the message is not processed by IMAP incoming filters. > This is by design as noted correctly in comment 17, so that bug should not have been confirmed. This bug is for IMAP case since initial to now(and perhaps till end of this bug, unless morphed by someone). Comment #17 is, as stated by comment #18, applicable to POP3 only. Please never ignore following case in IMAP. (1) Server side filter of IMAP server moves mail from Inbox to other folder such as FolderX, without storing \Seen flag nor \Deleted flag nor \Junk flag. (2) At Server Settings of Tb, user enables "Check for new messages at startup/every NN minutes". (3) New mail check by Tb for the FolderX. (3-a) Tb user checks [x] "When getting new messages for this account, always check this folder" at Folder Properties/General of FolderX. (3-b) IMAP Server uses primary personalNamespace=="INBOX/" or "INBOX.", and all Mbox, except Mbox for other personalNamespace/publicNamespace/otherUsersNamespace, is placed under Inbox. So, folder called FolderX is always sub folder of Inbox. SpecialUse flag states of folder=="Inbox" is checked for parents too by Tb, true is returned to nsMsgFolderFlags["Inbox"],true) for sub folder of Inbox. So, sub folders under Inbox is folder of SpecialUse=Inbox attribute in Tb. (4) Tb user uses message filer of Tb for the IMAP account. (5) A filter rule has setting of "Checking Mail" in "Apply filter when:"(not "Manually run" only). (6) User defines the filter rule with mail.server.serverN.offline_download != false. ("Checked state" is shown by Tb for "keep messags on this computer...") ( at Account Settings/Synchronization. ) (7) Because "Body" is shown in selection list at filter rule definition panel by mail.server.serverN.offline_download != false, user can define condition for Body via Tb's message filter UI. > but I don't see any word from v-baskoff@baks-lab.org.ua whether his IMAP folders are set for offline use. Is it? Because "manual body filter run" works well in bug opener's case, his case is auto-sync=enabled/Offline-Use=On case. And, because this bug is for problem with IMAP && Body filter && "Checking Mail" in "Apply filter when:", Offline-Use=On or Offline-Use=Off is not directly related to this bug. i.e. Problem can occur even when auto-sync=enabled && folder is Offline-Use=On. So, I don't ask for Offline-Use=On or Offline-Use=Off to him all the way in this bug.
(In reply to Kent James (:rkent) from comment #26) > I just did a quick test of IMAP body filters, and it is working fine for me. > That is, if I have a filter "Subject contains test" AND "body contains star" > THEN "Add Star" it is working fine for me. So I do not have a reproducible test case. "Checking Mail"? Or "Manually run"? If you can't reproduce problem with "Checking Mail", it may be timing dependent problem or mail data dependent problem. (a) If previewText(top 2048 bytes of message body) is fetched by Biff just after message header is fetched before message filter is invoked, message filter may be able to see a part of message body data. If search target string of Body filter is contained in the top 2048 bytes part, Body filter works. (b) Auto-sync fetches entire mail data and saves the data in offline-store file before message filter is invoked, so message filter can see message body data. (c) After message header is fetched and mail is shown at thread pane, before message filter is invoked, user clicked the mail then entire message data is stored in offline-store file before message filter is invoked, thus message filter can see message body data. (d) If "(after classification)" in "Apply filter when:", auto-sync can fetch entire message data and can save it in offline-store file, before message filter is invoked. (e) Some addons request fetch body[] or fetch body[TEXT] for text mail, or request fetch body[m.n] for first text part in multipart message(usually message body for mail display by Tb) before message filter is invoked, then message filter can see full message body or part of message body for message filter.
(In reply to Kent James (:rkent) from comment #26) > I just did a quick test of IMAP body filters, and it is working fine for me. > That is, if I have a filter "Subject contains test" AND "body contains star" > THEN "Add Star" it is working fine for me. So I do not have a reproducible test case. If you can't reproduce problem with "Checking Mail", it may be relevant to other component such a Gloda. (f) If a mail is copied within a same IMAP account, mail of different UID in different Mbox can have absolutely same message data. If FolderA/UID=a for a mail-X is already downloaded to offline-store file and is Indexed by Gloda, and if new mail in FolderB/UID=b is absolutely same mail as the mail-X, message filter can obtain data for the mail-X before fetch from FolderB.
(In reply to WADA from comment #27) > > This bug is for IMAP case since initial to now(and perhaps till end of this > bug, unless morphed by someone). Comment #17 is, as stated by comment #18, > applicable to POP3 only. > I am referring to this code in nsImapMailFolder which is clearly an IMAP and not a POP3 property, that determines whether incoming filters are applied to new IMAP messages: 631 // If this is the inbox, filters will be applied. Otherwise, we test the 632 // inherited folder property "applyIncomingFilters" (which defaults to empty). 633 // If this inherited property has the string value "true", we will apply 634 // filters even if this is not the inbox folder. 635 nsCString applyIncomingFilters; 636 GetInheritedStringProperty("applyIncomingFilters", applyIncomingFilters); 637 m_applyIncomingFilters = applyIncomingFilters.EqualsLiteral("true"); 638 639 if (mFlags & nsMsgFolderFlags::Inbox || m_applyIncomingFilters) So I do not expect incoming filters ("Checking Mail") filters to be applied to non-inbox folders for IMAP unless the user has overridden the default preference.
(In reply to Kent James (:rkent) from comment #30) > So I do not expect incoming filters ("Checking Mail") filters to be applied to > non-inbox folders for IMAP unless the user has overridden the default preference. Are you saying, "incoming filters shouldn't be applied to other than Inbox in v-baskoff@baks-lab.org.ua's case, unless one or more special preference settings is overridden by him", according to source code? If so, what preference setting? > 639 if (mFlags & nsMsgFolderFlags::Inbox || m_applyIncomingFilters) As for incoming message filter, Tb looks to check running folder's flag only, instead of checking parent folder's flag too by msgFolder.isSpecialFolder(nsMsgFolderFlags["Inbox"],true) which is used for default of thread pane's column setting(Inbox type or SentMail type). I thouhgt problem of "new mail is checked for any folder under Inbox when namespace=INBOX." was still alive. Sorry for my confusion.
Correction on "condition when Body is shown in message filter for IMAP". It depended on setting change of "keep messags on this computer..." at Account Settings/Synchronization&Disk Storage. UI for "keep messags on this computer..." did followings. - Change from Unchecked to Checked Set mail.server.serverN.offline_download = true Set Offline-Use=On to all folders of the IMAP account Show Body at Message Filter definition UI - Change from Checked to Unchecked Set mail.server.serverN.offline_download = false Set Offline-Use=Off to all folders of the IMAP account Hide Body at Message Filter definition UI Note: Following can be altered independently after above setting change, via Config Editor, Advanced at Account Settings/Synchronization&Disk Space, or Folder Properties/Synchronization. - Auto-sync is enabled or disabled mail.server.default.autosync_offline_stores = true/false mail.server.serverN.autosync_offline_stores = true/false, or reset states - Default of Offline-Use setting of newlly added mail folder mail.server.default.offline_download = true/false mail.server.serverN.offline_download = true/false, or reset states - Folder Properties/Synchronization of each folder Offline-Use = On / Off So, (6) in comment #27 should be; (6) After setting change from Unchecked to Checked of "keep messages on this computer..." at Synchronization&Disk Storage(==Initial/Default status), user defines message filter rule for IMAP account.
(addition to comment #27, based on discovery of comment #32) (8) If user changes "keep messages on this coputer..." setting from Checked to Unchecked after filter rule definition with Body for IMAP account, the rule with Body is grayed out.
"Are you saying, "incoming filters shouldn't be applied to other than Inbox in v-baskoff@baks-lab.org.ua's case, unless one or more special preference settings is overridden by him", according to source code? If so, what preference setting?" I see no evidence that v-baskoff@baks-lab.org.ua is using a server-side filter and trying to filter on a non-INBOX folder. But abugreporter@gmail.com in comment 0 is clearly trying to do that, and it is his report as OP that should define this bug. It is the behavior in comment 0 that is expected behavior. The recommended way to do what he wants to do is to install the FiltaQuilla extension which provides that capability. You could also set the following preference to string "true" that would grant this behavior to all folders, but that is not recommended as you can get into some strange filter loops as messages are moved from folder to folder, then rechecked: mail.server.default.applyIncomingFilters (This BTW is a capability that I added to the core code years ago, so that extensions like FiltaQuilla could override this behavior if desired.)
(In reply to Kent James (:rkent) from comment #34) > mail.server.default.applyIncomingFilters What is reason why you recommend it even though per folder "When getting new messages for this account, always check this folder" is already implemented, and even though you know that it can cause filter loop if used blindly?
(In reply to WADA from comment #35) > (In reply to Kent James (:rkent) from comment #34) > > mail.server.default.applyIncomingFilters > > What is reason why you recommend it even though per folder "When getting new > messages for this account, always check this folder" is already implemented, > and even though you know that it can cause filter loop if used blindly? I think that I specifically said that I did NOT recommend that, but I was offering it as an alternative to my recommended "FiltaQuilla" solution. To prevent filter loops when messages are moved, possible solutions are to not enable filters for destination folders, or to add a specific filter on folder name that disables the filter for specific folders. Either option is possible using FiltaQuilla.
"When getting new messages for this account, always check this folder" does not enable filters for a specific folder. The core code does not have a UI to allow you to enable filters on a per-folder basis.
Sorry, I confused setting for new mail check with setting for incomming filter. > http://mxr.mozilla.org/comm-central/source/mailnews/base/util/nsMsgDBFolder.cpp#2220 > 2220 nsMsgDBFolder::GetInheritedStringProperty(const char *aPropertyName, nsACString& aPropertyValue) GetInheritedStringProperty is for mail.server.serverX.applyIncomingFilters and for inheritance from mail.server.default.applyIncomingFilters. This may be(perhaps is) applicable to commet #0. But I thought comment #5 case, for which reporter says quit similar to this bug, is surely different from it, not non-Inbox case, because incomming filter works well for other than Body upon message download. (see my commen #9 and my comment #10, please...) Anyway, re-opening this bug, because comment #5, for which I did problem determination works in this bug, is perhaps different from original problem of this bug.
Status: NEW → UNCONFIRMED
Ever confirmed: false
To v-baskoff@baks-lab.org.ua(comment #5 poster) : Is your case for Inbox? Or other than Inbox? If "incoming filter on Inbox" case, open separate bug for your promlem, please, because comment #0 is apparently for "incoming filter on non Inbox" case. Sorry for my confusions.
To abugreporter@gmail.com(bug opener): Your case is "incomming filter on non Inbox" case, and it sounds "Body filter in IMAP" is relevant to your problem. As Kent James kindly explained, mail.server.serverX.applyIncomingFilters and mail.server.default.applyIncomingFilters is relevant to "incomming filter on non Inbox" case. What is your setting? Can mail.server.serverX.applyIncomingFilters=true be a workaround of your problem?
Summary: Message filters not automatically applied for folders (If IMAP, "Body message filter upon mail fetch" is meanngless regardless of Offline-use=On/Off, because message body is not fetched yet upon filter execution) → Message filters not automatically applied for folders
No longer depends on: 199689
To abugreporter@gmail.com(bug opener): As Kent says in comment #36, addon of "FiltaQuilla" is usefull for "incomming filter on non Inbox" case. Try "FiltaQuilla" for your "message filter for mail arriving in MyTestFolder" case, please, if manual setting changes etc. is hard for you.
I think neither of the reporters is here anymore.
(In reply to WADA from comment #41) > To abugreporter@gmail.com(bug opener): > As Kent says in comment #36, addon of "FiltaQuilla" is usefull for > "incomming filter on non Inbox" case. Try "FiltaQuilla" for your "message > filter for mail arriving in MyTestFolder" case, please, if manual setting > changes etc. is hard for you. the reporter begged off in comment 11 so we needn't waste time with him/her. AFAICT this is bug 428574
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
(In reply to Wayne Mery (:wsmwk) from comment #17) > In the case of abugreporter's automatic filters for "MyTestFolder", I should > think this is not expected to work. My recollection is automatic filters > operate by default on the *Inbox* only. If this is true, where is (or was) this reflected in the UI? If it isn't, then there is a UI bug. You are working on Thunderbird and all you can say is that you have a "recollection". How do you expect a user to know this when you don't?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: