サービスデスクを設定する

デフォルトでは、サービスデスクは新規プロジェクトでアクティブになっています。アクティブでない場合は、プロジェクトの設定でアクティブにできます。

前提要件:

• プロジェクトのメンテナー以上のロールを持っている必要があります。
• GitLabセルフマネージドでは、GitLabインスタンスの受信メールを設定する必要があります。メールのサブアドレス指定を使用する必要がありますが、すべてをキャッチするメールボックスを使用することもできます。これを行うには、管理者アクセス権が必要です。
• プロジェクトのイシューイシュートラッカーを有効にする必要があります。

プロジェクトでサービスデスクを有効にするには、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. サービスデスクを有効にするトグルをオンにします。
5. オプション。フィールドに入力します。
   • サービスデスクのメールアドレスにサフィックスを追加します。
   • 以下の全てのサービスデスクのイシューに追加するテンプレートリストが空の場合、リポジトリに説明テンプレートを作成します。
6. 変更を保存を選択します。

これで、このプロジェクトでサービスデスクが有効になりました。サービスデスクで使用するメールアドレスの下に表示されているアドレスに誰かがメールを送信すると、GitLabはそのメールの内容を含む機密性の高いイシューを作成します。

サービスデスクの用語集

この用語集では、サービスデスクに関連する用語の定義を提供します。

プロジェクトのセキュリティを強化する

サービスデスクプロジェクトのセキュリティを強化するには、以下を行う必要があります:

• サービスデスクのメールアドレスをエイリアスの背後に配置して、後で変更できるようにします。
• GitLabインスタンスでAkismetを有効にすると、このサービスデスクにアンチスパムチェックが追加されます。ブロックされていないメールアンチスパムにより、多くのスパムイシューが作成される可能性があります。

外部参加者に送信されるメールをカスタマイズする

外部参加者にメールが送信されるのは、次の場合です:

• リクエスタがサービスデスクにメールを送信して、新しいサービスデスクチケットを送信した場合。
• 外部参加者がサービスデスクのサービスデスクチケットに追加された場合。
• 新しいパブリックコメントがサービスデスクのサービスデスクチケットに追加された場合。
  • コメントを編集しても、新しいメールは送信されません。

これらのメールメッセージの本文は、サービスデスクのメールテンプレートでカスタマイズできます。テンプレートには、GitLab Flavored Markdownと一部のHTMLタグを含めることができます。たとえば、組織のブランドガイドラインに従って、ヘッダーとフッターを含むようにメールをフォーマットできます。サービスデスクのサービスデスクチケットまたはGitLabインスタンスに固有の動的コンテンツを表示するために、次のプレースホルダーを含めることもできます。

サンキューメール

リクエスタがサービスデスクを介してイシューを送信すると、GitLabはthank you email（サンキューメール）を送信します。追加の設定がない場合、GitLabはデフォルトのサンキューメールを送信します。

カスタムサンキューメールテンプレートを作成するには、次の手順を実行します:

1. リポジトリの.gitlab/service_desk_templates/ディレクトリに、thank_you.mdという名前のファイルを作成します。
2. マークダウンファイルにテキスト、GitLab Flavored Markdown 、一部の選択されたHTMLタグ、およびプレースホルダーを設定して、サービスデスクのリクエスタへの返信をカスタマイズします。

新しい参加者メール

外部参加者がチケットに追加されると、GitLabは会話の一部であることを知らせるnew participant email（新しい参加者メール）を送信します。追加の設定がない場合、GitLabはデフォルトの新しい参加者メールを送信します。

カスタムの新しい参加者メールテンプレートを作成するには、次の手順を実行します:

1. リポジトリの.gitlab/service_desk_templates/ディレクトリに、new_participant.mdという名前のファイルを作成します。
2. マークダウンファイルにテキスト、GitLab Flavored Markdown 、一部の選択されたHTMLタグ、およびプレースホルダーを設定して、サービスデスクのリクエスタへの返信をカスタマイズします。

新しいノートメール

サービスデスクのサービスデスクチケットに新しいパブリックコメントがある場合、GitLabはnew note email（新しいノートメール）を送信します。追加の設定がない場合、GitLabはコメントの内容を送信します。

メールのブランドを維持するために、カスタムの新しいノートメールテンプレートを作成できます。これを行うには、次の手順に従います:

