IMAP グループ受信トレイ対応

martin · 2020 年 8 月 12 日午前 5:03

Discourse での IMAP サポートを削除します。 詳細については、この投稿をご覧ください IMAP support for group inboxes - #39 by martin 。

グループ受信箱向けの IMAP サポートのアルファ版をご紹介できることを嬉しく思います。この機能により、グループごとに IMAP 認証情報と設定を入力して、グループ受信箱を電子メール受信箱と同期できるようになります。

これはアルファ段階の機能であり、100% 完成して洗練されたものではありません。動作しない可能性が非常に高く、現在は保守されておらず、本番環境で使用されていません。自己責任で使用してください！

メリット

既存のメールがすべて同期されるため、グループは Discourse 受信箱の使用をすぐに開始できます
単一の障害点がないよう、Discourse とメールプロバイダー間でメッセージが同期されます。電子メールアカウントからでも Discourse 内からでも返信でき、すべてが同期されます
メールプロバイダーから Discourse の受信トレイへ奇妙な転送ルールを設定する必要がなくなります。
電子メールのラベルが Discourse のタグと同期され、整理された状態を保つことができます
Discourse から返信した場合でも、グループにメールを送信した相手には、設定した電子メールアドレスから返信されます。もう混乱は不要です！

機能

受信メールと送信メールの両方が IMAP サーバーと Discourse 間で同期され、解析されたメールに基づいて適切なトピックと投稿の返信が作成されます。Discourse からでも IMAP サーバーからでも返信を作成でき、すべてが同期されます！
電子メールは Discourse のグループ受信箱から、または電子メールアカウントから返信できます。
Discourse トピックに適用されたタグは、ラベルとして作成され、IMAP サーバー上の電子メールに適用されます（これはプロバイダー固有です）。
IMAP サーバー上でアーカイブされた電子メールは、グループ受信箱でもアーカイブされます。
Discourse でアーカイブされたグループのプライベートメッセージトピックは、IMAP サーバーでもアーカイブされます。
IMAP サーバー上で削除された電子メールは、グループ受信箱内のトピックを削除します。
Discourse で削除されたグループのプライベートメッセージトピックは、IMAP サーバーでも削除されます。
この機能を有効にしたグループから送信された電子メールの返信先アドレスは、IMAP 設定で設定された電子メールユーザー名と同じになります。

始め方

まず、グループでこの機能を設定する前に、いくつかのサイト設定を構成する必要があります。

enable imap と enable smtp の両方を有効にする必要があります。IMAP はメールサーバーとの同期に、SMTP はメールサーバーからのメール送信に使用されます。
tagging enabled と allow staff to tag pms の両方を有効にする必要があります。ラベル同期は PM にタグを適用するためです。
enable imap write - Discourse での変更をメールサーバーに反映させたい場合（例えばタグの付け外し、トピックのアーカイブ、トピックの削除など）に有効にする必要があります。
enable imap idle - メールサーバーが IDLE をサポートしている場合、メールサーバーからライブ更新を受信できます。これにより、メールプロバイダーから Discourse への変更反映が大幅に高速化されます。これをオンにすることをお勧めします（Gmail はサポートしています）。詳細については、IDLE の RFC をご覧ください。
imap polling period mins - IDLE がサポートされていない場合、IMAP サーバーの変更を確認するまでの待ち時間（分）です。また、enable imap write が有効な場合、Discourse から IMAP サーバーへ変更を送信するまでの待ち時間でもあります。最小値は 1 分です。

これらの設定はデフォルトのままでよく、同期に問題が発生した場合に調整できます。

imap polling old emails - IMAP ボックスをポーリングするたびに更新される古いメール（処理済み）の最大数（0 の場合はすべて）。
imap polling new emails - IMAP ボックスをポーリングするたびに更新される新しいメール（未処理）の最大数。
imap batch import email - インポートモードをトリガーする新しいメールの最小数（投稿アラートを無効化）。

ラベル/タグを IMAP サーバーと同期させたい場合は、tagging enabled と allow staff to tag pms のサイト設定を有効にする必要があります。

