I've seen the mail/news external task "Filtering After The Fact". What I'd like is a folder filter than gets run regularly. So I'm submitting this RFE, for _comprehensive_ filtering. Filtering after the fact, which I'm interpreting as manual selection and filter application, is a part of this. You could have lots of triggers for filters. (a) When new message arrives (obvious). (b) When message arrives in this folder (can be fired due to a manual move or another filter moved the msg just before - watch out for endless rule firing) (c) When a cleanup occurs. (d) A combination of these (eg a OR b) (d) None : manual only (ie after the fact). (c) would absolutely rock. I would have filters set up to delete msgs > 14 days old AND read. So you would choose a menu option saying "Cleean Up Mail Folders" and BAM! - all the old messages are trashed or archived to another folder. All the filter actions would be the same as the new mail filters. Pretty cool huh? Not that it will make it into v5! =)

reassign to bienvenu.

yes, it won't make it into 5.0, unless some contributes it.

It would also nice to be able to create a one-off "filter" to apply, so you could select a bunch of folders and/or messages, then choose "Apply Action" which would bring up the standard filter screen. This filter wouldn't be saved at all.

marking [HELP WANTED].

Since this is a "help wanted" bug, I'll go ahead and reopen this bug. All our other "help wanted" bugs are open.

Then I'm going to move this to M15.

There are two bugs this depends on - they are both subsets of this functionality. Bug #11033 is about filtering mail that is already in a folder, and bug #11039 is about filtering outgoing mail. I had to mention the latter here or else I couldn't be honest with myself in calling this "comprehensive" filtering. =) Scratch my comment about one-off filters. The actions are obviously already available, therefore the sole advantage is the presence of the ability to apply to a subset of documents. I've realised this would be better done as a menu option to conditionally select messages, and have filed bug #12007.

The "cleanup" idea seems unnecessarily restrictive. An expanded idea is to allow users to define their own manual triggers. You would have a submenu in the UI containing all the triggers: Filter Triggers > Clean Up Old Messages Trim Sent Folder etc. Each filter might sit on one of these triggers.

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey bug tracking radar. Even though these bugs are not "open" in bugzilla, we welcome fixes and improvements in these areas at any time. Mail/news RFEs continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org

One action to this might be "delete attachment", which might be useful for outgoing mail.

It would be nice if procmail configurations could be left relatively unhindered, and still work with Mozilla.

This is the first RFE I voted for - this is absolutely necessary for a decent mailer, and I really would like to see clever filtering in MozMail! Esp. the "delete attachments"-action is a *must-have* and a very good idea I also had in mind for some time now. If you get big attachments like JPGs, MP3s etc. and save them, it's a real waste to leave them in the mailbox. I'd love to see at least some of that functionality (like the "delete attachment"-stuff), also the bug is growing a bit old now...

delete attachment is the subject of another bug.

most of this work is done now, as I understand it. Pointing back to component owner to see if this can be closed, or updated.

There are several times during the lifespan of a message when it should pass through a ruleset: * OPTIONALLY, after the headers are retrieved but before the body is retrieved, to determine whether to retrieve the body. Turning this on has extra overhead on POP3 (since the body can't be retrieved without refetching the header), so whether to use it or not should be a separate pref for mail versus usenet. Very few clients do this for mail, though some do it for usenet. Spam being what it is these days, doing it for mail would save many of us bandwidth in spite of the overhead of retrieving headers twice for all legit messages. * When the message is retrieved, to determine which folder to file it in. By default, if there is no rule that matches, it goes into the inbox. Many mail clients do this; Gnus is one example. * Whenever the message is placed into a folder. Each folder should be able to have its own rules. For example, I might want all messages that come from usin@thekleimans.com to go into a "diplomacy" folder, and then I might want to apply a special set of filters to those messages, so that ones with "from I" in the subject are marked green, ones with "to M" are marked as urgent, a sound is played whenever one arrives that says "Results" in the subject, and so on and so forth. Yes, loops have to be watched for, probably by calling the filters recursively with a list of folders that have already filtered it. Pegasus Mail does this when the folder is _opened_, rather than when the message is placed there, but I think that if the infinite loop problem can be avoided doing it when the message is filed into the folder is better. * Whenever a folder is closed by the user. (Could also be when Mail/News is exited, but I prefer the folder-closed approach because it can happen asynchronously while other stuff is being read.) This is useful for allowing messages that have been read already to be archived to another folder, or for allowing messages that match certain patterns to remain in a folder for only a certain amount of time, then being archived off. Pegasus Mail does this, and it's handy for mailing lists, to archive off messages more than n days old to a separate folder whether they are read or not. There may even be some categories of messages that the user wants to see in the inbox _once_, and have them pass elsewhere afterword whether they have been read or not. (I used to do that with one mailing list.) * When an outgoing message is sent. Pegasus Mail does this, and it is useful for placing outgoing messages that match certain patterns into different folders. Gnus handles this functionality differently, by allowing groups to be customised so that messages created in them have certain default headers, including the Gcc pseudoheader (which controls where a copy is filed), which the user can then edit on a per-message basis before sending if desired. All of this only covers _when_ filters can be triggered; the question of _what_ triggered filters are capable of doing to a message would be a separate bug (or numerous separate bugs, perhaps).

it would be nice to have filtering enabled for local folders as well

I believe this old bug (as reported) is WFM. We do support filtering after the fact now, and also message aging (not as a filter though). Filters per folder is bug 294632.