1. リポジトリの.gitlab/service_desk_templates/ディレクトリに、new_note.mdという名前のファイルを作成します。
2. マークダウンファイルにテキスト、GitLab Flavored Markdown 、一部の選択されたHTMLタグ、およびプレースホルダーを設定して、新しいノートメールをカスタマイズします。メールの受信者がコメントの内容を読み取れるようにするには、テンプレートに%{NOTE_TEXT}を必ず含めてください。

インスタンス全体のメールヘッダー、フッター、および追加のテキスト

インスタンスの管理者は、ヘッダー、フッター、または追加のテキストをGitLabインスタンスに追加して、GitLabから送信されるすべてのメールに適用できます。カスタムthank_you.md、new_participant、またはnew_note.mdを使用している場合は、このコンテンツを含めるために、%{SYSTEM_HEADER}、%{SYSTEM_FOOTER}、または%{ADDITIONAL_TEXT}をテンプレートに追加します。

詳細については、システムヘッダーとフッターメッセージおよびカスタムの追加テキストを参照してください。

サービスデスクチケットのカスタムテンプレートを使用する

説明テンプレートをper project（プロジェクトごと）に1つ選択して、新しいサービスデスクチケットのすべての説明に追加できます。

説明テンプレートは、さまざまなレベルで設定できます:

• インスタンス全体。
• 特定のグループまたはサブグループ。
• 特定のプロジェクト。

テンプレートは継承されます。たとえば、プロジェクトでは、インスタンスまたはプロジェクトの親グループに設定されているテンプレートにもアクセスできます。

前提要件:

• 説明テンプレートを作成しておく必要があります。

サービスデスクでカスタムの説明テンプレートを使用するには、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. 全てのサービスデスクのイシューに追加するテンプレートドロップダウンリストから、テンプレートを検索または選択します。

サポートボットのユーザー

舞台裏では、サービスデスクは特別なサポートボットのユーザーがイシューを作成することで機能します。このユーザーは、請求対象ユーザーではないため、ライセンス制限数にはカウントされません。

GitLab 16.0以前では、サービスデスクのメールから生成されたコメントは、GitLab Support Botを作成者として表示します。GitLab 16.1以降では、これらのコメントにはメールを送信したユーザーのメールが表示されます。この機能は、GitLab 16.1以降に作成されたコメントにのみ適用されます。

サポートボットの表示名を変更する

サポートボットのユーザーの表示名を変更できます。サービスデスクから送信されたメールには、Fromヘッダーにこの名前が含まれています。デフォルトの表示名はGitLab Support Botです。

カスタムメール表示名を編集するには、次の手順に従います:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. メールの表示名の下に、新しい名前を入力します。
5. 変更を保存を選択します。

デフォルトのチケット表示レベル

新しいチケットはデフォルトで機密性が高いため、少なくともプランナーロールを持つプロジェクトメンバーのみがそれらを表示できます。

プライベートプロジェクトおよび内部プロジェクトでは、新しいチケットがデフォルトで機密でなくなり、プロジェクトメンバーであれば誰でも閲覧できるようにGitLabを設定できます。

新しいチケットは常にデフォルトで機密であるため、パブリックプロジェクトではこの設定は使用できません。

前提要件:

• プロジェクトのメンテナー以上のロールを持っている必要があります。

この設定を無効にするには、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. デフォルトでは、新規チケットは非公開ですチェックボックスをオフにします。
5. 変更を保存を選択します。

外部参加者がコメントした場合にイシューを再度開く

外部参加者がメールでイシューに新しいコメントを追加した場合に、クローズされたイシューを再度開くようにGitLabを設定できます。これにより、イシューの割り当て先をメンションし、To-Doアイテムを作成する内部コメントも追加されます。

チュートリアルについては、短いショーケースビデオをご覧ください。

前提要件:

• プロジェクトのメンテナー以上のロールを持っている必要があります。

この設定を有効にするには、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. Reopen issues on a new note from an external participant（外部参加者からの新しいノートでイシューを再度開く）チェックボックスを選択します。
5. 変更を保存を選択します。

カスタムメールアドレス

サポート通信の送信者として表示するカスタムメールアドレスを設定します。認識されているドメインを使用して、ブランドアイデンティティを維持し、サポートリクエスタに信頼感を植え付けます。

概要については、短いショーケースビデオをご覧ください。

この機能はベータ版です。ベータ機能は本番環境に対応していませんが、リリース前に大幅に変更される可能性は低いです。ユーザーはベータ機能を試して、フィードバックイシューでフィードバックを提供することをお勧めします。

前提要件