次に、IMAP サーバーと同期させたいグループに入り、設定を入力します。

これらの設定はプロバイダー固有です。詳細については以下をご覧ください。設定と認証情報を入力したら「変更を保存」をクリックすると、IMAP プロバイダーのサーバーに対して認証情報が検証されます。成功するとメールボックスのリストが表示されるため、同期したいものを選択してください（この点に関するガイダンスもプロバイダー固有です）。

認証情報の検証が成功しなかった場合、ページにエラーメッセージが表示されます。明確に申し上げますと、入力されたユーザー名とパスワードのアカウントに代わってメールを送信するために使用されるのは、入力された SMTP サーバーであり、大量メール用に構成されたメインの Discourse SMTP ではありません。

最後に、app.yml ファイル内で env セクションに DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true を追加し、./launcher rebuild を実行してください。これでバックグラウンドワーカーが起動し、メールの同期が開始されます！

プロバイダー固有の情報

Gmail

アプリパスワードを生成する必要があります。そうしないと「セキュリティの低いアプリへのアクセス」をオンにする必要があり、Google はいずれこれを廃止する予定です。IMAP 設定では、Gmail アカウントのパスワードの代わりにこのパスワードを使用してください。詳細については Sign in with app passwords - Gmail Help をご覧ください。
SMTP と IMAP に以下の設定を使用してください。
- IMAP ポート: 987
- SMTP ポート: 587
- IMAP サーバー: imap.gmail.com
- SMTP サーバー: smtp.gmail.com
- SMTP と IMAP の両方で SSL を使用
強く推奨されます（まもなく UI 機能として実装予定）が、同期対象として「[Gmail]/All Mail」メールボックスのみを選択してください。
Discourse でトピックが削除された場合、Gmail 内のメールは即座に削除されず、ゴミ箱受信箱に移動されます。その後、Gmail 内の「30 日後に削除」機能が引き継ぎます。
Discourse トピックに適用されたタグは、Gmail でラベルを作成し、メールスレッドに適用します。Gmail のラベルは IMAP メールボックスでもあります！

制限事項

これはアルファ段階の機能であり、100% 完成して洗練されたものではありません。したがって、現在以下の制限が適用されます。

現在、IMAP プロバイダーとしてサポートされているのは Gmail のみです。 汎用的な IMAP 機能もありますが、動作する保証はありません。次は Outlook Online のサポートを大きな目標としています。
Gmail のゴミ箱から削除されたメールを復活させ、その状態を Discourse に反映させる機能は現在不安定です。
すでにメールが同期された後に同期メールボックスを変更することは推奨されず、多くの奇妙な問題を引き起こす可能性があります。
グループあたり同期できるメールボックスは 1 つのみです。
グループ間通信は未開拓の領域であり、うまく機能しません（例：それぞれ異なるグループ用に設定されている support@yoursite.com から team@yoursite.com へメールを送信する場合など）。

アルファ機能であるため、他の微妙な落とし穴や粗い部分がある可能性もあります。

フィードバックとロードマップ

Gmail でこの機能を使用している方からのフィードバックを歓迎します。バグや問題の修正を担当するのは私です。現在はデバッグが少し難しいですが、改善に取り組んでいます！

次に着手する予定の事項は以下の通りです。

デバッグ機能の強化：IMAP ログの表示や問題の特定を容易にする。
グループ電子メールインターフェースの改善：Gmail から選択可能なメールボックスを制限し、メールボックスの変更を抑制/禁止する。
複数のグループで同じ IMAP 詳細を使用することを防ぐための検証。
グループ IMAP 設定の保存方法の改善と、認証情報の検証の UX 向上。
Outlook サポート。

現在、問題点を解消している間、この機能はホストされた顧客には利用できません。

特別感謝

@dan と @j.jaffeux は、この大規模な機能の主要なコントリビューターであり、長期間にわたって取り組んできました。彼らの素晴らしい仕事のおかげで、この機能をこの段階まで持ち込み、この発表を行うことができました。

hellekin · 2020 年 8 月 12 日午前 7:09

