メールサーバーを自分でセットアップしましたが、Discourse Dockerコンテナでそれを最大限に活用する方法を知りたいと思いました。
もちろん、SMTPの詳細と認証情報を設定することもできますが、SMTPサーバーは同じマシンで実行されているため、不要なオーバーヘッドのように感じます。
sendmail は機能しますが、Discourse はコンテナ内にあり、ホストの sendmail にアクセスできません。
フォーラムで何かを検索すると、DISCOURSE_SMTP_DOMAIN が認証情報なしで使用されている例が 1 つ見つかりました。コンテナ内で swaks を使用して同様のことを行うと機能します: How to get Discourse to work with Postfix - #18 by sonmicrosystems
この場合、リクエストはローカルホストから送信されるため、Postfix は認証なしで受け入れるため、デフォルトポートでの通常の SMTP 送信であると推測しますか？
他に方法をご存知の方はいらっしゃいますか？使用されている Ruby ライブラリは一般的にすべてをサポートしているようです: GitHub - discourse/mail: A Really Ruby Mail Library
Discourse の設定で、目に留まったのは Delivery method というフィールドです。
コンテナ YAML が DISCOURSE_SMTP_ADDRESS などでこれらを強制するため、GUI ではこれらの設定を変更できないと思いますか？しかし、配信方法の変数は見つかりません。
他に方法をご存知の方がいれば、それまでの間、通常の SMTP 送信ポート認証を設定します。最近追加された DISCOURSE_SMTP_FORCE_TLS には感謝しますが、まだどのサンプルにも含まれていません（含まれるべきです）。STARTTLS は許可せず、暗黙的/即時 TLS のみを使用するつもりです。
不要なオーバーヘッドとはどういう意味ですか？ DiscourseからSMTPサーバーにデータを送信する方法が必要ですよね？ そうではありませんか？
追伸：別のコンテナの場合は、理論的にはブリッジネットワークを使用して、ホスト名の代わりにSMTPコンテナ名を使用できますが、パフォーマンス上の利点はありません。
「いいね！」 2
ローカルSMTPサーバー経由でメールを送信するには、2つの方法があります。
- 提出ポート（例: 587、STARTTLSを使用、または465、暗黙的/即時TLSを使用）に接続して認証する => ネットワークリクエスト、
smtpdによるチェックと制限の適用
sendmailまたは類似のものを使用する。これはローカルのpickupコマンド（Postfixの場合）を呼び出し、ネットワーク接続を行わず、smtpd提出サービス用に設定されたすべてのチェックと制限をバイパスします。
後者はよりシンプルで高速であり、PHPメーラーやDiscourseが使用するこのRubyメールライブラリのような一般的なランタイムシステムやフレームワークに実装されています。また、認証はバイパスされ、プレーンテキストの資格情報をどこにも保存する必要がありません。つまり、この場合、SMTPサーバーはまったく使用されず、SMTPクライアントのみが使用されます。
確かに、Discourseが通常行うことと比較して、提出ポート接続にはサーバー負荷への顕著な影響はないはずです。後者の点は、例えば提出ポートでのsmtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,rejectルールを使用して、認証を行う前にループバックIP（デフォルト、mynetworks設定）からの提出を許可することで解決できます。コンテナからのリクエストが別のIPで表示された場合、mynetworksに追加できます。以前リンクしたトピックの場合も、おそらくこのように機能していたのだと思います。
Discourseを次に更新/再構築してSMTP設定が変更されたときに確認します。動作したら報告します。
しかし、「配信方法」設定が何であるか、そして他にどのような方法があるのかを知ることは依然として興味深いです。
Postfixはコンテナ内ではなくホストで実行されますが、ネットワークベースの認証であることに変わりはないため、大きな違いはありません。
ええ、後で考えたのですが、ホスト/他のコンテナからのsendmailなどがコンテナ内で機能しないのは当然です。なぜなら、Postfixの実行可能ファイル、ライブラリ、設定の広範な部分に直接アクセスする必要があるからだと思います。もちろん、コンテナにバインドマウントできるような魔法のソケットがあれば別ですが 
。
「いいね！」 2
sendmail のマイクロマネジメントにこんなに深く入り込むのは久しぶりです。Mailcow スタックを 1 つの VM に、Discourse を別の VM に搭載しています。楽しむため以外に、これほど深く掘り下げる価値があるかどうかはわかりません。
皆さんの冒険に幸運を祈ります。学んだことを報告してください。
「いいね！」 1
おそらくそうではないでしょう:sweat_smile:。しかし、私はある文脈においては完璧主義者であり、深く掘り下げてすべての詳細を学ぶことを楽しんでいます。Dovecot、Postfix、rspamd、dkimpy-milter、PostSRSdなどを設定するために、数晩かかりました。ステップバイステップで、利用可能なほぼすべての設定、デフォルトがなぜそうなっているのか、それを異なるようにしたいかどうか、そしてその理由などを学びました。しかし、今では、さまざまなメールサーバーガイドの著者のほとんどよりも、ほとんどのことをよく理解しているようです:face_with_tongue:。
このトピックを Installation > Hosting に移動します。公式のインストール手順を読んだことがあるならご存知の通り、独自のメールサーバーをホストしようとすることは推奨しません。メールは難しいです！
Discourse がシステムでメールサーバーをホストできるかどうかとどう関係があるのかわかりません。もちろん、これは理論的にはメールを送信する別の方法を開きます。
ただし、メールの受信（別のトピック）には影響があります。メール受信コンテナをホストできないため、少なくともポート 25 で直接リッスンすることはできません。しかし、Postfix の設定で Discourse のメール受信 API を直接使用することは、わずか 2 ～ 3 行で済みました。Is there a way to only IMAP polling for incoming emails - #2 by MichaIng
しかし、同意します。上記で述べたように、メールサーバーを適切にセットアップするのは簡単な作業ではありませんでした。しかし、学ぶのは非常に興味深いです 
。
「いいね！」 1
はい！確かに、やりがいがあり、興味深いですね。過去には、あらゆる種類のサービスをインストールして自分で実行しようとした、自分自身の冒険を経験しました！
このトピックを、あなた自身を含む、勇敢な将来の旅行者のために、あなたの学びで更新していただけることを嬉しく思います。ただし、Support カテゴリは、サポートされているインストール、Discourse コア、および公式プラグインとコンポーネント用であることを忘れないでください。
「いいね！」 1
nineb
9
何です。Dovecoatは良いです。なぜPostfixなのですか？なぜDovecoat Eximではないのですか？
Postfix の何が問題なのでしょうか？それは私が最初に読んだメールサーバーの設定ガイドの一部であり、パイプラインの早い段階でスパムやボットアクセスを削減するための内部フィルターオプションは、良い議論のように思えました。
さて、少し話はそれますが、Discourse からの sendmail/pickup の使用についてです。
これを解決済み/回答済みにマークします。Discourse コンテナが、どのサーバーであっても、ホストの sendmail にアクセスできないことは理にかなっています。そのため、SMTP サブミッションを使用する必要があります。これには、Postfix の Docker コンテナの IP 範囲経由などで認証でき、Dovecot の passdb/userdb 認証をスキップできます。
system
(system)
クローズされました:
11
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