プロジェクトごとに1つのサービスデスクのカスタムメールアドレスを使用でき、インスタンス全体で一意である必要があります。

使用するカスタムメールアドレスは、次のすべての要件を満たしている必要があります:

• メール転送をセットアップできます。

• 転送されたメールは、元のFromヘッダーを保持します。

• サービスプロバイダーは、サブアドレス指定をサポートする必要があります。メールアドレスは、ローカル部分（@の前にあるすべて）とドメイン部分で構成されます。

  メールサブアドレス指定を使用すると、+記号を追加し、その後に任意のテキストをローカル部分に追加して、メールアドレスの一意のバリエーションを作成できます。メールアドレスsupport@example.comを指定して、support+1@example.comにメールを送信して、サブアドレス指定がサポートされているかどうかを確認します。このメールはメールボックスに表示されます。

• SMTP認証情報が必要です（理想的には、アプリパスワードを使用する必要があります）。ユーザー名とパスワードは、256ビットキーを持つAdvanced Encryption Standard（AES）を使用してデータベースに保存されます。

• SMTPホストは、GitLabインスタンス（GitLabセルフマネージドの場合）またはパブリックインターネット（GitLab.comの場合）のネットワークから解決できる必要があります。

• プロジェクトのメンテナー以上のロールを持っている必要があります。

• サービスデスクは、プロジェクト用に設定する必要があります。

カスタムメールアドレスを設定する

独自のメールアドレスを使用してサービスデスクのメールを送信する場合は、カスタムメールアドレスを設定して確認します。

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開し、カスタムメールアドレスを設定セクションを見つけます。
4. このプロジェクトに表示されているサービスデスクのアドレスをメモし、メールプロバイダー（たとえば、Gmail）を使用して、カスタムメールアドレスからサービスデスクのアドレスへのメール転送をセットアップします。
5. GitLabに戻り、フィールドに入力します。
6. Save & test connection（接続の保存とテスト）を選択します。

設定が保存され、カスタムメールアドレスの検証がトリガーされます。

検証

1. 設定が完了すると、すべてのプロジェクトオーナーと、カスタムメールの設定を保存した管理者は、通知メールを受信します。
2. 指定されたSMTP認証情報を使用して、検証メールがカスタムメールアドレス（サブアドレス指定部分を含む）に送信されます。このメールには、検証トークンが含まれています。メール転送が正しくセットアップされ、すべての前提条件が満たされると、メールはサービスデスクのアドレスに転送され、GitLabによってインジェストされます。GitLabは次の条件を確認します:
   1. GitLabは、SMTP認証情報を使用してメールを送信できます。
   2. サブアドレス指定がサポートされています（+verifyサブアドレス指定部分を使用）。
   3. Fromヘッダーは転送後に保持されます。
   4. 検証トークンが正しい。
   5. メールは30分以内に受信されます。

通常、プロセスには数分しかかかりません。

認証をいつでもキャンセルするか、認証に失敗した場合は、カスタムメールをリセットを選択します。設定ページがそれに応じて更新され、認証の現在の状態が反映されます。SMTP認証情報が削除され、設定を再度開始できます。

失敗時と成功時に、すべてのプロジェクトオーナーと検証プロセスをトリガーしたユーザーは、検証結果を含む通知メールを受信します。検証に失敗した場合、メールには理由の詳細も記載されています。

検証が成功した場合、カスタムメールアドレスを使用する準備ができています。カスタムメールアドレスでサービスデスクのメールの送信を有効にできるようになりました。

設定のトラブルシューティング

カスタムメールを設定するときに、次の問題が発生する可能性があります。

無効な認証情報

無効な認証情報が使用されたことを示すエラーが表示される場合があります。

これは、SMTPサーバーが認証に失敗したことを返す場合に発生します。

この問題を解決するには、次のようにします:

1. SMTP認証情報、特にユーザー名とパスワードを確認します。
2. GitLabは、SMTPサーバーがサポートする認証方法を自動的に選択できない場合があります。次のいずれかの操作を行います:

   • 使用可能な認証方法（プレーン、ログイン、およびCRAM-MD5）を試してください。

   • swaksコマンドラインツールを使用して、SMTPサーバーがサポートする認証方法を確認します:

     1. 認証情報を使用して次のコマンドを実行し、250-AUTHで始まる行を探します:

        swaks --to user@example.com \
              --from support@example.com \
              --auth-user support@example.com \
              --server smtp@example.com:587 \
              -tls-optional \
              --auth-password your-app-password

     2. カスタムメール設定フォームで、サポートされている認証方法のいずれかを選択します。

