On 11 Jun 2021, at 07:54, Daniel J. Luke dluke@geeklair.net wrote:
On Jun 11, 2021, at 3:51 AM, Vincent Brillault vincent.brillault@cern.ch wrote:
It then falls through my personal sieve filter and hits the implicit keep at the end and ends up in my inbox - with the original headers.
I had a similar issue recently (with addheader, not deleteheader) and I was pointed to the RFC: https://datatracker.ietf.org/doc/html/rfc5293#section-5
The deleteheader action does not affect Sieve's implicit keep.```
I haven't gone over the RFCs with a fine toothed comb, but having implicit and explicit keep with different behaviors is surprising.
Agreed. And I think we all hit this.
My addheader case was solved by adding an explicit keep or a fileinto.
I added a keep; to then end of my before.sieve and it doesn't change the behavior (with or without the deleteheaders I always see the other hosts X-Spam headers in the delivered mail).
Are you sure the message you are seeing is being processed by your before.sieve? Os there any evidence at all in the mail that it was hit sieve?
For example, one of my sieve_before
# cat /usr/lib/dovecot/sieve/filespam.sieve require ["fileinto", "imap4flags"];
if header :contains "X-spam-flag" "YES" { fileinto :flags "\Seen" "Junk"; }
I know that sieve fires because messages marked as spam are tied into the user's Junk mail.
You know that the sieve_before scripts are run AS THE USER, not as dovecot or root, right? I mention this because it was something that caught me out.
-- Growing up leads to growing old, and then to dying/And dying to me don't sound like all that much fun.