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

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

前提条件:

• プロジェクトのメンテナーまたはオーナーロールが必要です。
• GitLab Self-Managedでは、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. Markdownファイルにテキスト、GitLab Flavored Markdown 、一部の選択されたHTMLタグ、およびプレースホルダーを入力して、サービスデスクリクエスタへの返信をカスタマイズします。

新規参加者メール

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

カスタム新規参加者メールテンプレートを作成するには:

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

新規メモメール

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

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

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

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

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

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

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

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

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

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

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

前提条件:

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

サービスデスクでカスタム説明テンプレートを使用するには:

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

サポートボットユーザー

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

GitLab 16.0および以前では、サービスデスクメールから生成されたコメントは、GitLab Support Botを作成者として表示します。In GitLab 16.1 and laterでは、これらのコメントはメールを送信したユーザーのメールを表示します。この機能は、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認証情報を持っていること（理想的にはアプリパスワードを使用する必要があります）。ユーザー名とパスワードは、Advanced Encryption Standard (AES) を使用して256ビットキーでデータベースに保存されます。

• SMTPホストは、GitLabインスタンスのネットワーク（GitLab Self-Managedの場合）またはパブリックインターネット（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認証情報は削除され、設定を再度開始できます。

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

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

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

カスタムメールを設定する際に、以下のイシューに遭遇する可能性があります。

無効な認証情報

次のようなエラーが表示される場合があります:

The given credentials (username and password) were rejected by the SMTP server,
or you need to explicitly set an authentication method.

このイシューは、SMTPサーバーが認証認証情報を拒否した場合に発生します。

この問題を解決するには、次の手順に従います:

1. ユーザー名とパスワードが正しいことを確認します。

2. GitLabがサポートされている認証方法を自動的に選択できない場合は、次のいずれかを実行します:

   • 利用可能な認証方法をテストします: プレーン、ログイン、およびCRAM-MD5。

   • GitLabサーバーでこのコマンドを実行して、SMTPサーバーがサポートする認証方法を確認します:

          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

     出力で250-AUTHで始まる行を見つけてから、カスタムメールセットアップフォームでサポートされている認証方法のいずれかを選択します。

3. Microsoft 365を使用していてエラーが解決しない場合は、条件付きアクセスを無効にして前の手順を繰り返します。

不適切な転送ターゲット

不適切な転送ターゲットが使用されたことを示すエラーが表示される場合があります。

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

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. カスタムメールアカウントにサインインし、Forwarding and POP/IMAPの設定を開きます。
2. Add a forwarding addressを選択します。
3. カスタムメールフォームからサービスデスクアドレスを入力します。
4. Nextを選択します。
5. 入力を確認し、続行を選択します。Googleはサービスデスクアドレスにメールを送信し、確認コードを要求します。

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

1. Plan > 作業アイテムを選択し、タイプ = Issueでフィルタリングします。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を有効にします。
   1. リストからアカウントを選択します。
   2. ドロワーでMailを選択します。
   3. Email appsの下でManage email appsを選択します。
   4. Authenticated SMTPをチェックし、変更を保存を選択します。
5. 全体的なExchange Online設定によっては、以下のものを設定する必要がある場合があります:

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

      Set-TransportConfig -SmtpClientAuthenticationDisabled $false

   2. Azure Cloud Shellを使用してSMTP AUTHを使用するレガシー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. Nextを選択します。

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アプリケーションを受信メールと同じ方法で設定します。

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

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

サフィックスには、小文字（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です。The 受信メール address still works.

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

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

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

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

Helmチャート (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の基本設定をすべてのノードに追加して、Web 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を再構成します。