転送先が正しくありません

転送先が正しくないことを示すエラーが表示される場合があります。

これは、確認メールが、カスタムメール設定フォームに表示されるプロジェクト固有のサービスデスクアドレスとは異なるメールアドレスに転送された場合に発生します。

incoming_emailから生成されたサービスデスクアドレスを使用する必要があります。service_desk_emailから生成された追加のサービスデスクエイリアスアドレスへの転送は、すべてのメールによる返信機能をサポートしていないため、サポートされていません。

この問題を解決するには、次のようにします:

1. メールの転送先となる正しいメールアドレスを見つけます。次のいずれかの操作を行います:
   • すべてのプロジェクトオーナーと、検証プロセスをトリガーしたユーザーが受信する検証結果メールのアドレスをメモしておきます。
   • カスタムメール設定フォームのメールを転送するためのサービスデスクのメールアドレス入力からアドレスをコピーします。
2. すべてのメールをカスタムメールアドレスから正しいターゲットメールアドレスに転送します。

カスタムメールアドレスを有効または無効にする

カスタムメールアドレスが検証された後、管理者は、カスタムメールアドレスでサービスデスクメールの送信を有効または無効にできます。

カスタムメールアドレスをenable（有効）にするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開する。
4. Enable custom email（カスタムメールを有効にする） トグルをオンにします。外部の参加者へのサービスデスクメールは、SMTP認証情報を使用して送信されます。

カスタムメールアドレスをdisable（無効）にするには:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 設定 > 一般を選択します。

3. サービスデスクを展開する。

4. Enable custom email（カスタムメールを有効にする） トグルをオフにします。メール転送を設定したため、カスタムメールアドレス宛てのメールは引き続き処理され、プロジェクトのサービスデスクチケットとして表示されます。

   外部の参加者へのサービスデスクメールは、GitLabインスタンスのデフォルトの送信メール設定を使用して送信されるようになりました。

カスタムメール設定を変更または削除する

カスタムメール設定を変更するには、リセットして削除し、もう一度カスタムメールを設定する必要があります。

プロセスの任意の手順で設定をリセットするには、カスタムメールをリセットを選択します。認証情報がデータベースから削除されます。

カスタムメール返信先アドレス

外部の参加者は、メールでサービスデスクチケットに返信できます。GitLabは、チケットに対応する32文字の返信キーを持つメール返信アドレスを使用します。カスタムメールが設定されている場合、GitLabはそのメールから返信アドレスを生成します。

独自のドメインでGoogle Workspaceを使用する

独自のドメインでGoogle Workspaceを使用する場合、サービスデスクのカスタムメールアドレスを設定します。

前提要件:

• Google Workspaceアカウントを既にお持ちである。
• テナントの新しいアカウントを作成できます。

Google Workspaceでカスタムサービスデスクメールアドレスを設定するには:

1. Google Workspaceアカウントを設定します。
2. Google Workspaceでメール転送を設定します。
3. Google Workspaceアカウントを使用してカスタムメールアドレスを設定します。

Google Workspaceアカウントを設定する

まず、Google Workspaceアカウントを作成して設定する必要があります。

Google Workspaceの場合:

1. 使用するカスタムメールアドレスの新しいアカウントを作成します（例：support@example.com）。
2. そのアカウントにサインインし、2要素認証を有効にします。
3. SMTPパスワードとして使用できるアプリパスワードを作成します。安全な場所に保存し、文字間のスペースを削除します。

次に、Google Workspaceでメール転送を設定する必要があります。

Google Workspaceでメール転送を設定する

次の手順では、GitLabとGoogle Workspaceの間を移動する必要があります。

GitLabで、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定>一般を選択します。
3. サービスデスクを展開する。
4. メールを転送するためのサービスデスクのメールアドレスの下のメールアドレスをメモします。

Google Workspaceの場合:

1. カスタムメールアカウントにサインインし、転送とPOP/IMAP設定ページを開きます。
2. Add a forwarding address（転送先アドレスを追加）を選択します。
3. カスタムメールフォームからサービスデスクアドレスを入力します。
4. 次へを選択します。
5. 入力を確認し、続行を選択します。Googleはメールをサービスデスクアドレスに送信し、確認コードを要求します。

GitLabで、次の手順を実行します:

1. プロジェクトのイシューに移動し、Googleからの確認メールから新しいイシューが作成されるのを待ちます。
2. イシューを開き、確認コードをメモします。
3. （オプション）イシューを削除します。

