メールの改訂：テストrakeタスクの出力

開発
1

メール：タスクと関連コードを確認し、各障害コードパスをテストしてエラーテキストを修正しました。

また、DISCOURSE_SMTP_ENABLE_STARTTLS=false の設定の影響は（ほとんど）ないことを発見しました。これを設定しても STARTTLS は無効にならず、実際には接続時に TLS と共存できます（DISCOURSE_SMTP_FORCE_TLS=true）。

そのため、以下の対応を行いました。

これをマージする前に、ダッシュボードで DISCOURSE_SMTP_ENABLE_STARTTLS=false が設定されている場合に管理者に警告を表示するのが適切だと思います。これを設定したが、実際には必要なく STARTTLS に依存しているセルフホスティングユーザーが少なくとも一人いると想像しています。

「いいね！」 4
2

それは良い仕事のように聞こえます！私が（気づいたと思う）一つのことは、レイクタスクが実際には実際の送信と同じコードを使用していないことです（たとえば、/admin/emailテストページから）。UXでは機能したがレイクタスクでは機能しなかった（またはその逆だった？）ケースがあったと確信しています。

それがあなたの心に新鮮なうちに、実際に送信するときにDiscourseと同じコードを使用していることを確認できれば、それは素晴らしいことです。

「いいね！」 2
3

それについても取り組んでおり、キューに入れられたメールジョブが失敗した際のログの改善にも取り組んでいます。:+1:

「いいね！」 4
4

フォーラムで何か私が行うべきことはありますか？

Screenshot_20251105_151945_Firefox
Screenshot_20251105_151945_Firefox1847×588 152 KB

「いいね！」 4
5

いいえ、このアラートはホスティングには表示されないはずです。修正します。いつもご報告ありがとうございます。

「いいね！」 5
6

@supermathie この変数が設定されているすべてのサイトのすべての管理者にPMを送信する価値はありますか？現在の問題チェックシステムがそれを行いますが、ほとんどの場合、これはnilの効果しかないため、ここで正当化されるかどうかはわかりません。理想的には、管理ユーザーにpingを送信せずにダッシュボードにのみ表示したいのですが、現在の問題チェックの構造がこのユースケースをサポートしているかどうかわかりません。

7

多くの管理者がメール設定について混乱していることを考えると、実際に STARTTLS に依存しているのに、この変数が設定されている可能性が非常に高いと思います。

おそらく、誰もこれを設定すべきではありません。

誤検知の警告がある方が、誰かのメール設定がサイレントに壊れるよりも良いです。

代替案は、チェックを削除して、変数が何も行わないように無力化することです。

「いいね！」 1
8

発信SMTPサーバーがlocalhost（つまりDiscourseドメイン名と一致する）の場合、TLSは同じマシンであるDockerコンテナとホスト間で不要なため、警告が表示されないようになると良いでしょう。

「いいね！」 1
9

この場合、環境から変数を削除できます。

STARTTLSが提供されている場合にのみ使用されます。

「いいね！」 1