Gmailctl – Declarative Configuration for Gmail Filters

This is interesting; what benefit&#x2F;advantage does it have over IMAP-level email management tools like imapfilter[1]?<p>I don&#x27;t ask that to be confrontational; I&#x27;ve successfully managed several email inboxes on several different providers for years with plain old IMAP rules, so I&#x27;d like to know if there&#x27;s anything I&#x27;m missing.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;lefcha&#x2F;imapfilter" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lefcha&#x2F;imapfilter</a>

I made something like this a while back for myself, and it worked all right, but I ended up never even using it myself. The main problems I had were:<p>- You end up with multiple sources of truth for what&#x27;s happening to your email. And&#x2F;or you won&#x27;t be able to easily edit your filters from multiple machines.<p>- Either the source code or the generated code ends up being hard to read.<p>- There&#x27;s imperative (and sometimes counterintuitive) behavior in Gmail regarding labels, and that can interfere with declarative reasoning.<p>- Filters have a size limit! So you might need to take that into account if you have complicated filters.

Huge respect to the author for ealizing this - however, I&#x27;m honestly sceptical of including yet another turing-complete configuration DSL without sufficient debugging capabilities.<p>Seems to me, now you&#x27;ve added several more sources of complexity:<p>- You have to get the JSONnet syntax right and learn about th various functionalities and expressions.<p>- You have to ensure Jsonnet is correctly translated into the GMail filter chain.<p>- You <i>still</i> have to ensure the GMail filter chain works correctly - this is one of the original problems this project set out to solve, but I don&#x27;t understand what additional tools the project gives you to archieve this.

I use something like this that a Googler shared with me.<p>It&#x27;s super helpful to get around the way Gmail doesn&#x27;t really let you order rules.<p>This helps you generate mutually exclusive rules, so the ordering doesn&#x27;t matter.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;mbrt&#x2F;gmailctl&#x2F;blob&#x2F;master&#x2F;README.md#chain-filtering" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mbrt&#x2F;gmailctl&#x2F;blob&#x2F;master&#x2F;README.md#chain...</a>

The real benefit Gmail has over most other email solutions, including Outlook, is labels for emails which are like virtual mailboxes. Almost all IMAP-based solutions I&#x27;ve seen don&#x27;t attempt to solve this problem, which is why people keep using Gmail. If something like this was automated through Dovecot, people would be much more likely to host there own email.

That&#x27;s a pretty awesome project! I wrote something to automate label manipulation too, but I used a simple scripting language.<p>I migrated from self-hosted mail where I had the power of procmail, to gsuite, where I had less flexibility. Making simple filters via the google UI is easy, but it gets complicated when you want to look at both the subject and the sender - to file &quot;Facebook comment replies&quot;, &quot;Facebook messages&quot;, and &quot;Facebook event invitations&quot; under different labels for example.<p>It&#x27;s a pain to authenticate, but once that&#x27;s done I like my solution. Downside is you need to run it under cron:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;skx&#x2F;labeller&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;skx&#x2F;labeller&#x2F;</a><p>The appeal of this gmailctl is that it keeps everything native, and doesn&#x27;t require a server to run a cronjob. Nice work.

I wonder if a terraform provider for gmail would make sense.

If the author comes along, are there any plans to support FastMail for those of us who don’t use Gmail? I’d be willing to pay a bounty.

Nice tool. Pretty popular at my workplace.

F### GMail.