Google Workspaceの場合:

1. 確認コードを入力し、Verify（確認）を選択します。
2. Forward a copy of incoming mail to（受信メールのコピーを転送）を選択し、ドロップダウンリストからサービスデスクアドレスが選択されていることを確認します。
3. ページの下部にある変更を保存を選択します。

次に、サービスデスクで使用するGoogle Workspaceアカウントを使用してカスタムメールアドレスを設定します。

Google Workspaceアカウントを使用してカスタムメールアドレスを設定する

GitLabで、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定>一般を選択します。
3. サービスデスクを展開する、カスタムメール設定を見つけます。
4. フィールドに入力します:
   • カスタムメールアドレス: あなたのカスタムメールアドレス。
   • SMTPホスト：smtp.gmail.com。
   • SMTPポート：587。
   • SMTPユーザー名: カスタムメールアドレスが事前に入力されています。
   • SMTPパスワード: カスタムメールアカウント用に以前に作成したアプリパスワード。
   • SMTP認証方法: GitLabにサーバーがサポートする方法を選択させる（推奨）
5. 接続の保存とテストを選択
6. 確認プロセスの後、カスタムメールアドレスを有効にすることができるはずです。

独自のドメインでMicrosoft 365（Exchange Online）を使用する

独自のドメインでMicrosoft 365（Exchange）を使用する場合、サービスデスクのカスタムメールアドレスを設定します。

前提要件:

• Microsoft 365アカウントを既にお持ちである。
• テナントの新しいアカウントを作成できます。

Microsoft 365でカスタムサービスデスクメールアドレスを設定するには:

1. Microsoft 365アカウントを設定します。
2. Microsoft 365でメール転送を設定します。
3. Microsoft 365アカウントを使用してカスタムメールアドレスを設定します。

Microsoft 365アカウントを設定する

まず、Microsoft 365アカウントを作成して設定する必要があります。このガイドでは、カスタムメールメールボックスにライセンスされたユーザーを使用します。他の設定オプションを試すこともできます。

Microsoft 365管理センターで:

1. 使用するカスタムメールアドレスの新しいアカウントを作成します（例：support@example.com）。
   1. ユーザーセクションを展開する、メニューからアクティブなユーザーを選択します。
   2. Add a user（ユーザー）を選択し、画面の指示に従います。
2. Microsoft Entra（以前はActive Directoryという）で、アカウントの2要素認証を有効にします。
3. ユーザーがアプリのパスワードを作成できるようにする。
4. アカウントのAuthenticated SMTP（認証済みSMTP）を有効にします。
   1. リストからアカウントを選択します。
   2. ドロワーで、Mail（メール）を選択します。
   3. Email apps（メールアプリ） の下でManage email apps（メールアプリ）の管理] を選択します。
   4. Authenticated SMTP（認証済みSMTP）をチェックし、変更を保存を選択します。
5. 全体的なExchangeオンライン設定によっては、以下を設定する必要がある場合があります:

   1. Azure Cloudシェルを使用して、SMTPクライアント認証を許可します:

      Set-TransportConfig -SmtpClientAuthenticationDisabled $false

   2. Azure Cloudシェルを使用して、SMTP認証を使用するレガシーTLSクライアントを許可します:

      Set-TransportConfig -AllowLegacyTLSClients $true

   3. 外部受信者に転送する場合は、外部メール転送を有効にする方法に関するこのガイドを参照してください。また、それを必要とするユーザーに対してのみ外部受信者への転送を許可するために、送信アンチスパムポリシーを作成することもできます。

6. そのアカウントにサインインし、2要素認証を有効にします。
   1. 右上隅のメニューからView account（アカウントの表示） を選択し、Security Info（セキュリティ情報）に移動します。
   1. Add sign-in method（サインイン方法を追加）を選択し、自分に適した方法（認証アプリ、電話、またはメール）を選択します。
   2. 画面の指示に従ってください。

1. Security Info（セキュリティ情報）ページで、SMTPパスワードとして使用できるアプリパスワードを作成します。

1. Add sign-in method（サインイン方法を追加）を選択し、ドロップダウンリストからApp password（アプリのパスワード）を選択します。

2. GitLab SDなどのアプリパスワードにわかりやすい名前を設定します。

3. 次へを選択します。

4. 表示されたパスワードをコピーし、安全な場所に保管します。

