機能リクエスト: 要約メール用の別アカウント

貢献 特徴
1

初心者からの報告ですが、今日はすべてのメールが事実上 シャットダウン され、ユーザーは登録、パスワードの復元、またはメールでのログインができなくなりました。これは、レガシーフォーラムの移行後に週次ダイジェストが開始され、sidekiq キューに 30 万件以上のメールが溜まっていたためです。そのため、メールでのログイン、登録、パスワードの復元などを試みたユーザーはメールを受け取れず、完全に 詰み 状態になってしまいました（彼らの言い方では）。

この問題は、メール中継に GMAIL を使用していることに起因しています。無料の GMAIL はこのような SMTP 中継に制限を設けており、結果として GMAIL が一日中当社の送信を遮断してしまいました。

将来的にこの機能の実装をお願いしたいと考えています（他に解決策がある場合は別ですが）。

提案

管理者がダイジェスト用の異なるメール中継を設定できるようにする、app.yml の変数セットを追加してください。

セットアップ中に、ダイアログで「ダイジェスト用に別の SMTP サーバーを設定しますか？」と表示し、必要であればユーザーが同じ SMTP 中継を使用できるようにします。

理由

ダイジェストの活動が活発な大規模フォーラムでは、パスワード復元、ログイン、登録などの重要なタスクに使用する SMTP 中継とは別に、ダイジェストメールを中継するオプションがあると良いでしょう。

現時点では、すべてのダイジェスト機能を無効にしています。過去 X 日間の設定で制限する方法を見つけましたが、本日確認した際のデフォルト値は 365 日でした。何らかの理由で、移行されたサーバーには 30 万件以上のメッセージがキューイングされていました。

議論

大きな問題ではありませんが、ダイジェスト と ミッションクリティカルなメール を分離できることが望ましいと考えます。なぜなら、ミッションクリティカルなメール の キュー優先度 が高く設定されていても、ダイジェストの数が多すぎて SMTP 中継がブロックされれば、ミッションクリティカルなメール もブロックされてしまうからです。

さらに、同様の状況に直面しているフォーラムがあり、SMTP メールが機能しない理由に気づいていない場合もあるかもしれません。実際には前述の理由でブロックされていた可能性があります。

ご検討いただき、ありがとうございます。

TangentialDuck

「いいね！」 2
2

無料の Gmail を使用して Discourse からメールを送信することはサポートされていない点にご注意ください。これも Google の利用規約によるものです。この方法で Gmail を使用することは、unsupported-install（非サポート環境）に近い状態です。

この機能リクエストの実装がどのように意義を持つのか理解に苦しみます。もしサポートされたメール機構を使用していたなら、この事象は発生しなかったはずです。

3

それは誤りです。

当社はGoogleドメインを所有しており、無料のメールは長年サポートされており、現在もサポートされています。

20年にわたりフォーラムを運営してきた者に対して、もう少し寛容になってください。私たちは昨日突然生まれたわけではありませんよ、@Stephen。

「いいね！」 1
4

その通りです。当社のメールガイドを無視するコミュニティは、この問題に頻繁に直面します。

Google は、Gmail アカウントからトランザクションメールを送信することを許可していません。これにより、アカウントが永久に失われる事例も確認されています。また、有料の G Suite アカウントでも、1 日あたりのトランザクションメール数に厳格な制限が設けられています。このような状況に置かれるのはあなただけではありませんが、Google が設定した利用規約を回避する技術的な解決策を提供することはできません。

「いいね！」 1
5

GSuiteアカウントにログインし、利用規約を確認しましたが、おっしゃっていることは事実ではありません。

@Stephen、あなたは早計すぎます。「Googleの利用規約を回避する」機能を求めたわけではなく、私の投稿に言葉を付け加えないでください。

あなたは早計すぎて、@Steven に対して誤って人を非難しているようです。だから、もっと慎重な他の人々に私のリクエストに返信してもらえませんか？

6

ここでの発言に矛盾が見られます：

Gmail は G-Suite とは異なります。有料の G-Suite アカウントには以下の制限があります：

制限の種類 制限
1 日のメッセージ数
1 日の送信制限*		 2,000（トライアルアカウントは 500）

無料の Gmail アカウントは常に 500 通の制限があります。

これは Google の利用規約であり、上記とは関係ありません。「今まで動作していた」と「許可されている」には明確な違いがあります。過去 7 年間で多くのユーザーがこの試みを行いましたが、成功した例は一度もありません：

このトピックに関する追加の読み物

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

推奨プロバイダーのリストを含むメール設定ガイドがあります。これを必ずしも従う必要はありませんが、Gmail や GSuite を意図されていない方法で使用することはサポートできません。

「いいね！」 1
7

