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 thesupport+[HASH]...
address, but it contains also the original project specific addressgitlab+project-20-issue-@...
address. That might cause the problem.From
header is indeed the original sender.- I can't see any
Delivered-To
entryReferences
header consists ofReferences: <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 aDelivered-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.