5. オプション。swaksコマンドラインツールを使用して、SMTPを使用してメールを送信できることを確認します。

6. 認証情報を使用して次のコマンドを実行し、アプリパスワードをauth-passwordとして使用します:

   swaks --to your-email@example.com \
         --from custom-email@example.com \
         --auth-user custom-email@example.com \
         --server smtp.office365.com:587 \
         -tls-optional \
         --auth-password <your_app_password>

次に、Microsoft 365でメール転送を設定する必要があります。

Microsoft 365でメール転送を設定する

次の手順では、GitLabとMicrosoft 365管理センターの間を移動する必要があります。

GitLabで、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。

2. 設定>一般を選択します。

3. サービスデスクを展開する。

4. サブアドレス部分なしで、メールを転送するためのサービスデスクのメールアドレスの下のメールアドレスをメモします。

   受信者のアドレスにサブアドレス（GitLabによって生成された返信アドレスなど）が含まれており、転送メールアドレスにサブアドレス（メールを転送するためのサービスデスクのメールアドレス）が含まれている場合、メールは転送されません。

   たとえば、incoming+group-project-12346426-issue-@incoming.gitlab.comはincoming@incoming.gitlab.comになります。Exchange onlineは転送後もToヘッダーにカスタムメールアドレスを保持し、GitLabはカスタムメールアドレスに基づいて正しいプロジェクトを割り当てることができるため、問題ありません。

Microsoft 365管理センターで:

1. ユーザーセクションを展開する、メニューからアクティブなユーザーを選択します。

1. リストからカスタムメールに使用するアカウントを選択します。
2. ドロワーで、Mail（メール）を選択します。
3. Email forwarding（メール転送） の下でManage email forwarding（メール転送の管理） を選択します。
4. Forward all emails sent to this mailbox（このメールボックスに送信されたすべてのメールを転送）をチェックします。
5. サブアドレス部分なしで、Forwarding email address（メール転送先メールアドレス） のカスタムメールフォームからサービスデスクアドレスを入力します。
6. 変更を保存を選択します。

次に、サービスデスクで使用するために、Microsoft 365アカウントを使用してカスタムメールアドレスを設定する。

Microsoft 365アカウントを使用してカスタムメールアドレスを設定する

GitLabで、次の手順を実行します:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定>一般を選択します。
3. サービスデスクを展開する、カスタムメール設定を見つけます。
4. フィールドに入力します:
   • カスタムメールアドレス: あなたのカスタムメールアドレス。
   • SMTPホスト：smtp.office365.com。
   • SMTPポート：587。
   • SMTPユーザー名: カスタムメールアドレスが事前に入力されています。
   • SMTPパスワード: カスタムメールアカウント用に以前に作成したアプリパスワード。
   • SMTP認証方法: ログイン
5. 接続の保存とテストを選択
6. 確認プロセスの後、カスタムメールアドレスを有効にすることができるはずです。

既知の問題

• 一部のサービスプロバイダーでは、SMTP接続が許可されなくなりました。多くの場合、ユーザーごとに有効にし、アプリパスワードを作成できます。

追加のサービスデスクエイリアスメールを使用する

インスタンスのサービスデスクで、追加のエイリアスメールアドレスを使用できます。

これを行うには、インスタンスの設定でservice_desk_emailを設定する必要があります。カスタムサフィックスを設定して、サブアドレス部分の-issue-デフォルト部分を置き換えることもできます。

サービスデスクエイリアスメールアドレスを設定する

サービスデスクでは、受信メールの設定がデフォルトで使用されます。ただし、サービスデスク用に別のメールアドレスを使用するには、プロジェクトの設定で、service_desk_emailをカスタムサフィックスで設定します。

前提要件:

• addressには、アドレスのuser部分の+%{key}プレースホルダーを@の前に含める必要があります。プレースホルダーは、イシューを作成するプロジェクトを識別するために使用されます。
• service_desk_emailとincoming_emailの設定では、サービスデスクのメールが正しく処理されるように、常に個別のメールボックスを使用する必要があります。

IMAPでサービスデスクのカスタムメールボックスを設定するには、次のスニペットを設定ファイルに完全に追加します:

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@gmail.com"
gitlab_rails['service_desk_email_email'] = "project_contact@gmail.com"
gitlab_rails['service_desk_email_password'] = "[REDACTED]"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_idle_timeout'] = 60
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_host'] = "imap.gmail.com"
gitlab_rails['service_desk_email_port'] = 993
gitlab_rails['service_desk_email_ssl'] = true
gitlab_rails['service_desk_email_start_tls'] = false

