• プロジェクトのセキュリティを向上させましょう。
• 依頼者に送るメールのカスタマイズ
  • お礼メール
  • 新しいノートメール
  • インスタンスレベルのメールのヘッダー、フッター、追加テキスト
• サービスデスクのチケットにカスタムテンプレートを使用
• サポートボットユーザー
  • サポートボットの表示名を変更
• カスタムメールアドレス
  • 前提条件
  • カスタムEメールアドレスの設定
    • 検証
  • カスタムEメールアドレスの有効化または無効化
  • カスタムEメール設定の変更または削除
  • 既知のイシュー
• 追加のサービスデスクエイリアスメールを使用
  • サービスデスクエイリアス電子メールの設定
    • 暗号化された認証情報を使用
    • Microsoft Graph
  • Service Desk エイリアス電子メールのサフィックス設定
• 複数ノード環境でのメール取り込みの設定
  • Helmチャート (Kubernetes)
  • Linuxパッケージ(Omnibus)
    • すべてのノードのセットアップ
    • 一つのメール取り込みノードを設定します。

サービスデスクの設定

デフォルトでは、Service Deskは新しいプロジェクトでアクティビティになっています。もしアクティブでなければ、プロジェクトの設定で設定できます。

前提条件：

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

プロジェクトでサービスデスクを有効にするには

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開します。
4. サービスデスクをアクティブにするトグルをオンにします。
5. オプション。フィールドを入力します。
   • サービスデスクのメールアドレスにサフィックスを追加します。
   • すべてのサービスデスクのイシューに追加するテンプレートの下のリストが空の場合は、リポジトリに説明テンプレートを作成してください。
6. 変更を保存を選択します。

これで、このプロジェクトで Service Desk が有効になりました。もし誰かが以下のアドレスにメールを送信した場合サービスデスクに使用するメールアドレス GitLab はメールの内容で機密イシューを作成します。

プロジェクトのセキュリティを向上させましょう。

サービスデスクプロジェクトのセキュリティを向上させるには、以下のことを行う必要があります：

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

依頼者に送るメールのカスタマイズ

• 13.2でGitLab PremiumからGitLab Freeに移行しました。
• UNSUBSCRIBE_URL SYSTEM_HEADER,SYSTEM_FOOTER,ADDITIONAL_TEXT プレースホルダーはGitLab 15.9で導入されました。
• %{ISSUE_DESCRIPTION} GitLab 16.0で導入。
• %{ISSUE_URL} GitLab 16.1 で導入。

次のような場合に、依頼者にメールが送信されます：

• 依頼者がサービスデスクにメールで新しいチケットを送信した場合。
• サービスデスクのチケットに新しい公開コメントが追加されます。
  • コメントを編集しても、新しいメールは送信されません。

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

お礼メール

依頼者が Service Desk を通してイシューを提出すると、GitLab はサンキューメールを送信します。追加の設定がない場合、GitLab はデフォルトのサンキューメールを送信します。

カスタムのサンキューメールテンプレートを作成するには

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

新しいノートメール

Service Desk チケットに新しい公開コメントがあると、GitLab は新しいノートメールを送信します。追加設定なしで、GitLab はコメントの内容を送信します。

メールのブランドを保つために、カスタムの新規ノートメールテンプレートを作成することができます。そのためには

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

インスタンスレベルのメールのヘッダー、フッター、追加テキスト

GitLab 15.9 で導入されました。

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

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

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

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

説明テンプレートは様々なレベルで設定できます：

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

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

前提条件

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

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

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

サポートボットユーザー

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

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

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

サポートボットユーザーの表示名を変更することができます。Service Desk から送信されるメールには、From ヘッダーにこの名前が表示されます。デフォルトの表示名はGitLab Support Botです。

カスタムメール表示名を編集するには

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開します。
4. Eメール表示名の下に新しい名前を入力します。
5. 変更を保存を選択します。

カスタムメールアドレス

GitLab 16.3 でservice_desk_custom_email というフラグで導入されました。デフォルトでは無効です。

フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。プロジェクトごと、またはインスタンス全体で利用できるようにするには、管理者がservice_desk_custom_emailという機能フラグを有効にします。GitLab.comでは、この機能は利用できません。この機能はまだ本番環境では使用できません。

サポートコミュニケーションの送信者として表示するカスタムメールアドレスを設定します。ブランド・アイデンティティを維持し、サポート依頼者に認知度の高いドメインで信頼感を与えます。

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

前提条件

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

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

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

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

  電子メールのサブアドレスを使用すると、+ シンボルの後に任意のテキストをローカル部分に追加することで、電子メールアドレスのユニークなバリエーションを作成できます。support@example.comというメールアドレスがある場合、support+1@example.com宛にメールを送信して、サブアドレスがサポートされているかどうかを確認してください。 このメールはメールボックスに表示されるはずです。

• あなたはSMTP認証を持っています（アプリのパスワードを使うのが理想的です）。
• 少なくともプロジェクトのメンテナーのロールを持っている必要があります。
• プロジェクトにサービスデスクが設定されている必要があります。