これは同時に素晴らしいニュースでもあり、悲しいニュースでもあります。詳しく説明します。
まず、Discourse グループとの IMAP 統合が実現したことは素晴らしいニュースです。これにより、グループのアイデンティティ（正しい元のアドレスを使用）に関するいくつかの有用な解決策がもたらされ、複数のユーザーが同じ IMAP アカウントを利用しやすくなります（ネイティブでは十分にサポートされておらず、例えば共有された読み状態がないなど）。さらに、ActivityPub の受信トレイへの道も開かれます。

しかし、これは悲しいニュースでもあります。なぜなら、その実装が、フェデレーテッド・サービスを大規模に中央集権的なシステムに変えてしまったメール大手を優遇しているからです。大規模プロバイダーと連携することの魅力は理解できますが、この機能がベータ段階に達した際にあらゆるメールプロバイダーがサポートされるよう、プロバイダー固有の拡張機能よりも IMAP 標準が優先されることを願っています。

これを可能にしてくださり、心から感謝します。

sam · 2020 年 8 月 12 日午前 8:18

この機能が「アルファ」と見なされている大きな理由があります

私が傍観して観察した限り、IMAP の問題は、解釈の余地が非常に多いことに直面せざるを得ない点です。

私たちはもちろん、より多くのプロバイダーとの連携を実現したいと考えています。社内でのニーズとして Google を優先したのは、Discourse でも Google を実際に利用しているため、まず自社の課題を解決したかったからです。

より多くのプロバイダーに対応するための PR は歓迎します。それらが提出されない場合でも、時間が経過し、他のプロバイダーとの利用への要望が高まれば、サポートを追加していく予定です。

martin · 2020 年 8 月 12 日午前 8:52

これは正当な批判です。@sam が述べたように、私たちはまず Gmail に焦点を当てました。それは私たちが実際に使用しているものであり、私にとって最も関連性が高いからです。しかし、私の考えでは、私たちのベースとなる「汎用」プロバイダーは、RFC に 100% 準拠しているわけではなく、機能も完全ではありませんが、IMAP プロトコルには非常に忠実に従っています。詳細は https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb をご覧ください。この実装に追加が必要と思われるのは、アーカイブと削除の特別な処理のみです。削除については、現在は \Deleted フラグを設定し、EXPUNGE コマンドを送信するだけで済ませていますが、一部のメールクライアントでは、これを直接行うか、まずゴミ箱フォルダーに移動させてから EXPUNGE するなど、ユーザーが選択できるようにしています。IMAP におけるアーカイブの標準については確信が持てません。Gmail 専用のプロバイダークラスがあり、それらがこれらの汎用メソッドの一部を上書きしています。

Gmail は独自の特別な処理を行っており、Gmail IMAP 拡張機能も存在するため、より「汎用的」な IMAP サーバーやプロバイダーでテストできるようなご提案があれば、大変助かります。

また、sam が述べた通り、改善のためのプルリクエスト（PR）はいつでも歓迎します。そうでない場合、需要に合わせて対応を進めますが、次の大きなユースケースとして組織向けのこの種の機能が必要となるのは Outlook になるでしょう（Outlook にも独自の特別なルールがあります。例えば、アーカイブがフォルダーやメールボックスとして扱われ、ラベルのサポートがないなど）。

itsbhanusharma · 2020 年 8 月 12 日午前 8:57

非常に興味深そうですね。当社は最近、自前のメールサーバーからG Suiteへ移行したところですが、この統合により、顧客からの問い合わせへの対応や進捗管理のトラッカーの運用が格段に容易になるでしょう。@martin 様へ一点確認がございます。グループ受信トレイで受信したメッセージへの返信にGmailのSMTPを使用するのか、それともDiscourseのメール送信用に設定されたマスターSMTPを使用するのか、現時点では明確ではありません。プラグインの説明にはGmailのSMTPについても言及されていましたが、この点について改めて明確化をお願いできますでしょうか。

martin · 2020 年 8 月 12 日午前 8:58

