ユーザーのメール未着のトラブルシューティングを行っていたところ、そのアカウントで「メールの無効化」アクションがログに記録されているのを発見しました。このアクションをキャンセルまたは取り消す方法はありますか？
また、ユーザーのメールが無効化された場合、これは「送信されたメール」または「スキップされたメール」のログに反映されますか？それとも「メールの無効化」アクションのみに記録されますか？
以下の議論の続きです：ログ内の「メールの無効化」アクションの意味とは？:
「メールの取り消し」アクションは、あるユーザー宛てに複数のメールが配信失敗（バウンス）した際に発動します。メールがバウンスするたびに、ユーザーの「バウンススコア」が、サイト設定の soft bounce score または hard bounce score で設定された値に応じて増加します。ユーザーのバウンススコアがサイトの bounce score threshold 設定（デフォルトは 4）に達すると、「メールの取り消し」アクションが発動します。
このアクションを取り消すには、ユーザーの管理ページに移動し、ページ上部付近にある「Bounce Score」行の「Reset」ボタンをクリックしてください。
Reset ボタンをクリックしなかった場合でも、reset bounce score after days で設定された期間が経過すると、Discourse が自動的にユーザーのバウンススコアをクリアします。この設定のデフォルト値は 30 日です。この期間が過ぎると、Discourse は再度そのユーザー宛てにメールを送信しようとします。
サイトの bounce score threshold を超えたユーザー宛てにメールが送信されなかった場合、「Skipped」ログにエントリが追加されます。Skip Reason は「Exceeded bounce_score_threshold」に設定されます。
ありがとうございます。つまり、ユーザーXへの最近のメールのスキップログに「Exceeded bounce_score_threshold」が表示されている場合、そのユーザーに対して以前に「メールの取り消し」アクションが実行されたと推測でき、その逆も成り立ちますか？
背景として、Discourseインスタンスからのメールをあるユーザーが受信できていません。そのユーザーは非常に有能な方なので、スパムフォルダを確認したなどの報告を信頼しています。以前にそのユーザーのバウンススコアをリセットしましたが、今日になって初めてログで「メールの取り消し」に気づきました。
これは興味深いですね。私は、メールがまだ無効化されていないユーザーのバウンススコアがリセットされると（Mailman のように）思っていました。最も近い設定としては、この期間を 10 年程度に設定することでしょうか！
私の知る限り、Discourse は常にユーザーのバウンススコアをリセットし、その後そのユーザーにメールを再送信しようとします。一時的なバウンスと永続的なバウンスの処理の違いは、永続的なバウンスの場合、サイト設定の「ハードバウンススコア」で設定されたデフォルト値 2（通常は 1）によってバウンススコアが増加する点です。
それによって問題は解決しますが、意図しない結果を招く可能性があります。例えば、最近の Gmail 障害により「バウンススコア閾値」を超えてしまったユーザーは、バウンススコアが自動的にリセットされるまで 10 年間待たなければならなくなります。
Mailman 2 は、バウンス設定や閾値のデフォルト値がより高く設定されていますが、一度閾値に達すると購読解除されてしまいます。どちらの立場にも一理あると思います。追記：詳細は覚えていませんが、ある時点で管理用メールへの返信機会が提供され、それによりバウンススコアがリセットされ、リストへの登録が維持される仕組みだったと記憶しています。
Discourse をセルフホストしている多くの人はおそらく Mailgun を利用していると思われますが、Mailgun は一度「永続的失敗」が発生するとそのメールアドレスを抑制リストに登録し続けるため、Discourse のより寛容なアプローチは無視されてしまいます。
どうやら Mailgun の API を使用してその抑制リストを取得できるようですし、Discourse の設定と同期させることも可能かもしれません。
今日、Google から「誰かがあなたのパスワードを取得したことが判明しました」という明確なメールが届きました。この件が今回の「停止」と関連しているのではないかと疑問に思います。
これに気づきました：Configure VERP to handle bouncing e-mails - #166
これは bounce_score_threshold_deactivate 設定の削除に関するものです。これが誤りだったのではないかと思い始めます。デフォルト設定が達成しにくかったなら、その値を下げるべきだったはずです。
大規模なフォーラムにとって、その削除が招く意図しない結果の一例は、長年にわたり無効なアドレスへのメール送信が徐々に増加することです。それにより、外部サービス（Mailgun のように、1 回のpermanent failバウンスでアドレスを抑制するサービスなど）とのトラブルや、IP レピュテーションの低下につながる可能性があります。
現状では、私の理解が間違っていなければ、Discourse は送信できていると認識しているメールが、Mailgun の抑制リストにより拒否されているだけという状態です。Discourse のアプローチと Mailgun のアプローチを同期させることはできません。
それを忘れていました。bounce_score_threshold_deactivate 設定が、Discourse の無効なアドレスへのメール送信を試みることを防ぐために機能していたかどうかは確信が持てません。問題は、ユーザーが bounce score threshold に達すると、reset bounce score after days 設定で指定された期間が経過するまで、Discourse はそのユーザーへのメール送信を停止するものの、その期間が過ぎるとユーザーのバウンススコアがリセットされ、このプロセスが再び始まってしまう点です。
この問題に対する最善の解決策が何なのかは確信が持てません。私の理解が正しければ、Discourse サイトは時間とともに、無効なアドレスへのメール送信を試みる回数が徐々に増えているように思われます。
これには少なくとも二つの側面があります。一つは、メール送信元（例：localhost）がこの方針に同意することを前提とした、Discourse にとって適切なポリシーは何かという点です。もう一つは、この方針に同意しないメール送信サービス（例：Mailgun）とどのように同期を取るかという点です。
Discourse には既に、「送信に問題が発生したため、メールアドレスを確認してください」といった趣旨のメッセージがあると思います。Discourse は、バウンスするメールをより積極的無効化するアプローチと、メール送信の欠如に関する閉じられないサイト通知の導入を検討する必要があるかもしれません。
外部送信サービスとの同期はより困難です。Mailgun は、API から抑制リストを取得できる可能性があると述べていますが、API を通じてアドレスを削除できるかどうかは現時点では不明です。もし両方が可能であれば、Discourse はアドレスが抑制リストに入った時点でそれを無効化し、管理者やユーザーが Discourse 内で手動の手順（確認メールへの返信など）を実行した際に、抑制リストから削除することができるようになります。これに関連するもう一つの課題は、プロバイダーごとに異なるルールが存在する可能性があることです。
編集：上記の取り消し線は、Mailgun の API を使用して抑制リストからメールアドレスを削除できることが判明したため追加されました：https://documentation.mailgun.com/en/latest/api-suppressions.html#delete-a-single-bounce