How does one mark all messages as read (imap4flag "seen") with sieve?
Hello!
I had hoped that marking all messages that arrive to a specific mailbox as read/seen would be as simple as applying the following sieve script to all incoming mail for that mailbox user:
######################## require ["imap4flags"]; addflag "\\Seen"; ########################
With this script in-place, mail does not appear to be marked as read/seen. It arrives as it normally would, and my email client sees it as new mail.
Is something more required? Or is it a bug/limitation in my email client?
I've found many examples of "addflag "\\Seen";" on the web, but all of them are wrapped in conditional logic of some variety. This is a spam-training mailbox and I simply want everything marked as seen/read upon arrival so I'm not bothered/notified every time.
Thanks for any pointers here!
-Ben
On 11/3/2016 10:07 PM, Ben Johnson wrote:
Hello!
I had hoped that marking all messages that arrive to a specific mailbox as read/seen would be as simple as applying the following sieve script to all incoming mail for that mailbox user:
######################## require ["imap4flags"]; addflag "\\Seen"; ########################
With this script in-place, mail does not appear to be marked as read/seen. It arrives as it normally would, and my email client sees it as new mail.
Is something more required? Or is it a bug/limitation in my email client?
I've found many examples of "addflag "\\Seen";" on the web, but all of them are wrapped in conditional logic of some variety. This is a spam-training mailbox and I simply want everything marked as seen/read upon arrival so I'm not bothered/notified every time.
Thanks for any pointers here!
-Ben
I had the afterthought that perhaps the problem is that my Antispam plugin pipe-script simply writes the original message to the filesystem. It doesn't use dovecot-lda, so the Sieve filters are not being applied.
I would use dovecot-lda if it didn't sefault with my pipe script. :(
Will just have to live with making messages read manually, I suppose!
-Ben
could your script be modified to use LMTP?
On Sat, Nov 5, 2016 at 12:01 PM, Ben Johnson <ben@indietorrent.org> wrote:
On 11/3/2016 10:07 PM, Ben Johnson wrote:
Hello!
I had hoped that marking all messages that arrive to a specific mailbox as read/seen would be as simple as applying the following sieve script to all incoming mail for that mailbox user:
######################## require ["imap4flags"]; addflag "\\Seen"; ########################
With this script in-place, mail does not appear to be marked as read/seen. It arrives as it normally would, and my email client sees it as new mail.
Is something more required? Or is it a bug/limitation in my email client?
I've found many examples of "addflag "\\Seen";" on the web, but all of them are wrapped in conditional logic of some variety. This is a spam-training mailbox and I simply want everything marked as seen/read upon arrival so I'm not bothered/notified every time.
Thanks for any pointers here!
-Ben
I had the afterthought that perhaps the problem is that my Antispam plugin pipe-script simply writes the original message to the filesystem. It doesn't use dovecot-lda, so the Sieve filters are not being applied.
I would use dovecot-lda if it didn't sefault with my pipe script. :(
Will just have to live with making messages read manually, I suppose!
-Ben
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx@gmail.com US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
On 11/5/2016 1:03 PM, Larry Rosenman wrote:
could your script be modified to use LMTP?
That's a very interesting suggestion. Thanks, Larry!
My gut feeling is that it will crash (segfault and core-dump) in the same way that dovecot-lda does, but it's worth a shot!
(I've posted about my woes with the dovecot-lda crashing issue many times here... nobody seems to have any other ideas. Wish there was an official bug-tracker.)
I'll give it a shot and report back!
-Ben
What OS/MTA are you using? Can you give me (privately if you want) a re-hash of the LDA issues?
I'm using FreeBSD 10.3 / Exim for my set up and LMTP for ALL deliveries, and it works great.
On Sat, Nov 5, 2016 at 12:06 PM, Ben Johnson <ben@indietorrent.org> wrote:
On 11/5/2016 1:03 PM, Larry Rosenman wrote:
could your script be modified to use LMTP?
That's a very interesting suggestion. Thanks, Larry!
My gut feeling is that it will crash (segfault and core-dump) in the same way that dovecot-lda does, but it's worth a shot!
(I've posted about my woes with the dovecot-lda crashing issue many times here... nobody seems to have any other ideas. Wish there was an official bug-tracker.)
I'll give it a shot and report back!
-Ben
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx@gmail.com US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
On 11/5/2016 1:22 PM, Larry Rosenman wrote:
What OS/MTA are you using? Can you give me (privately if you want) a re-hash of the LDA issues?
I'm using FreeBSD 10.3 / Exim for my set up and LMTP for ALL deliveries, and it works great.
Thanks again for your willingness to help with this, Larry.
I'm using Postfix.
Regarding the OS, I'm using Ubuntu 16.04 here, which ships dovecot 2.2.22 at present.
---- Slightly off-topic, but I'll bring it full-circle... ----
Sure, a quick recap of the crashing issue I'm having with dovecot-lda:
I struggled to get this working the first time (in dovecot 2.0.19), but prevailed with lots of help from this list. I described the roadblocks I encountered along the way in this thread:
http://www.dovecot.org/list/dovecot/2013-June/091018.html
All was well until I upgraded from Ubuntu 12.04 LTS to 14.04 LTS and thereby from Dovecot 2.0.19 to 2.2.9. To be clear (and it may be very relevant), this was a "manual" server migration and not an OS-level/package-managed upgrade. Point being, the potential to botch some aspect of the extremely fragile configuration was absolutely present!
I wrote about the problems I encountered after the upgrade here:
http://www.dovecot.org/list/dovecot/2014-July/097234.html
The thread died-out, but I rekindled it here:
http://www.dovecot.org/list/dovecot/2014-August/097385.html
I ran out of steam after a soft dead-end.
I wrote more about it a couple months later, mostly in the context of difficulty with dovecot-lda logging in an effort to debug the issue, but the thread received no replies:
http://www.dovecot.org/list/dovecot/2014-October/098127.html
Nearly two years later, I tried again:
http://www.dovecot.org/list/dovecot/2016-August/105221.html
The thread received some traction, and I changed the subject line to be more accurate partway through, which begins here:
http://www.dovecot.org/list/dovecot/2016-August/105236.html
I ended-up running with Karol's final suggestion, which was to forego the LDA in favor of a simple filesystem move/copy operation.
But now the problem I'm having (to bring it full circle!) is that I can't mark the Antispam plugin's incoming emails as seen/read automatically because they aren't delivered by an LDA. And I want to get this working with an LDA again for this reason, among others, such as quotas not being enforced when a "trained" message is "copied" on the filesystem instead of "delivered" via an LDA.
The more I think about this, the more I think I should go back and study the very first thread from June, 2013... maybe the solution is more or less the same!
-Ben
so to summarize: postfix (what version?) dovecot-antispam plugin (version? Installed from where?)
and when your script invokes deliver you get a core dump. Have you a stack-trace from that coredump?
On Wed, Nov 9, 2016 at 5:49 PM, Ben Johnson <ben@indietorrent.org> wrote:
On 11/5/2016 1:22 PM, Larry Rosenman wrote:
What OS/MTA are you using? Can you give me (privately if you want) a re-hash of the LDA issues?
I'm using FreeBSD 10.3 / Exim for my set up and LMTP for ALL deliveries, and it works great.
Thanks again for your willingness to help with this, Larry.
I'm using Postfix.
Regarding the OS, I'm using Ubuntu 16.04 here, which ships dovecot 2.2.22 at present.
---- Slightly off-topic, but I'll bring it full-circle... ----
Sure, a quick recap of the crashing issue I'm having with dovecot-lda:
I struggled to get this working the first time (in dovecot 2.0.19), but prevailed with lots of help from this list. I described the roadblocks I encountered along the way in this thread:
http://www.dovecot.org/list/dovecot/2013-June/091018.html
All was well until I upgraded from Ubuntu 12.04 LTS to 14.04 LTS and thereby from Dovecot 2.0.19 to 2.2.9. To be clear (and it may be very relevant), this was a "manual" server migration and not an OS-level/package-managed upgrade. Point being, the potential to botch some aspect of the extremely fragile configuration was absolutely present!
I wrote about the problems I encountered after the upgrade here:
http://www.dovecot.org/list/dovecot/2014-July/097234.html
The thread died-out, but I rekindled it here:
http://www.dovecot.org/list/dovecot/2014-August/097385.html
I ran out of steam after a soft dead-end.
I wrote more about it a couple months later, mostly in the context of difficulty with dovecot-lda logging in an effort to debug the issue, but the thread received no replies:
http://www.dovecot.org/list/dovecot/2014-October/098127.html
Nearly two years later, I tried again:
http://www.dovecot.org/list/dovecot/2016-August/105221.html
The thread received some traction, and I changed the subject line to be more accurate partway through, which begins here:
http://www.dovecot.org/list/dovecot/2016-August/105236.html
I ended-up running with Karol's final suggestion, which was to forego the LDA in favor of a simple filesystem move/copy operation.
But now the problem I'm having (to bring it full circle!) is that I can't mark the Antispam plugin's incoming emails as seen/read automatically because they aren't delivered by an LDA. And I want to get this working with an LDA again for this reason, among others, such as quotas not being enforced when a "trained" message is "copied" on the filesystem instead of "delivered" via an LDA.
The more I think about this, the more I think I should go back and study the very first thread from June, 2013... maybe the solution is more or less the same!
-Ben
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx@gmail.com US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
On 11/9/2016 7:04 PM, Larry Rosenman wrote:
so to summarize: postfix (what version?) dovecot-antispam plugin (version? Installed from where?)
and when your script invokes deliver you get a core dump. Have you a stack-trace from that coredump?
Yes, that summarizes it!
Postfix version 3.1.0 (installed from Ubuntu 16.04 repos.
Antispam plugin version 2.0+20150222-1build1, also installed from Ubuntu 16.04 repos.
Regarding a stack-trace, I forgot to mention that I ran into roadblocks with that, too (the "average end-user doesn't have a chance!), as described at
http://www.dovecot.org/list/dovecot/2016-September/105417.html
and no one was willing and able to offer assistance.
I persisted in the thread at
http://www.dovecot.org/list/dovecot/2016-September/105422.html
which dead-ended eventually with the stack-trace posted here:
Thanks again,
-Ben
looks to me from the coredump (although you pointed to the wrong binary) that deliver was PANIC()'ing with
io_add(0x%x) called twice fd=%d, callback=%p -> %p
I'm not sure what that message means, but maybe one of the dovecot folks does.
Are all the packages built together?
Are you averse to compiling stuff yourself?
On Wed, Nov 9, 2016 at 6:25 PM, Ben Johnson <ben@indietorrent.org> wrote:
On 11/9/2016 7:04 PM, Larry Rosenman wrote:
so to summarize: postfix (what version?) dovecot-antispam plugin (version? Installed from where?)
and when your script invokes deliver you get a core dump. Have you a stack-trace from that coredump?
Yes, that summarizes it!
Postfix version 3.1.0 (installed from Ubuntu 16.04 repos.
Antispam plugin version 2.0+20150222-1build1, also installed from Ubuntu 16.04 repos.
Regarding a stack-trace, I forgot to mention that I ran into roadblocks with that, too (the "average end-user doesn't have a chance!), as described at
http://www.dovecot.org/list/dovecot/2016-September/105417.html
and no one was willing and able to offer assistance.
I persisted in the thread at
http://www.dovecot.org/list/dovecot/2016-September/105422.html
which dead-ended eventually with the stack-trace posted here:
Thanks again,
-Ben
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: larryrtx@gmail.com US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
I don't use the Anti-Spam plugin; I just fire off a BASH script every four hours with crontab which iterates thru the vmail email accounts and trains Spamassassin 'per-user' accounts. If the script sounds interesting I can post it here. It probably could use a little polish though.
Bill
On 11/9/2016 6:49 PM, Ben Johnson wrote:
On 11/5/2016 1:22 PM, Larry Rosenman wrote:
What OS/MTA are you using? Can you give me (privately if you want) a re-hash of the LDA issues?
I'm using FreeBSD 10.3 / Exim for my set up and LMTP for ALL deliveries, and it works great. Thanks again for your willingness to help with this, Larry.
I'm using Postfix.
Regarding the OS, I'm using Ubuntu 16.04 here, which ships dovecot 2.2.22 at present.
---- Slightly off-topic, but I'll bring it full-circle... ----
Sure, a quick recap of the crashing issue I'm having with dovecot-lda:
I struggled to get this working the first time (in dovecot 2.0.19), but prevailed with lots of help from this list. I described the roadblocks I encountered along the way in this thread:
http://www.dovecot.org/list/dovecot/2013-June/091018.html
All was well until I upgraded from Ubuntu 12.04 LTS to 14.04 LTS and thereby from Dovecot 2.0.19 to 2.2.9. To be clear (and it may be very relevant), this was a "manual" server migration and not an OS-level/package-managed upgrade. Point being, the potential to botch some aspect of the extremely fragile configuration was absolutely present!
I wrote about the problems I encountered after the upgrade here:
http://www.dovecot.org/list/dovecot/2014-July/097234.html
The thread died-out, but I rekindled it here:
http://www.dovecot.org/list/dovecot/2014-August/097385.html
I ran out of steam after a soft dead-end.
I wrote more about it a couple months later, mostly in the context of difficulty with dovecot-lda logging in an effort to debug the issue, but the thread received no replies:
http://www.dovecot.org/list/dovecot/2014-October/098127.html
Nearly two years later, I tried again:
http://www.dovecot.org/list/dovecot/2016-August/105221.html
The thread received some traction, and I changed the subject line to be more accurate partway through, which begins here:
http://www.dovecot.org/list/dovecot/2016-August/105236.html
I ended-up running with Karol's final suggestion, which was to forego the LDA in favor of a simple filesystem move/copy operation.
But now the problem I'm having (to bring it full circle!) is that I can't mark the Antispam plugin's incoming emails as seen/read automatically because they aren't delivered by an LDA. And I want to get this working with an LDA again for this reason, among others, such as quotas not being enforced when a "trained" message is "copied" on the filesystem instead of "delivered" via an LDA.
The more I think about this, the more I think I should go back and study the very first thread from June, 2013... maybe the solution is more or less the same!
-Ben
On 11/10/2016 3:46 AM, Bill Shirley wrote:
I don't use the Anti-Spam plugin; I just fire off a BASH script every four hours with crontab which iterates thru the vmail email accounts and trains Spamassassin 'per-user' accounts. If the script sounds interesting I can post it here. It probably could use a little polish though.
Bill
Thanks, Bill!
Sure, please do share the script, if it's not too much trouble.
For my specific use-case, I've been maintaining a "corpus" of known ham/spam messages, and enjoy being able to hand classify/re-classify/ignore if necessary.
But I do see the appeal of training with a single script that iterates through each user's mailbox.
Heretofore, my thinking has been that combining all "submitted" spam, which is piped into the training mailbox automatically, whenever a user drags from Inbox -> Spam (or vice versa), I have a much broader sample of the the ham and spam out there.
And yes, a "shared" corpus among all users does seem to "dilute" specific individuals' would-be training preferences a bit, but the trade-off seems worthwhile.
Interesting quandary... I would love to see the script! No problem if it's a bit "rough around the edges"; the overall concept and approach are what's important to me.
-Ben
This one is for vmail which is attached.
Bill
On 11/10/2016 8:29 PM, Ben Johnson wrote:
On 11/10/2016 3:46 AM, Bill Shirley wrote:
I don't use the Anti-Spam plugin; I just fire off a BASH script every four hours with crontab which iterates thru the vmail email accounts and trains Spamassassin 'per-user' accounts. If the script sounds interesting I can post it here. It probably could use a little polish though.
Bill Thanks, Bill!
Sure, please do share the script, if it's not too much trouble.
For my specific use-case, I've been maintaining a "corpus" of known ham/spam messages, and enjoy being able to hand classify/re-classify/ignore if necessary.
But I do see the appeal of training with a single script that iterates through each user's mailbox.
Heretofore, my thinking has been that combining all "submitted" spam, which is piped into the training mailbox automatically, whenever a user drags from Inbox -> Spam (or vice versa), I have a much broader sample of the the ham and spam out there.
And yes, a "shared" corpus among all users does seem to "dilute" specific individuals' would-be training preferences a bit, but the trade-off seems worthwhile.
Interesting quandary... I would love to see the script! No problem if it's a bit "rough around the edges"; the overall concept and approach are what's important to me.
-Ben
participants (3)
-
Ben Johnson
-
Bill Shirley
-
Larry Rosenman