返信はGmailのSMTPサーバーを使用して送信されます。これは、IMAP同期に使用されているメールアカウントに代わって返信を送信するためです。この点を明確にするため、元の投稿に追記いたします。

itsbhanusharma · 2020 年 8 月 12 日午前 9:02

それは本当に素晴らしいですね。これには多くのユースケースが思い浮かびます。@martin @dan @j.jaffeux さん、お疲れ様でした🙌

martin · 2020 年 8 月 17 日午前 12:10

簡単な更新情報です。先週、以下の 2 つの PR をマージしました。

まず、アーカイブや削除機能を使用するためにタグ付けを有効にする必要がなくなるよう修正しました：

github.com/discourse/discourse

FIX: Do not require tagging to be enabled for IMAP archive and delete (#10426)

master ← issue/imap-do-not-require-tagging-for-archive-and-delete

merged 04:04AM - 13 Aug 20 UTC

martin-brennan

+39 -9

Previously we did an early return if either SiteSetting.tagging_enabled or Site…Setting.allow_staff_to_tag_pms was false when updating the email on the IMAP server -- however this also stopped us from archiving or deleting emails if either of these were disabled.

次に、IMAP ログをすべてデータベースに書き込むように変更しました。これにより、確認が容易になります。5 日を超えるログは毎日ジョブを実行して削除されます：

StanD · 2020 年 8 月 21 日午後 10:47

とても素敵ですね！ありがとうございます。

付け加えると、Discourse がユーザー名とパスワードを受け付けるようにするには、Google メールアカウントで「アプリ用パスワード」を作成する必要がありました。

sunjam · 2020 年 8 月 23 日午後 3:25

Google 側で 2 段階認証を実行していますか？もしそうであれば、これは標準的な手順です。

StanD · 2020 年 8 月 23 日午後 4:34

はい。アプリパスワードを作成するために必要だったと思います（ただし、確信はありません）。

martin · 2020 年 8 月 23 日午後 11:40

これは OP で既に記載されていますさもないと、Gmail アカウントが「安全性の低いアプリ」を受け入れるようにするために、非常に複雑な手順を踏まなければなりません。いずれ、Google 向けに OAuth に対応する必要が出てくるでしょう。それが今後の方向性のようです。

StanD · 2020 年 8 月 24 日午前 1:19

おっと！私の読解力がダメだと書いたかな？

martin · 2020 年 8 月 24 日午前 1:25

問題ありません！重要なポイントなので、Gmail のリストの先頭に移動し、いくつかの警告インジケーターを追加しました。他の人の手間を省こうと教えてくださり、ありがとうございます

thoka · 2021 年 2 月 6 日午前 1:10

Dovecot IMAP サーバーとのメール同期が失敗する理由を理解しようとしています（残念ながら Ruby や Rails の経験はありません）。

imap_sync_logs を読むと、インポートデーモンがループに陥っていることがわかります：

UIDVALIDITY = 1612565899 は期待値 0 と一致しないため、IMAP キャッシュを無効化し、INBOX メールボックスのメールを再同期します

したがって、このケースでは @group.imap_uid_validity を更新すべきではないかと疑問に思っています：

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # (synced emails) and fetches new emails.
          
          # TODO: Use `Net::IMAP.encode_utf7(@group.imap_mailbox_name)`?
          @status = @provider.open_mailbox(@group.imap_mailbox_name)
          
          if @status[:uid_validity] != @group.imap_uid_validity
            # If UID validity changes, the whole mailbox must be synchronized (all
            # emails are considered new and will be associated to existent topics
            # in Email::Reciever by matching Message-Ids).
            ImapSyncLog.warn("UIDVALIDITY = #{@status[:uid_validity]} does not match expected #{@group.imap_uid_validity}, invalidating IMAP cache and resyncing emails for mailbox #{@group.imap_mailbox_name}", @group)
            @group.imap_last_uid = 0
          end
          
          if idle && !can_idle?
            ImapSyncLog.warn("IMAP server for group cannot IDLE or imap idle site setting is disabled", @group)
            idle = false
          end
          
          if idle
            raise 'IMAP IDLE is disabled' if !SiteSetting.enable_imap_idle

この値を手動で更新した後、インポートデーモンは別のループに陥ります。

Dovecot は以下で 'LABELS' をサポートしていません：

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # the email has moved mailboxes, we don't want to try marking as spam again next time
              ImapSyncLog.debug("Updating incoming ID #{incoming.id} uid data FROM [UID #{incoming.imap_uid} | UIDVALIDITY #{incoming.imap_uid_validity}] TO [UID #{matching_spam.uid} | UIDVALIDITY #{response.spam_uid_validity}] (SPAM)", @group)
              incoming.update(imap_uid_validity: response.spam_uid_validity, imap_uid: matching_spam.uid)
            end
          end
          
          def process_new_uids(new_uids, import_mode, all_old_uids_size, all_new_uids_size)
            ImapSyncLog.debug("Syncing #{new_uids.size} new emails (oldest first)", @group)
          
            emails = @provider.emails(new_uids, ['UID', 'FLAGS', 'LABELS', 'RFC822'])
            processed = 0
          
            # TODO (maybe): We might need something here to exclusively handle
            # the UID of the incoming email, so we don't end up with a race condition
            # where the same UID is handled multiple times before the group imap_X
            # columns are updated.
            emails.each do |email|
              # Synchronously process emails because the order of emails matter
              # (for example replies must be processed after the original email
              # to have a topic where the reply can be posted).

これにより Net::IMAP::BadResponseError が発生しますが、残念ながらログには記録されません。

そこで以下の点について疑問に思っています：

Dovecot のカスタムフラグのサポートは、Discourse との双方向同期に十分か
lib/imap/providers/detector.rb で Dovecot を検出する方法
Dovecot プロバイダーでラベル機能をエミュレートする方法

…

martin · 2021 年 2 月 7 日午後 11:39

グループ受信トレイの IMAP 同期は現在、初期段階の機能であり、Gmail のみがサポートされています。理論的には dovecot プロバイダーを作成することも可能ですが、数週間前に、メインコードの一部に Gmail 固有の機能が使われており、これらをプロバイダー固有のコードに移動させる必要がある箇所がいくつかあることに気づきました。申し訳ありませんが、この機能がもう少し完成度が高まるまでお待ちいただくことをお勧めします。

thoka · 2021 年 2 月 8 日午後 2:54

IIUC、'LABELS' は Gmail の非標準機能です。
Google IMAP と標準 IMAP の違いについて理解したいと考えています。

これまでの私のまとめは以下の通りです：

標準 IMAP	Google IMAP
アーカイブされたメールはサブフォルダに存在する	すべてのメールが 1 つのフォルダに存在するアーカイブされたメッセージには `"\\INBOX"` ラベルが付いていない
カスタムフラグはシステムフラグと共に保存される	カスタムフラグをラベルとして保存する

以下の対応で十分でしょうか？

標準 IMAP において、フラグをシステムフラグとカスタムフラグに分割することでラベルをエミュレートする
email_is_archived をプロバイダー側で処理する（例：「archived」フラグを追加してテストする）
標準 IMAP の同期を機能させる

これにより、以下の行に影響が出ます：

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
                update_email(incoming_email)
                incoming_email.update(imap_sync: false)
              end
            end
          end
          
          def update_topic_archived_state(email, incoming_email, opts = {})
            topic = incoming_email.topic
          
            topic_is_archived = topic.group_archived_messages.size > 0
            email_is_archived = !email['LABELS'].include?('\\Inbox') && !email['LABELS'].include?('INBOX')
          
            if topic_is_archived && !email_is_archived
              ImapSyncLog.debug("Unarchiving topic ID #{topic.id}, email was unarchived", @group)
              GroupArchivedMessage.move_to_inbox!(@group.id, topic, skip_imap_sync: true)
            elsif !topic_is_archived && email_is_archived
              ImapSyncLog.debug("Archiving topic ID #{topic.id}, email was archived", @group)
              GroupArchivedMessage.archive!(@group.id, topic, skip_imap_sync: true)
            end
          end

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # don't do any of these type of updates on anything but the OP in the
          # email thread -- archiving and deleting will be handled for the whole
          # thread depending on provider
          return if post&.post_number != 1
          topic = incoming_email.topic
          
          # if email is nil, the UID does not exist in the provider, meaning....
          #
          # A) the email has been deleted/moved to a different mailbox in the provider
          # B) the UID does not belong to the provider
          email = @provider.emails(incoming_email.imap_uid, ['FLAGS', 'LABELS']).first
          return if !email.present?
          
          labels = email['LABELS']
          flags = email['FLAGS']
          new_labels = []
          new_flags = []
          
          # Topic has been deleted if it is not present from the post, so we need
          # to trash the IMAP server email
          if !topic

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
            return @provider.trash(incoming_email.imap_uid)
          end
          
          # the topic is archived, and the archive should be reflected in the IMAP
          # server
          topic_archived = topic.group_archived_messages.any?
          if !topic_archived
            # TODO: This is needed right now so the store below does not take it
            # away again...ideally we should unarchive and store the tag-labels
            # at the same time.
            new_labels << "\\Inbox"
          
            ImapSyncLog.debug("Unarchiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for unarchiving too
            @provider.unarchive(incoming_email.imap_uid)
          else
            ImapSyncLog.debug("Archiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for archiving. this way we preserve
            # any new tag-labels, and archive, even though it may cause extra requests

この行は私には奇妙に思えます：

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # some providers need special handling for archiving. this way we preserve
              # any new tag-labels, and archive, even though it may cause extra requests
              # to the IMAP server
              @provider.archive(incoming_email.imap_uid)
            end
          
            # Sync topic status and labels with email flags and labels.
            if tagging_enabled?
              tags = topic.tags.pluck(:name)
              new_flags = tags.map { |tag| @provider.tag_to_flag(tag) }.reject(&:blank?)
              new_labels = new_labels.concat(tags.map { |tag| @provider.tag_to_label(tag) }.reject(&:blank?))
            end
          
            # regardless of whether the topic needs to be archived we still update
            # the flags and the labels
            @provider.store(incoming_email.imap_uid, 'FLAGS', flags, new_flags)
            @provider.store(incoming_email.imap_uid, 'LABELS', labels, new_labels)
          end
          
          def tagging_enabled?

Discourse のタグによってすべてのシステムフラグが上書きされてしまいます。
これはすべての IMAP フラグ（\Answered, \Deleted, \Draft, \Flagged, \Recent, \Seen および $Forwarded, $MDNSent, $SubmitPending, $Submitted）を適切に処理しているのでしょうか？

StanD · 2021 年 3 月 29 日午前 2:58

しばらく離れていましたが、再びこの件について確認しています。

reply-to ヘッダーが正しく機能するように設定する方法がわかりません。特定の Gmail アカウントと同期するグループを設定することはできますが、メールで返信しようとすると、reply-to アドレスが設定された Discourse の「通知用メールアドレス」になり、IMAP アドレスにはなりません。

何か見落としていることはありますか？

mognet · 2021 年 10 月 16 日午後 4:15

GoDaddyのメールプロバイダーで試しましたが、うまくいきませんでした。Gmailなら問題なく動作しますが、残念ながら自ドメインを使いたいと考えています。この機能は本番環境で使えるようになるまでの更新状況はいかがでしょうか？

pfaffman · 2021 年 10 月 16 日午後 5:58

参考までに、Gmail（有料版）では独自ドメインを利用できます。

トピック		返信	表示
Is it possible to use Discourse for e-mail? Support	5	1428	2021 年 9 月 9 日
Discourse settings: IMAP Support	1	68	2024 年 8 月 14 日
Discourse as a private email support portal Feature rfc , spec	45	23283	2016 年 5 月 10 日
Replacing Mailing lists: Email-In Feature	67	17149	2014 年 10 月 4 日
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	24220	2026 年 4 月 3 日

メリット

機能

始め方

プロバイダー固有の情報

Gmail

制限事項

フィードバックとロードマップ

特別感謝

関連トピック