service_desk_email:
  enabled: true
  address: "project_contact+%{key}@example.com"
  user: "project_contact@example.com"
  password: "[REDACTED]"
  host: "imap.gmail.com"
  delivery_method: webhook
  secret_file: .gitlab-mailroom-secret
  port: 993
  ssl: true
  start_tls: false
  log_path: "log/mailroom.log"
  mailbox: "inbox"
  idle_timeout: 60
  expunge_deleted: true

設定オプションは、受信メールの設定と同じです。

暗号化された認証情報を使用する

サービスデスクのメールの認証情報を設定ファイルに平文で保存する代わりに、オプションで、暗号化されたファイルを受信メールの認証情報に使用することもできます。

前提要件:

• 暗号化された認証情報を使用するには、まず暗号化設定を有効にする必要があります。

暗号化されたファイルでサポートされている設定項目は次のとおりです:

• user
• password

Microsoft Graph

service_desk_emailは、IMAPの代わりに、Microsoft Graph APIを使用してMicrosoft Exchange Onlineメールボックスを読み取りるように設定できます。受信メールの場合と同じ方法で、Microsoft GraphのOAuth 2.0アプリケーションをセットアップします。

gitlab_rails['service_desk_email_enabled'] = true
gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.onmicrosoft.com"
gitlab_rails['service_desk_email_email'] = "project_contact@example.onmicrosoft.com"
gitlab_rails['service_desk_email_mailbox_name'] = "inbox"
gitlab_rails['service_desk_email_log_file'] = "/var/log/gitlab/mailroom/mail_room_json.log"
gitlab_rails['service_desk_email_inbox_method'] = 'microsoft_graph'
gitlab_rails['service_desk_email_inbox_options'] = {
  'tenant_id': '<YOUR-TENANT-ID>',
  'client_id': '<YOUR-CLIENT-ID>',
  'client_secret': '<YOUR-CLIENT-SECRET>',
  'poll_interval': 60  # Optional
}

gitlab_rails['service_desk_email_inbox_options'] = {
  'azure_ad_endpoint': 'https://login.microsoftonline.us',
  'graph_endpoint': 'https://graph.microsoft.us',
  'tenant_id': '<YOUR-TENANT-ID>',
  'client_id': '<YOUR-CLIENT-ID>',
  'client_secret': '<YOUR-CLIENT-SECRET>',
  'poll_interval': 60  # Optional
}

  service_desk_email:
    enabled: true
    address: "project_contact+%{key}@example.onmicrosoft.com"
    user: "project_contact@example.onmicrosoft.com"
    mailbox: "inbox"
    delivery_method: webhook
    log_path: "log/mailroom.log"
    secret_file: .gitlab-mailroom-secret
    inbox_method: "microsoft_graph"
    inbox_options:
      azure_ad_endpoint: "https://login.microsoftonline.us"
      graph_endpoint: "https://graph.microsoft.us"
      tenant_id: "<YOUR-TENANT-ID>"
      client_id: "<YOUR-CLIENT-ID>"
      client_secret: "<YOUR-CLIENT-SECRET>"
      poll_interval: 60  # Optional

サービスデスクエイリアスメールのサフィックスを設定する

プロジェクトのサービスデスクの設定で、カスタムサフィックスをセットできます。

サフィックスには、小文字（a-z）、数字（0-9）、またはアンダースコア（_）のみを含めることができます。

設定すると、カスタムサフィックスによって、service_desk_email_address設定と次の形式のキーで構成される新しいサービスデスクのメールアドレスが作成されます：<project_full_path>-<custom_suffix>

前提要件:

• サービスデスクエイリアスメールを設定する必要があります。

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > 一般を選択します。
3. サービスデスクを展開します。
4. メールアドレスのサフィックスの下に、使用するサフィックスを入力します。
5. 変更を保存を選択します。

たとえば、mygroup/myprojectプロジェクトのサービスデスクの設定に次の設定があるとします:

• メールアドレスのサフィックスがsupportに設定されています。
• サービスデスクのメールアドレスがcontact+%{key}@example.comに設定されています。

このプロジェクトのサービスデスクのメールアドレスは次のとおりです：contact+mygroup-myproject-support@example.com。受信メールアドレスは引き続き機能します。

カスタムサフィックスを設定しない場合、デフォルトのプロジェクト識別がプロジェクトの識別に使用されます。

マルチノード環境でのメール取り込みを設定する

