IMAPポーリングが正常に機能せず、一部削除され、これらのいくつかの設定は、実装を目指していた頃の残骸のように思われると、別のチームメンバーが言っていました。
編集：それに関する声明を見つけました：IMAP support for group inboxes - #39 by martin
これは後退のように思えます。なぜなら、今日ではPOP3は時代遅れで実用的ではなく、人々は通常複数のメールクライアント（最低でも携帯電話とPC）を使用しているからです。そのため、DovecotインスタンスでPOP3リスナーを有効にする意味はないと思います。
しかし、メール受信コンテナやそのRubyスクリプトなしで、既存のPostfixに直接Discourseメール受信APIを実装することに成功しました。ただし、主にDiscourseメール受信コンテナで使用されているPostfix統合に従っています：mail-receiver/Dockerfile at main · discourse/mail-receiver · GitHub
/etc/postfix/main.cf：
# Discourse返信メールアドレスの場合、トランスポートマッピングを使用してデフォルトのトランスポートをオーバーライドします
transport_maps=hash:/etc/postfix/transport
/etc/postfix/transport
# 「discourse」という名前のサービスは、指定されたDiscourse返信アドレスへのメールのトランスポートエンドポイントとして使用されます
forum.reply@dietpi.com discourse:
/etc/postfix/master.cf
# 「discourse」トランスポートサービスを、（プライベートな）UNIXソケットでリッスンしているcurlへのパイプデーモンとして定義します
# パイプしてcurlを機能させるためには、特権なしまたはchroot化することはできません
discourse unix - n n - - pipe user=nobody:nogroup argv=/usr/bin/curl -X POST -F email=\u003c- -H Api-Username:system -H Api-Key:fooooobaaaaarbaaaaaaz https://dietpi.com/forum/admin/email/handle_mail
- そのため、トランスポートマッピングは返信アドレスへのメールをカスタムの
discourseサービスに渡します。 - 最適なパフォーマンスはUNIXソケットであるべきで、他に誰も使用する必要がないため、プライベートにすることができます（最初の
-）。 「プライベート」とは、ソケットが/var/spool/postfix/private/discourseにあり、Postfixのchrootディレクトリ/var/spool/postfix内でpostfixユーザーのみがアクセスできるディレクトリにあることを意味します。 - ただし、
pipeしてcurlを機能させるためには、特権なしまたはchroot化することはできません（n n）。 - 次に、
nobody:nogroupユーザー：グループを使用して権限を最小限に抑えます。 - 受信APIに従って、メールは
emailフォームフィールドに添付する必要があります。これはcurlの<-STDIN呼び出しで行うことができます。Api-UsernameとApi-Keyヘッダーを追加する必要があります。最初のヘッダーは通常systemであり、2番目のヘッダーはDiscourseで生成できます。receive_emails権限のみを持つ、きめ細かなAPIキーとして。その後、それぞれのHTTPエンドポイントを使用します。
受信コンテナによって行われる高速拒否ポリシーチェックを意図的にスキップします。
FromおよびToヘッダーの存在、送信者がドメインを持つ完全なアドレスであるかどうか、およびブラックリストにあるかどうかを確認します。ブラックリストは、BLACKLISTED_SENDER_DOMAINSコンテナ変数を通じてオプションで定義できます。そして、送信者と受信者のアドレスを別のDiscourse HTTP APIエンドポイントに送信して、受信者が設定された返信メールアドレステンプレートに一致するかどうか、および送信者アドレスが登録ユーザーに属しているかどうかを確認します。ただし、フォーラムが着信メールで新しい一時ユーザーを作成するように設定されている場合は除きます。これは、奇妙なことにデフォルトで有効になっていましたか？_- これのほとんど、およびそれ以上は、パブリックPostfix SMTP受信サービスによってチェックされます。すべてが
rspamdを通過するため、DKIM、SPF、およびDMARCチェックが含まれます。 - しかし最も重要なのは、最終的なDiscourseメール受信バックエンドによっても同じチェックが実行されることです。唯一の欠点：送信者はメールャーデーモン拒否/バウンスメールを受け取りませんが、無効な送信者/受信者の場合のエラーは代わりにDiscourseにログに記録されます。しかし、送信者と受信者が正しかった場合、メールの内容が期待どおりでない場合（特にMessage-IDヘッダーがない場合）、送信者はDiscourseから適切なメールを受け取ります。SMTP拒否/バウンスメールがないことは、IMOでは完全に問題ありません。なぜなら、それ以外の場合、実装は最小限のオーバーヘッドであり、メールごとにネットワークリクエストとバックエンド処理が1つ少なくて済むからです。
- 一般的に：
master.cfのコマンド引数でのスペースには注意してください。スペースをリテラルとして保持するための引用符は機能しません。代わりに、そのような引数は中括弧で囲む必要があります：{some arg with spaces}。しかし、この場合、どの引数にもスペースは含まれていません。ヘッダーキーと値の間のスペースはオプションです。
これまでのところうまく機能しており、Dovecotへのデフォルトの仮想トランスポート、および外部アドレスへの一部のメールを中継するために使用されるトランスポートマッピングとシームレスに統合されています。チームの全員が追加のメールボックスをサーバーに持つことを望む/必要とするわけではないためです。キャッチオールアドレスが仮想エイリアスマッピングで定義されている場合、Discourse返信アドレスをそのテーブルに追加し、それを自身にマッピングする必要があります（他のローカル仮想ユーザー/アドレスのように）。