If you’ve ever tried to use your gmail account for some sysadmin-type work (and you’re not using an external email client), you know how frustrating gmail’s threading rules are. The
Problem: prodv-vm-22 is down messages gets displayed in a separate thread from the
OK: prod-vm-22 is back up one. That’s because gmail’s clients (both web and mobile) ignore the traditional email headers used for indicating what goes where in a thread and thread purely¹ based on the
There’s a relatively easy way to work around this assuming you’re in full control of your daemons² and you’re ok with being mocked by other admins for implementing such a monstrosity.
It would seem gmail’s designers thought basing threading on just the contents of email subject lines was perfectly fine once certain exceptions were applied. The two I know of are:
Re:prefixes and their different variants.
- Ignore the
The latter of which can be used for our purposes. If you simply change an email template from generating subject lines like this:
Subject: $STATUS: $PROBLEM on $MACHINE
to something more like this:
Subject: [$STATUS] $MACHINE: $PROBLEM
you’ll get emails with titles like
[PROBLEM] sip1: Disk I/O is overloaded on sip1 and
[OK] sip1: Disk I/O is overloaded on sip1, which are as legible as the original, yet correctly threadable by any email client, including gmail.
And that’s it. Problem solved.
However, if you’re particularly desperate, this can be pushed to extremes. I know a guy who knows a guy, who wanted to get his
git-send-email-generated git repo email notifications³ displayed with gmail, so he added some simple sed magic which:
- Generates a unique subject core string for the thread and then makes all of the messages use it, while putting the original subjects inside square brackets.
- Copies the actual first line of the commit log into the first line of the email’s body. (Without that you wouldn’t be able to easily view the full log in gmail.)
The end result is an email thread going something like this:
- [GIT: admin] branch master updated: 301af7e
- [[PATCH 1/2] Differentiate between cloud and legacy vms] [GIT: admin] branch master updated: 301af7e
- [[PATCH 2/2] First line of the next commit’s log] [GIT: admin] branch master updated: 301af7e
What this does is preserve all the info that was already there for the people using traditional email clients, while allowing gmail users to also view them as intended. It also makes other admins look at you with barely hidden contempt. At least that’s what I’ve heard…
¹ Don’t quote me on this.
² If not, seek out a professional willing to help you.
³ Idea being that each git repo push to a central repository host generates an email thread consisting of a meta-email („This is an automated email from the git hooks/post-receive script.”) followed by bunch of emails (one per commit) each containing full commit log and diff. Great for giving multiple people the ability to easily track each other’s work.