Skip to content

Reply by Email broken when not using sub-addressing

Summary

We use Microsoft Exchange for our email provider which does not support email sub-addressing. After getting a dedicated email address to use for GitLab and getting IMAP access enabled for the address, GitLab does not properly parse the reply tag out of the message so the reply by email feature never works. Looking into the code, it appears to be caused by a few bugs in the code related to parsing the tag out of the References header of the reply email.

Steps to reproduce

  1. Using official Docker container
  2. Configure GitLab to use Reply by email using a dedicated email inbox
  3. Test the configuration as directed in the documentation
  4. Have somebody post a comment on one of your Merge Requests, get an email about it in your email inbox
  5. Reply to email

Expected behavior

My replied comment should be properly posted to the Merge Request

Actual behavior

GitLab immediately replies to my email saying it was rejected with the message

Unfortunately, your email message to GitLab could not be processed.

We couldn't figure out what the email is for. Please create your issue or comment through the web interface.

I see this behavior on the official GitLab EE Docker Container.

Relevant logs and/or screenshots

Nothing interesting found in any logs.

Output of checks

Results of GitLab application Check

application_check.log

Results of GitLab environment info

env_check.log

Possible fixes

Given an email with references like this:

References: <merge_request_13@gitlab.example.com>
<reply-53246363f8909346dabe872581be9c90@gitlab.example.com>

When I reply, the references in the reply email are like this:

References: <merge_request_13@gitlab.example.com>
 <reply-53246363f8909346dabe872581be9c90@gitlab.example.com>,<3c3afaf6d424ec74d4b00200770cd12c@gitlab.example.com>

When this hits the code, in lib/gitlab/email/receiver.rb, the key_from_additional_headers function attempts to loop on all the entries in the References field of the email, then run the key_from_fallback_message_id function on it. However, this loop doesn't actually split the string in anyway, it just dumps the whole References field into the first entry of an array and passes that one whole string through to key_from_fallback_message_id instead of three separate <....@gitlab.example.com> entries.

Even if each entry were properly passed through, There appear to be two issues in key_from_fallback_message_id in lib/gitlab/incoming_email.rb that would still prevent this feature from working. First, the FALLBACK_MESSAGE_ID_REGEX regex doesn't match on the angle brackets in the references field, so none of them will ever match. Second the line that does the matching seems to have swapped the string to match on with the regex string.

This issue applies to both GitLab CE and GitLab EE.

I have these fixes in my fork of the gitlab-ce repository and in my fork of the gitlab-ee repository and can file Merge Requests if requested.