Add Service Desk custom email MS365 setup documentation

Marc Saleikorequested to merge
ms/service-desk/custom-email-ms365-setup-documentation into master

What does this MR do and why?

Solves Custom Email: O365 - Forwarding does not preser... (#455341 - closed)

Solves Custom email: Forwarding in Microsoft Exchange ... (#426269 - closed)

Since Directly ingest emails by custom email in To he... (!167770 - merged) has been merged, we can process emails that have the custom email address in the To header. This allows configuring Service Desk custom email for Microsoft 365 (Exchange) customers.

Before we only relied on the availability of the project-specific Service Desk address in one of the supported headers. Exchange doesn't add the forwarding target address (project-specific Service Desk email address) in any header, those emails were rejected because GitLab couldn't figure out what to do with the email. Now GitLab finds the custom email in the To header and can assign the correct project and process the email.

This MR adds a user walkthrough guide on how to set up the Service Desk custom email feature on Microsoft 365 (Exchange). We're aware that there might be a lot of other possible solutions especially those that don't use licensed users. But we want to illustrate one way and the general configuration direction so administrators can modify that to their needs.

I tested the following:

  1. ✅ Locally with incoming_email from MS365 and a custom email from MS365. So email handling happens completely inside MS context.
  2. ✅ On gitlab.com with incoming_email from another provider and custom email from MS365. So MS sends the email to another provider.

References

Please include cross links to any resources that are relevant to this MR This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Related to #455341 (closed)

Edited by Marc Saleiko

Merge request reports