マルチノード環境とは、スケーラビリティ、フォールトトレランス、およびパフォーマンス上の理由から、複数のサーバーにわたってGitLabが実行されるセットアップです。

GitLabは、mail_roomと呼ばれる別のプロセスを使用して、incoming_emailおよびservice_desk_emailメールボックスから新しい未読メールをインジェストするます。

Helm Chart（Kubernetes）

GitLab Helmチャートは複数のサブチャートで構成されており、そのうちの1つがMailroomサブチャートです。incoming_emailの共通設定を設定するとservice_desk_emailの共通設定を設定する。

Linuxパッケージ（Omnibus）

マルチノードLinuxパッケージインストール環境では、mail_roomを1つのノードでのみ実行します。単一のrailsノード（application_roleなど）で実行するか、完全に個別に実行します。

すべてのノードをセットアップする

1. すべてのノードでincoming_emailおよびservice_desk_emailの基本的な設定を追加して、ウェブUIおよび生成されたメールでメールアドレスをレンダリングします。

   /etc/gitlab/gitlab.rbで、incoming_emailまたはservice_desk_emailセクションを見つけます:

   incoming_email

   gitlab_rails['incoming_email_enabled'] = true
   gitlab_rails['incoming_email_address'] = "incoming+%{key}@example.com"

   service_desk_email

   gitlab_rails['service_desk_email_enabled'] = true
   gitlab_rails['service_desk_email_address'] = "project_contact+%{key}@example.com"

2. GitLabは、mail_roomからGitLabアプリケーションにメールを転送する2つの方法を提供します。メールの設定ごとにdelivery_methodを個別に設定できます:

   1. 推奨：webhook（GitLab 15.3以降でデフォルト）は、API POSTリクエストを使用してメールペイロードをGitLabアプリケーションに送信します。認証には、共有トークンが使用されます。この方法を選択する場合は、mail_roomプロセスがAPIエンドポイントにアクセスでき、すべてのアプリケーションノード間で共有トークンを配布できることを確認してください。

      incoming_email

      gitlab_rails['incoming_email_delivery_method'] = "webhook"
      
      # The URL that mail_room can contact. You can also use an internal URL or IP,
      # just make sure mail_room can access the GitLab API with that address.
      # Do not end with "/".
      gitlab_rails['incoming_email_gitlab_url'] = "https://gitlab.example.com"
      
      # The shared secret file that should contain a random token. Make sure it's the same on every node.
      gitlab_rails['incoming_email_secret_file'] = ".gitlab_mailroom_secret"

      service_desk_email

      gitlab_rails['service_desk_email_delivery_method'] = "webhook"
      
      # The URL that mail_room can contact. You can also use an internal URL or IP,
      # just make sure mail_room can access the GitLab API with that address.
      # Do not end with "/".
      
      gitlab_rails['service_desk_email_gitlab_url'] = "https://gitlab.example.com"
      
      # The shared secret file that should contain a random token. Make sure it's the same on every node.
      gitlab_rails['service_desk_email_secret_file'] = ".gitlab_mailroom_secret"

   2. webhookのセットアップで問題が発生する場合は、sidekiqを使用して、Redisを使用してメールペイロードをGitLab Sidekiqに直接配信します。

      incoming_email

      # It uses the Redis configuration to directly add Sidekiq jobs
      gitlab_rails['incoming_email_delivery_method'] = "sidekiq"

      service_desk_email

      # It uses the Redis configuration to directly add Sidekiq jobs
      gitlab_rails['service_desk_email_delivery_method'] = "sidekiq"

3. メール取り込みを実行しないすべてのノードでmail_roomを無効にします。次に、/etc/gitlab/gitlab.rbの例を示します:

   mailroom['enable'] = false

4. 変更を有効にするには、GitLabを再設定します。

単一メール取り込みノードをセットアップする

すべてのノードをセットアップし、mail_roomプロセスを無効にした後、単一のノードでmail_roomを有効にします。このノードは、incoming_emailおよびservice_desk_emailのメールボックスを定期的にポーリングするし、新しい未読メールをGitLabに移動します。

1. さらにメール取り込みを処理する既存のノードを選択します。

2. incoming_emailおよびservice_desk_emailの完全な設定と認証情報を追加します。

3. このノードでmail_roomを有効にします。次に、/etc/gitlab/gitlab.rbの例を示します:

   mailroom['enable'] = true

4. 変更を有効にするには、このノードでGitLabを再設定する。