はい、@Steven さん、私が投稿する前からそのことはすべて知っていました。

私の意見では、Mosaic ブラウザが存在する前からオンラインに参加してきた人の知識を過小評価するのはやめ、返信の仕方も慎重にするべきです。他人に対して非難めいた発言をするのは、Discourse やテクノロジー全般の楽しみを損なうものです。

最初は「無料の GMAIL は存在しない」と言われました（それが間違いだと私は知っていました）。そして、私を何らかの悪意ある活動に関与していると非難されました。その後、あなたは調査を進め、GSuite には 1 日 2,500 件の制限があることを発見しましたが、私はこの GSuite アカウントを長年管理しているため、そのことは以前から知っていました。

すぐに行動を起こして人を非難し、詳細について誤っている場合は、謝罪すべきです。

単純な機能リクエストを投稿して、このような否定的なエネルギーに応答しなければならないのは、本当に楽しくありません。

8

これは、GsuiteではなくGmailを使用していることを示唆しており、これは規則違反です。多くの人々、特にシステム管理の知識がない人々がGmailの使用を試みることがありますが、これは利用規約に違反します。その事実を伝えることは良いことであり、無礼や失礼ではありません。

しかし、あなたはGsuiteを使用しており、それは完全に問題ありません。これはあなたの最初の投稿からは判別できませんでした。そのため、あなたが不当に扱われているように見えるのです。

ただし、Gsuiteは、あなたが説明しているようなトラフィックの多いフォーラムでは実際には機能しません。あなたは、1日あたり2500件のメッセージに制限されているメールサービスでもDiscourseが動作するようにする新しい機能の追加を求めています。

そのためのプラグインを作成することは可能ですが、簡単ではありません。Discourseの開発に詳しい人であれば、数日かかるでしょう。

解決策は、必要な量のメールを送信できるメールサービスを使用することです。

「いいね！」 2
9

フォローアップですが、このトピックは重複しています。複数の SMTP サービスに関するリクエストは以前にも提出されています：

ここでのユースケースは少し異なりますが、問題はダイジェストの設定ミスから発生しました。Unix.com には 138,062 人のユーザーがおり、パスワードリセットなどのミッションクリティカルな用途であっても 1 日あたりのメール送信上限が 2,000 件だとすると、毎日やり取りできるユーザーは全体の 1.8% しかいません。

編集：実際の制限を反映するため、2,500 から 2,000 に修正しました

「いいね！」 1
10

だからこそ、@pfaffman さん、オンライン上では、技術やその動機について他者に対して非難めいた発言をすぐに口にするのは避けるべきなのです。通常、銃を引金にかけ発砲する前に、まず質問をすべきでしょう、笑。

はい、私は GSUITE ではなく GMAIL と書きましたが、このドメインを数十年前に作成した当時は GSUITE というものは存在せず、単に GMAIL と呼ばれていました。さらに、私が正確な用語を使わなかった理由は、私の機能リクエストが GMAIL とは全く無関係だからです。それは完全に脇道にそれた議論です。

もし私が（あるいはあなたが）望むなら、ここにいる多くの人がそうであるように、任意のサーバーにアクセスし、apt install postfix または apt install sendmail と入力するだけで、15 分もかからずに独自の SMTP リレーを稼働させることができます。

どうか、ダイジェスト処理からの大量トラフィックの移動という主題を、GMail 対 GSuite 対「どうでもいいもの」のような議論に変えないでください。apt install postfix は些細なことです。

問題は信頼性です。これは基礎中の基礎です。

mission critical（ミッションクリティカル） なメールを、digests（ダイジェスト） と同じ SMTP リレー上で運用するのは、私の望むところではありません。だからこそ、この機能リクエストを求めたのです。

どうか、私が mission critical なアプリ の構築について何を話しているか分かっている以上、私のリクエスト内容に焦点を当てた議論を続けましょう。

繰り返しになりますが：

mission critical なメール を digest メール と同じ SMTP リレー上に置いたくないのです。これは良い考えであり、システムをより堅牢にするものです。

GMAIL や GSuite、あるいは MonkeyMail などの非常に脇道にそれた議論からは離れましょう。メールサーバーは私の機能リクエストとは無関係なので、言及してしまったことをお詫びします。

落ち着いて、他者に親切にしましょう。何か投稿されても、理解できないことや混乱することがあれば、他人を攻撃するのではなく質問してください @Steven

私は 10 分もあれば SMTP リレーを構築できます。私たち全員できます。apt install postfix で完了です。GSuite や postfix、あるいは donkey kong mail を使いたいかどうかは、他者ではなく私次第です。私が言ったように…

核心部分…（再掲）

