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
- Using official Docker container
- Configure GitLab to use Reply by email using a dedicated email inbox
- Test the configuration as directed in the documentation
- Have somebody post a comment on one of your Merge Requests, get an email about it in your email inbox
- 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
Results of GitLab environment info
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.