On 18/01/2021 18:05 Ron Garret ron@flownet.com wrote:
On Jan 17, 2021, at 11:06 PM, Aki Tuomi aki.tuomi@open-xchange.com wrote:
On 18/01/2021 08:56 Ron Garret ron@flownet.com wrote:
On Jan 17, 2021, at 10:48 PM, Aki Tuomi aki.tuomi@open-xchange.com wrote:
Don't touch the INBOX setting (leave it out), use the -m parameter for dovecot-lda.
I don’t think that will work. My MTA is postfix and it’s connected to dovecot via LMTP, so AFAIK postfix is talking to dovecot over a socket, and dovecot-lda isn’t being invoked so there is no place to pass that the -m parameter. But we are at the limits of my understanding of how all this stuff actually works under the hood so please correct me if I’m wrong here.
rg
Ah, you are using LMTP... then the easiest is to use Sieve here.
I was afraid of that :-(
What about just using postfix as the LDA?
You can use simple global script, e.g. /etc/dovecot/default-mbox.sieve
require ["fileinto", "mailbox"]; fileinto "OtherBox";then sievec the script, and use
plugin { sieve_before = /etc/dovecot/default-mbox.sieve }
this way it will change the default mailbox, but allows per-user scripts to change it.
The problem is that the spam filter needs to put good messages back in INBOX. That would cause an infinite loop (unless sieve has a mechanism to prevent this that I don’t know about). So to prevent this I’d need to make the rule conditional on some header that the spam filter adds before moving the message back. The problem with *that* is that it plays badly with the strategy for training the filter, which is for the user to move false-positive messages from SPAM to INBOX. A user might then also move a good message from OtherBox to INBOX rather than wait for the spam filter to get around to processing it, and then sieve would (presumably) move it right back. So now I need *another* header that *sieve* adds before moving the message to OtherBox and make the rule conditional on *that* header. It all starts to seem very complicated and fragile.
rg
How about using IMAP Sieve for Spam filter training? https://doc.dovecot.org/configuration_manual/howto/antispam_with_sieve/
Also, sieve rules are processed during Delivery (lmtp or lda), not if users or spam filters move messages around. IMAP sieve is different thing, and needs to be separately configured. Not sure what "infinite loop" you are seeing here?
Aki