mission critical なメール を digest チャンネル とは異なるサーバー上に置く方が、より信頼性が高いのです。これは非常に繁忙なサーバーにおける基礎中の基礎です。

apt install postfix は SMTP リレーを構築します。私は、信頼性とパフォーマンスの理由から、mission critical なメール（パスワードリセット、登録メール、ログインメール）を digests とは異なるチャンネルで扱える機能リクエストを求めています。

11

@Steven

それは本質的な点ではありません。それは脇道にそれています。

余談ですが、実際には以前は 50 万人以上のユーザーがいましたが、私が整理しました :slight_smile:

私が言いたいのは、ミッションクリティカルなメール をダイジェストトラフィックとは別のチャネル（SMTP リレー）で扱うことです。

確かに、このシンプルな概念、そしてなぜ 2 つのチャネルの方が優れているのかという概念を理解するのは非常に簡単ですよね？

この議論は、私の機能リクエストの本来の意図から大きく逸れてしまっています。

投稿して質問してしまったこと自体を後悔しています… :frowning:

私の最初の投稿以降のこの議論は、私見ですが、全く的を外していると思います。

12

あなたを助けようとしている人々の能力を過小評価しないでください。誰もあなたに反対しているわけではありません。

「いいね！」 3
13

これがこのトピックに関する最後の投稿になります。

GSuite についてですが（これは私の機能リクエストの主旨とは全く関係ありません）

  • ユーザーが 24 時間以内に送信できるメッセージの最大数は 10,000 件です。ただし、これは G Suite アカウントのユーザーライセンス数によって変動する場合があります。
  • 登録された G Suite ユーザーは、24 時間以内に 10,000 人を超える一意の受信者にメッセージをリレーできません。

参照：Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

しかし、私にとってはこれも完全にトピックから外れています。なぜなら、仮に GSuite が SMTP リレーを通じて 10 億通以上のメールを 1 日に送信することを許可したとしても、mission critical（ミッションクリティカル）なメールとdigest email（ダイジェストメール）では、異なる SMTP リレーチャネルを希望するからです。

これが主旨です。

ありがとうございます。今後のアップグレードでこれを検討してください。これは比較的簡単に追加できると思います。

この機能リクエストはpersonality（個性）に関するものでも、email providers（メールプロバイダー）の優劣や詳細に関するものでもありません。

私の機能リクエストは、信頼性に関するものであり、mission critical emailをdigest channelから分離することにあります。

以上、失礼します… :slight_smile:

14

Discourse を開発している人々は、動作するメールシステムを持っています。彼らは、複数の信頼性の低いメールシステムを使いたい人のために機能を追加するつもりはありません。もし必要ならプラグインを開発することもできますが、開発が難しく、保守も面倒になります。

Postfix のインストールは簡単かもしれませんが、現在では正常に動作するメールサーバーを運用するのは、私が Sendmail と uucp を Linux に移植した当時よりもはるかに困難です。もしメールサーバーの運用が簡単なら、あなたはすでに動作するメールサーバーを持っているはずで、2 つも必要とはしないでしょう。

私はそうは思いませんが、Discourse プラグイン開発については私よりもはるかに詳しいかもしれませんね。

「いいね！」 3
15

一つ簡単な回避策として、そのような問題が多数発生している場合は、ダイジェストメールをグローバルに「無効」にすることもあります。すでに最良の提案がなされているかもしれませんが、制限を課さないメールプロバイダーを使用することをお勧めします。例えば、Mailgunなどです。
このようにすれば、誰もが満足するでしょう（何らかの理由で特定のメールプロバイダーの使用に制限がある場合を除きます）。

「いいね！」 4
16

同意します。@neounix が最初に投稿した内容には多くの矛盾があり、その後のレスポンスでも詳細が次々と変わっています。

上記で私が強調した部分ですが、無料アカウントの制限についてはすでにこのトピックの他の箇所で文書化されています。継承された「無料」の G Suite アカウントも同様の制限があります。これが有料の G Suite アカウントである場合、上記のコメントは誤解を招くものであり、それが私の返信の理由です。

再び、ここでどのサービスを使用しているかが明確ではありません。無料ティアのレガシー Google Apps を使用している場合、1 日あたりのユーザーあたりの受信者数は 500 人に制限され、無料の Gmail プロダクトと同じです。有料の G Suite アカウントを使用している場合、Google SMTP リレーサービスを使用する必要があります。制限は 1 日あたりユーザーあたり 1 万件ですが、それでも十分ではなく、特にパスワードリセットを必要とする 13 万人以上のユーザーがいる場合、特に問題です。移行時にユーザーを削減できたのは素晴らしいことですが、それが実際にどれほど重要かはわかりません。

