Skip to content
Snippets Groups Projects

Comment on issues/MRs/notes by replying to their notification email

The problem

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.

Current flow:

  • 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

Desired flow:

  • Read notification
  • Hit Reply
  • Enter comment as email reply
  • Send message

DesiredFlow.steps.count < CurrentFlow.steps.count

The solution

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:

  1. To what issue/MR/commit is this meant to be a comment?
  2. What user is authoring this comment?

Fact 1, we can acquire easily.

We can set a Message-ID header of something like gitlab-org/gitlab-ce/issues/123@gitlab.com on the original issue notification (GitLab already does this!), and gitlab-org/gitlab-ce/issues/123/notes/345@gitlab.com on follow-up comment notifications.

When replying, mail user agents copy this value into the In-Reply-To and 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 reply+00026ecab27203...@reply.github.com.

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 username+whatever_you_want@gmail.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.

Conclusion

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.