Rules are not processing properly, leaving matched messages in the Inbox.

I just created the following Rule, and applied it. It left many of the messages in the Inbox with running automatically or manually.

I would export and post the Rule on here, but neither of those options are a possibility (HINT!)

we find out that in current version emails with sender with spaces inside aren’t processed (e.g. ‘CustomerService@’). Can you confirm that’s your problem also? If not and you are unable to find some pattern of emails not processed, please, send us some screenshots of your situation or send me these problematic emails to [email protected] and we will try to simulate the issue.

I have am similar problem. My rules should work, when i recive the mails, but it doesn’t work properly: some mails are move to the right folder, other mails stay in the in-box. Both mails have the same content. I use Window 7 64-bit. Any idea to solve this problem?

can you please also send me these problematic emails to [email protected] (better with screenshots describing your problem) ? We will try to simulate the issue and compare the mails.

I have the same issue. The rule works some of the time and other times i have to run it manually. No obvious pattern and when i run it manually it catches all the emails it should. Don’t want to keep running it manually though.

Are you sure that they are not open simultaneously in another client/mobile/webmail? Then they will be not filtered by eM Client because they don’t have proper flag for rules processing (Recent flag).

If you are, then can you please send us email to [email protected] with the screenshot (or precise description) of rule preview, some emails that should be filtered or network communication logs* and reference to your problem (e.g. this topic)?

*You will make these logs this way: go to menu Tools->Settings->Logging and check Network communication. Then restart eM Client, try to simulate the issue and send us the logs using the same logging settings window.

I am trying to use the rules as well without any success at all. I used to have similar rules in Thunderbird and they all worked fine.

I am not sure I understand the comment above. I read my Gmail both through when at work, and with eM when at home. I also use my Droid to access Gmail.

If the mail is opened by some other way before eM Client, it won’t filter this mail.

Please send us the logs as mentioned above.

Yes but that works in Thunderbird!

I confirm the rules are working correctly IF the message is not seen by webmail first. This is a little bit annoying because I use webamil to check my private mail from work, but I use eM at home.

In that respect I prefer the way Thunderbird does it.

We plan to change eM Client filtering behavior in longer time horizon because of that.

Make it sooner than later.

I add my vote to the signficance of this problem (not processing rules on previously read messages). Will it be fixed in the 4.0 release?

I can answer my own question. No, this has not been fixed in 4.0. This is very annoying, since I usually see my mail first on my android phone and then later download it on eM. It would sure be nice to have the messages properly filed away by the Rules even if they had already been read. Can anyone advise when this can be fixed?


I can confirm that is has nothing to with being read via the web or by other means. It simply seems this problem will occur if it IMAP server.

I haven’t touch the web interface for more than a week now, I haven’t use my phone to check e-mail since I hard-reset it, and has yet to set everything up. EM Client does not process the rule that I have set for my IMAP account.

I am using imap on gmail, and in my case, the rules are properly processed if the message has NOT been previously read on another device (phone or iPad with gmail). If the message has already been read when downloaded by eM, then it just stays in the Inbox without being processed (all the rules are to file messages based on text in the subject line).

we see this too, even if \recent is set. It only filters mail that comes in when connected, not any new mail that was received while disconnected.

there’s a much worse problem though that some messages are being corrupted on move. Our server logs show FETCH, FETCH, FETCH (all body parts) then APPEND. This is AWFUL AWFUL AWFUL… means you have to download the entire message to move it… that’s what the MOVE or COPY + STORE is for.

It’s not-reinserting the MIME boundary marker properly, so any multipart messages that are moved this way are broken. The boundary marker is correctly put in the header, just not in the body, instead it puts – -- ---- This is a major problem.

I’d recommend pulling the release until it’s fixed

as it actively breaks mail in a way that is going to be extremely difficult to fix in code. I had to manually edit the files on the IMAP server to re-add the boundary marker and rebuild the mailbox index. Most customers won’t be able to do this.

I know it was eMClient did this as well, as it did the APPEND literal.

p.s. it wasn’t doing this yesterday, it only started today!!!???

messages it filtered yesterday were fine. HTH

I’m using Gmail too. The mails are not read by any other means. However, the mails has being filtered by Gmail first. I received lots of mails, so I have use a few very complex filter to arrange my Gmail with labels (folders in eM). And eM is failing to apply the rules.

After message has been received
from ‘[email protected]
and received using [email protected]
and with ‘Database Backup’ found in body or subject
move to Database

we have made some changes in rule processing and here is the fixed version: