Writing custom sieve plugins and extensions
I am a pretty heavy user of Sieve, and one of the services where I have extensive Sieve scripts is Protonmail. For my own mailserver setup, Dovecot's sieve-test has been excellent. I have a library of example email messages, and my own tooling setup for being able to test whether a given change has broken anything else unintentionally. If it does, I can trace the decision tree.
With protonmail this has severe limitations. Most of those scripts apply expire, and what the expire is can change as it passes through the filters. But I cannot test any of that with sieve-test because that extension is unique to them. I always have to strip it out of sieve first, and that doesn't help me understand what's happening.
I have some software engineering experience, so I was poking around at the pigeonhole source code, but since it's really focused on the RFC (understandably) there doesn't seem to be a friendly on-ramp to creating a one-off extension.
What I'd really like to do though is make some kind of custom extension to sieve-test specifically which would allow the user to define custom vendor plugins/modules and appropriate messages. After all, I don't need sieve-test to know how to expire a message, I just need it to not throw an error on the extension when it's loaded, and to inform me in the output that it would have applied the expire action to a given message with a given value.
I suspect the easiest way to do that is with a stubbed out extension that can handle that, but I'm open to other approaches that might work.
Hi Mark,
Op 5-2-2025 om 20:07 schreef Mark via dovecot:
I am a pretty heavy user of Sieve, and one of the services where I have extensive Sieve scripts is Protonmail. For my own mailserver setup, Dovecot's sieve-test has been excellent. I have a library of example email messages, and my own tooling setup for being able to test whether a given change has broken anything else unintentionally. If it does, I can trace the decision tree.
With protonmail this has severe limitations. Most of those scripts apply expire, and what the expire is can change as it passes through the filters. But I cannot test any of that with sieve-test because that extension is unique to them. I always have to strip it out of sieve first, and that doesn't help me understand what's happening.
I have some software engineering experience, so I was poking around at the pigeonhole source code, but since it's really focused on the RFC (understandably) there doesn't seem to be a friendly on-ramp to creating a one-off extension.
What I'd really like to do though is make some kind of custom extension to sieve-test specifically which would allow the user to define custom vendor plugins/modules and appropriate messages. After all, I don't need sieve-test to know how to expire a message, I just need it to not throw an error on the extension when it's loaded, and to inform me in the output that it would have applied the expire action to a given message with a given value.
I suspect the easiest way to do that is with a stubbed out extension that can handle that, but I'm open to other approaches that might work.
This should provide a starting point:
https://github.com/stephanbosch/pigeonhole-proton-compat-plugin
This complies with your need of not having Pigeonhole fail with an error. The expire/unexpire actions and expiration/hasexpiration tests also provide the expected semantics (from what I can tell from the Proton docs anyway). However, I haven't turned the expire command into a full-featured action yet, so it is not reported in the final sieve-test result as e.g. a side-effect to fileinto/keep.
Have fun!
Regards,
Stephan.
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
participants (2)
-
mb-dovecot＠mailroom.meme
-
Stephan Bosch