Re: Tribulations trying to pin-down viable sieve script constraints in connection with imap events.

Op 9-8-2026 om 23:24 schreef sjh_dovecot_org--- via dovecot:
> Hi Aki... Thanks for the link  - I had read that page in connection with Option 1.  The /etc/dovecot/sieve/report-ham.sieve script it proposes is easily modified to exclude training for for ham if emails are moved from the root Spam folder to some more-specific spam folder - e.g. Spam.2026.June as well as 'Trash'.
>
> The /etc/dovecot/sieve/report-spam.sieve script is less easily adjusted so as not to train (again) as spam if an email is moved from Spam.2026.June back to Spam.  If it were feasible to discover the source folder for emails copied/moved into Spam in that script, I could easily adapt it to meet my requirements.  If I take the approach that moving to a folder (c.f. applying a tag) is how I am going to control training... then the example it provides is 99% complete for my purposes.  The only niggle with it, for me, is that it assumes only one Spam folder - whereas I have many (nested) Spam folders.
>
> While I may ultimately adopt a strategy focused upon moving messages to particular folders... Dovecot (and the relevant RFCs) suggest that driving actions when messages are tagged in specific ways (rather than only when moving messages to/from specific folders) should also be fully supported.  It just doesn't seem to work.. it looks as if the hasflag feature's results are inconsistent with flags events notified by imap.changedflags.

These are apparently currently not documented at doc.dovecot.org:

https://github.com/dovecot/pigeonhole/blob/96fe62fe9d1530ef9de584e30571b520d7860f8a/doc/plugins/imapsieve.txt#L26

Regards,

Stephan.

_______________________________________________
dovecot mailing list -- [email protected]
To unsubscribe send an email to [email protected]