Comment on issues/MRs/notes by replying to their notification email
Suppose you receive a notification email for a new issue, MR or comment. Suppose you're on your phone. Suppose you would like to comment on it.
- Read notification
- Click "View it on GitLab" link
- Log in if not already logged in (which may involve cumbersome stuff like 1Password, OAuth, LDAP)
- Reorient to the new page
- Enter comment (struggling with the small text area)
- Save comment
- Close tab to keep Mobile Safari snappy
- Read notification
- Hit Reply
- Enter comment as email reply
- Send message
DesiredFlow.steps.count < CurrentFlow.steps.count
We can't intercept incoming email at the SMTP level (like Mailgun's Inbound Routing does), because we don't (and can't ask to) control the GitLab server's email infrastructure.
We can, however, get the GitLab server admin to set up a special email address within their existing infrastructure, and then have a process on the GitLab server log in and listen on this IMAP box for new incoming email, and accomplish the same thing.
What we need
We need to know 2 things about incoming email:
- To what issue/MR/commit is this meant to be a comment?
- What user is authoring this comment?
Fact 1, we can acquire easily.
We can set a
Message-ID header of something like
email@example.com on the original issue notification (GitLab already does this!), and
firstname.lastname@example.org on follow-up comment notifications.
When replying, mail user agents copy this value into the
References headers for the new email. These are customarily used for threading email, but are perfect for us to identify the issue an incoming email concerns.
Note that Amazon SES, which is used by dev.gitlab.org and probably others, inexplicably strips the Message-ID from mails sent through them. We can, however, get this back and add this to a database table to dereference later.
Fact 2, is a little bit harder to get to.
We can't simply go off of the
From email, because this can easily be spoofed, and may not be in our system anyway (suppose the user has automatic forwarding setup from their notification email to another).
The way this problem is usually solved, is by assigning a disposable, unique "Reply-To" email to sent notifications, so when the user replies and this message is caught in a catch-all mailbox on the server, the "To" address can be used to uniquely identify who originally received this email. An example disposable email from GitHub reads
Unfortunately, this is not an option for us, since we can't ask the GitLab server admin to set up a dedicated domain and catch-all email box, and we can't have this feature rely on the customer using Gmail/Google Apps, which support
email@example.com disposable email addresses.
Another option would be to still generate a uniquely identifying "comment access token", but embed this in the
Message-ID rather than the
Reply-To address. This is dangerous however, because some mail clients include this value in forwarded email as well, which would give the recipient of your forward access to your access token, and thus the ability to reply under your name. (The
Reply-To address is never sent along with forwards). This same problem exists with adding a token to the subject, the body or any other header (besides
Reply-To... which we can't use).
We could mostly remedy the issue by using a single-purpose token, that allows the user only to access to comment on this particular object, and not any other.
I think is feature would be extremely useful, and I think the risk posed by the single-purpose access token leaking via a forwarded email is small enough to not stand in its way.