カスタムEメールアドレスの設定

独自のメールアドレスを使用してService Deskのメールを送信する場合は、カスタムメールアドレスを設定および確認します。

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開し、カスタムEメール設定を見つけます。
4. このプロジェクトのService Deskアドレスをメモし、Eメールプロバイダ（例えば、Gmail）を使用して、カスタムEメールアドレスからService DeskアドレスへのEメール転送を設定します。
5. GitLabに戻って、フィールドを完成させてください。SMTPホストは、GitLabインスタンスのネットワーク（GitLabセルフマネジメントの場合）または公開インターネット（GitLab SaaSの場合）から解決可能でなければなりません。
6. Save & test settingsを選択します。

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

検証

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

通常は数分で完了します。

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

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

検証が成功した場合、カスタムメールアドレスは使用可能な状態になります。これで、カスタムメールアドレス経由でサービスデスクメールを送信できるようになります。

カスタムEメールアドレスの有効化または無効化

カスタムEメールアドレスが確認された後、管理者はカスタムEメールアドレス経由でサービスデスクEメールの送信を有効または無効にすることができます。

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

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開します。
4. カスタムメールを有効にする］トグルをオンにします。外部参加者へのService DeskメールはSMTP認証情報を使用して送信されます。

カスタムEメールアドレスを無効にするには：

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開します。

4. カスタムEメールを有効にする］トグルをオフにします。Eメール転送を設定したため、カスタムEメールアドレスへのEメールは引き続き処理され、プロジェクト内のService Deskチケットとして表示されます。

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

カスタムEメール設定の変更または削除

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

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

既知のイシュー

• SMTP接続を許可しないサービスプロバイダがあります。多くの場合、ユーザーごとに有効にし、アプリのパスワードを作成することができます。
• Microsoft ExchangeはFrom ヘッダーを保持しないため、同じテナントからカスタムメールを使用することはできません。回避策として
  • GitLab SaaSでは、トランスポートルールを使用して、カスタムメールアドレスからのメールをGitLab SaaSからService Deskのメールに転送します。現在のテナント外のメールアドレスに転送すると、元のFrom ヘッダーが保持されます。
  • GitLab セルフマネージドでは、カスタムメールアドレスまたは GitLab インスタンスincoming_email またはservice_desk_email に、サブドメインまたは別のサービスプロバイダからの別のドメインを使用します。

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

• GitLab 13.0から導入されました。
• GitLab 13.8で機能フラグを削除しました。

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

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

サービスデスクエイリアス電子メールの設定

Service Desk はデフォルトで受信メールの設定を使用します。しかし、サービスデスク用に別のメールアドレスを持つには、プロジェクト設定でservice_desk_email をカスタムサフィックスで設定してください。

前提条件：

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

IMAPでService Deskのカスタムメールボックスを設定するには、以下のスニペットを設定ファイルに完全に追加します：

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

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

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

GitLab 15.9 で導入されました。

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

前提条件：

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

暗号化ファイルの設定項目は以下のとおりです：

• user
• password

Microsoft Graph

• GitLab 14.9で導入された代替Azureデプロイ。
• GitLab 15.11でセルフコンパイル（ソース）インストールに導入されました。

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

Service Desk エイリアス電子メールのサフィックス設定

プロジェクトのサービスデスク設定でカスタム接尾辞を設定することができます。

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

設定すると、カスタムサフィックスは、service_desk_email_address の設定とフォーマットのキーで構成される新しいサービスデスクのメールアドレスを作成します：<project_full_path>-<custom_suffix>

前提条件：

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

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. 設定] > [全般]を選択します。
3. サービスデスクを展開します。
4. 電子メールアドレスの接尾辞の下に、使用する接尾辞を入力します。
5. 変更を保存を選択します。

例えば、mygroup/myproject プロジェクト Service Desk 設定に以下の設定があるとします：

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

このプロジェクトのサービスデスクのメールアドレスはcontact+mygroup-myproject-support@example.com です。受信メールアドレスはまだ機能しています。

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

複数ノード環境でのメール取り込みの設定

マルチノード環境とは、スケーラビリティ、フォールトトレランス、パフォーマンス上の理由から、GitLabが複数のサーバーで実行される設定のことです。

GitLabは、incoming_email とservice_desk_email メールボックスから新しい未読メールを取り込むために、mail_room という別のプロセスを使っています。

Helmチャート (Kubernetes)

GitLab Helmチャートは複数のサブチャートで構成されており、そのうちの1つがMailroomサブチャートです。incoming_email](https://docs.gitlab.com/charts/installation/command-line-options.html#incoming-email-configuration) の共通設定と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 via 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 via 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. GitLab 16.0では非推奨、17.0では削除予定)： 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['enabled'] = false
   

4. 変更を有効にするには、GitLabを再設定してください。

一つのメール取り込みノードを設定します。

全てのノードを設定し、mail_room プロセスを mail_room無効にした後mail_room 、 mail_room一つのノードで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['enabled'] = true
   

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