ここであなたがイライラしているのは理解できます。あなたのテストでは、キューイングされるダイジェストを見逃していました。これにより、パスワードをリセットしてアカウントに復帰しようとするすべての人にとって、実質的な利用不能期間が発生しました。

上記で数回、私があなたの言葉を曲解していると指摘されましたが、私が確認した限りでは、あなたの提供した情報に基づいた一貫した応答です。もし同意しないのであればお詫びしますが、投稿を再読しても、いったいどのプロダクトを使用しているのかは依然として不明確です。

余談ですが、私は @Stephen であり、@Steven ではありません。あなたは全く異なるユーザーをタグ付けして通知しています。

「いいね！」 3
17

もしそうであれば、Marketplace に予算を明記して投稿することで資金調達を行ってください。また、メールの件数を減らすための非常に優れた提案もいくつかあります☝ので、それらを活用することをお勧めします。

「いいね！」 3
18

現時点では、結局はダイジェスト機能を完全に無効化しました。その経緯を改めて説明します。

私たちにはステージングサーバーも存在します。Discourse はデフォルトで週次ダイジェスト（365 日のウィンドウ）を有効にするため、インストール直後（out-of-the-box）に、このステージングサーバーも先週ダイジェストを開始してしまいました（私たちは予想していなかったのです）。LOL

この事態が起きる（あるいは起きうる）ことを事前に知らなかったため、ステージングサーバーでバックアップを試みたところ、システムがそれを拒否しエラーを返しました。管理コンソールに表示された正確なエラーメッセージは忘れましたが、メールキューを指す手がかりがあったことを覚えています。

その手がかりを頼りに sidekiq を確認すると、まさにその通り、デフォルトのダイジェスト設定（「オン」かつ「過去 365 日」）により、キューに 30 万件以上のダイジェストメッセージが溜まっていることが分かりました。

そこで、コマンドラインからメールキューをクリアし、再度バックアップ管理パネルにアクセスすると、バックアップは正常に実行されました。

Discourse のメールシステムは sidekiq に基づいて構築されているため、これが「ミッションクリティカルなメール」と「ダイジェストメール」を異なるチャネル（異なるメールサーバー）で設定するのが難しい理由だと思われます。当初考えていたほど単純ではないようです（単に環境内に 2 つのメールサーバーを設定すればよい、というわけではありません）。

ここがおかしいところです… LOL

当初は、デフォルトでダイジェストを有効にするのではなく、無効にしておくのが良いアイデアだと思いました。365 日のログインウィンドウを伴う有効状態よりも。しかし、このエラーは私の完全な責任であり、meta にそのような提案を投稿するのは良くないと思い直しました。LOL。

Discourse をインストールした際、移行されたすべてのユーザー（旧 vB3 フォーラムから）の last_seen_at がデフォルトで約 50 年前に設定されていました。

私はデータベースに直接アクセスし、すべてのユーザーの最終閲覧日を「10 日前」に手動で変更しました！LOL。当時はダイジェスト設定について何も知らず、移行後に全ユーザーの最終閲覧日が 50 年前になっているのは移行エラーだと思っていました。ハハ…私の間違いでした。これにはちゃんと理由があるのです。

Discourse が大規模な週次ダイジェスト処理を開始し、私のステージングサーバーで「最終閲覧日を 10 日前に変更」という DB ハックを行い、それを本番環境にエクスポートしたため、本番およびステージングサーバー双方の sidekiq がオーバーロードされてしまいました。これがこの問題の原因となった過ちです。

多くの人は、Postgres にログインして私のようにハックしたり、以下のような操作を行ったりしません。

UPDATE users SET last_seen_at "today minus 10 days"

…多くのユーザーがいるレガシーな移行において。

したがって、彼らはこのような大規模なダイジェスト問題に直面することはないでしょう。

LOL

私の users テーブルに対する UPDATE ハックによって、このような緊張状態を作り出してしまい、申し訳ありません。

それでも、mission critical なメールと digest メールを 2 つの異なるメールサーバーに配置するのは合理的だと思います。しかし、sidekiq を見ていると、まだ sidekiq の経験がない私には、それを簡単に実行する方法が明確ではありません。

とはいえ、フォーラムを Discourse へ移行する方（これは素晴らしいアイデアです）へのアドバイスとして、users テーブルの last_seen_at はデフォルトのままでおくことをお勧めします。:slight_smile:

「いいね！」 1
19

通常、ステージングインスタンスと外部の世界の間に Mailhog を配置することをお勧めします。この種のシナリオでは非常に優れています。

「いいね！」 4
20

ステージングインスタンスに DISCOURSE_DISABLE_DIGEST_EMAILS を追加しようとしています。ただし、メールの無効化が非スタッフに設定されているため、これは大きな問題ではありません。

「いいね！」 2