Mailspring: Mail rules are not always applied
What operating system are you using?
Linux Mint 18.3
What version of Mailspring are you using?
1.1.2
Bug?
Do you have any third-party plugins installed? If so, which ones?
No.
Is the issue related to a specific email provider (Gmail, Exchange, etc.)?
Possibly Davmail + Exchange.
I have mail rule set up as seen on the attached screenshot.
It seems to be applied very inconsistently. Some emails fitting the rules are moved automatically, some are not. I have no idea how is this decided.
raqua
All 29 comments
This also happens to me on Ubuntu 16.04. The rules are valid because the messages are filtered when I "Process entire inbox".
I'm using 1.1.3 with no additional plugins.
Pinchanzee
on 9 Feb 2018
Same for me on Manjaro. The rules are valid because the messages are filtered when I "Process entire inbox".
I'm using 1.1.4 with no additional plugins.
My hoster is mail.ru.
Tamriel
on 20 Feb 2018
I think it might just be the 'Move Messages' action that's not working. When I have rules with both 'Move Messages' and 'Mark as Read', it does the 'Mark as Read' action automatically, just not the move.
Pinchanzee
on 27 Feb 2018
Same for me, with an IMAP standard account, still having this issue on version 1.1.4
domenico-ruggiano
on 27 Feb 2018
Same for me, on an IMAP account, Mailspring 1.1.4 on Windows - messages are not moved unless mail rules applied via "Process entire inbox".
jo-chemla
on 8 Mar 2018
Is this some sort of obscure feature? I see the text "One message in this thread is hidden because it was moved to trash or spam" which could potentially explain why it's still in my inbox.. But why would I want something I'm explicitly marking trash or junk in my inbox at all? If I check my Trash, it is in there, and it has been read, so the mail rule has been applied, but there's still that copy in my inbox which I obviously don't want.
Again, it's removed when I "Process entire inbox".
Pinchanzee
on 9 Mar 2018
+1 for this issue, currently this is the only thing preventing me from replacing thunderbird with mailspring
giedriusStan
on 14 Mar 2018
I get the same thing, but it's not consistent. Sometimes mail is moved properly, other times it just fills my inbox.
Is there any way to set a keyboard shortcut to process the inbox? That would make this problem slightly less annoying.
adolson
on 3 Apr 2018
+1 for this issue, Same here, I am using 1.2.1 on Ubuntu 17.10.
EniasCailliau
on 13 Apr 2018
+1 for this issue, installed via snapd on Linux Mint 18.3
regnerisch
on 7 May 2018
+1 for this issue: on my ubuntu 16.04 it seems to move messages only when the main application panel is open; if it runs in background or has been closed, messages wont be moved automatically
giovazz89
on 6 Jun 2018
+1 for this issue
- another issue when the client runs in the background and not open/minimized, the blue dot for new messages on the tray icon doesn't appear .It appears only when the client is open or minimized.
this is on ubuntu 16.04
nikolayanchev
on 14 Jun 2018
+1 for this issue, on ubuntu 18.04, tried installing both via snap and .deb, v1.4.2
PrimarchAlpharius
on 2 Sep 2018
+1 for this issue, on Linux Mint 19.0 Cinnamon.
brandonp2412
on 13 Sep 2018
+1 for this issue, on Linux 4.18.7-arch1-1-ARCH x86_64 GNU/Linux
Jens0512
on 22 Sep 2018
Same here, mint 18 on Cinnamon +1 for the shortCut
intrazik
on 15 Oct 2018
Any idea at all what could be causing this?
jotaf98
on 13 Nov 2018
+1 for this issue, on Fedora 29
korotindev
on 22 Nov 2018
@bengotow anyway to tag this as a bug, mark as a linux issue, and have it prioritized for a fix?
ElementalWarrior
on 29 Nov 2018
+1 for this issue on Ubuntu 18.04
oddjobz
on 15 Dec 2018
Same here. Switching to back Thunderbird.
johanneskoester
on 12 Feb 2019
Also switched to Thunderbird because of this
Jens0512
on 12 Feb 2019
+1 for this issue on Ubuntu 18.04
MohamedKhelifi
on 27 Feb 2019
Hey folks! Sorry for the delay on this one - I believe this will be fixed in the next release, just testing the patch now. A while back, some code was added to ensure that mail rules would only run once when the message was synced and not repeatedly when it was viewed, marked as read, etc.
This code checked a version bit and made sure that the "version" of the object in the local database was 1. Higher than 1? Must have already run mail rules.
This used to be a valid assumption. (It was always a hack, but it was a very small efficient hack we all agreed was best at some point.. 🤷♂️) However, the new C++ sync engine now pulls down messages and their bodies separately for a better user experience, and it debounces updates sent to the JavaScript application so that the UI doesn't get flooded with changes as the mail is synced. This means that 1) mail rules that require the message body don't always work, since it might not be there yet and 2) in some cases, the message is created and updated with it's body so fast that version 1 of the message object is never handed to the JavaScript app - it goes straight to version 2 and mail rules are not run.
In the next release, the C++ sync engine will explicitly emit an event to the JS application indicating it's finished fetching the message AND it's body and then mail rules will run on that message. This does mean that in some cases mail rules will be delayed by a second or two more (since we're waiting for the message bodies rather than running the rules as soon as the message hits the inbox.) I think this is a worthwhile tradeoff though - a lot of future mail rules we could implement (like attachment / custom header tests, message language tests, etc.) that would be super cool would require the full message.
Stay tuned!
bengotow
on 25 Mar 2019
What operating system are you using?
macOS 10.14.4
What version of Mailspring are you using?
1.6.1
Bug?
Yes.
Do you have any third-party plugins installed? If so, which ones?
No.
Is the issue related to a specific email provider (Gmail, Exchange, etc.)?
I currently only have mail rules defined for iCloud.
1.6.1 does not fix this issue for me.
They will not run on messages as they are downloaded. They only run when manually triggered from the Preferences view.
quixoticraindrp
on 9 Apr 2019
Closing after inactivity
bengotow
on 17 Feb 2020
But is it fixed?
regnerisch
on 18 Feb 2020
I observed this for now.
jizongFox
on 26 Mar 2020
It's not fixed, @bengotow it still happens with 1.7.8 and it's also a move rule. If I hit process inbox it does what it's supposed to do but does not act on incoming email.
working-name
on 15 Nov 2020
Related issues
jerry79
·
3Comments
KristerV
·
3Comments
k4rli
·
3Comments
enoversum
·
3Comments
scooby
·
3Comments
Most helpful comment
Hey folks! Sorry for the delay on this one - I believe this will be fixed in the next release, just testing the patch now. A while back, some code was added to ensure that mail rules would only run once when the message was synced and not repeatedly when it was viewed, marked as read, etc.
This code checked a version bit and made sure that the "version" of the object in the local database was
1. Higher than 1? Must have already run mail rules.This used to be a valid assumption. (It was always a hack, but it was a very small efficient hack we all agreed was best at some point.. 🤷♂️) However, the new C++ sync engine now pulls down messages and their bodies separately for a better user experience, and it debounces updates sent to the JavaScript application so that the UI doesn't get flooded with changes as the mail is synced. This means that 1) mail rules that require the message body don't always work, since it might not be there yet and 2) in some cases, the message is created and updated with it's body so fast that version 1 of the message object is never handed to the JavaScript app - it goes straight to version 2 and mail rules are not run.
In the next release, the C++ sync engine will explicitly emit an event to the JS application indicating it's finished fetching the message AND it's body and then mail rules will run on that message. This does mean that in some cases mail rules will be delayed by a second or two more (since we're waiting for the message bodies rather than running the rules as soon as the message hits the inbox.) I think this is a worthwhile tradeoff though - a lot of future mail rules we could implement (like attachment / custom header tests, message language tests, etc.) that would be super cool would require the full message.
Stay tuned!