Custom email: Forwarding in Microsoft Exchange using a transport rule adds forwarding target as To header

Based on #416637 (comment 1577749434)

Yes, I can see the following information:

To header is the support+[HASH]... address, but it contains also the original project specific address gitlab+project-20-issue-@... address. That might cause the problem.

From header is indeed the original sender.

I can't see any Delivered-To entry

References header consists of References: <reply-[32-CHARACTER HASH]@gitlab.com> <issue_[ISSUE_ID]@gitlab.com>

I think, the problem might be caused by having two addresses in the To header, what do you think? This is the case, since in order to forward the email to the project specific address, I use a transport rule adding the project specific address as another recipient.

I use Microsoft Exchange / Office 365, simply forwarding the email won't update the To header to the specific project address and since a Delivered-To header doesn't exist, no issue can be created at all, because Gitlab is not able to map it to a specific project. That's why I chose to add the address as another recipient.

GitLab takes the first match and that's the project-specific address gitlab+project-20-issue-@..., so it adds a new issue.

Normally, with just one To address, it won't find anything interesting there and will look for References and then create a reply comment.

Proposal

Probably we'll need to also look for the custom email + hash version and then create a comment.
There is also a plan to offer an Active Directory app that would allow us to poll for changes using the Graph API. But work on this hasn't started, yet.

Current workaround

Self-Managed: If you'd like to use the feature, and are fine with "Reply-To" addresses using the incoming_email, you can disable the feature flag service_desk_custom_email_reply on your Self-Managed instance. If disabled, GitLab will use the standard way to ingest replies and generate a reply address using the incoming_email.

SaaS: None.