メールが実際には拒否されるべきではないのに、却って拒否されてしまう奇妙なケースが多数見られます。つまり、ユーザーからサポート宛てに送信されたメールが、私たちに届かないことがたまにあるのです。
例えば、mac.com のアドレスからサポート宛てに送信されたメールは、本文がないという理由（Email::Receiver::NoBodyDetectedError）で拒否されることがよくあります。しかし、これらのメールには実際には本文が含まれていることが多く、パース処理に問題がある可能性があります。
誤った拒否の原因を修正することとは別に、新しい拒否が発生した際に通知を受け取れるようにできれば幸いです。そうすれば、拒否が適切だったかどうかを確認できます。
その方法としては、すべての拒否に対してスタッフにアラートを送信するオプションを追加するか、単にすべての拒否メールをスタッフに CC するオプションを設定するなどが考えられます。
そうでなければ、Discourse のバックエンドで「拒否されたメール」リストを常にポーリングして、サポートへの着信メールを見逃さないようにする必要がありますが、これは手間がかかり、不要な作業です。
「いいね！」 2
具体的な例に焦点を当てる方が良いでしょう。「よく」拒否されるとのことですが、メールの内容に特定の傾向は見られますか？もし常時問題であれば、mac.com からのすべてのメールが失敗するはずです。
「いいね！」 2
まあ……「よく」というのは「うっとうしいほど頻繁に」という意味です。私たちの主な懸念は、サポートチームからの対応がないと人々が誤解して怒ってしまうことです。
私が気づいた事例のパターンを調べてみました。当初は mac.com のメール処理に問題があるのではないかと考えましたが、その後、mac.com アドレスを持つ約 30 人のユーザーに同様の問題は見られないことが分かりました。
また、mac.com にウェブメールクライアントがあれば、HTML メールを非標準的な方法で処理している可能性もあると考えました。しかし、そもそも mac.com にウェブメールクライアントがあるのかも確信がありません。
最近の事例ではメール本文に引用行しか含まれていなかったことに気づき、原因を特定できたかと思いましたが、その後のテストで Discourse はそのようなメールを正しく解析することが分かりました。
今後、ログを確認してこのような事態がどれほど頻繁に発生しているか、そしてパターンがあるかどうかを調べます。Discourse がたまにこのようなミスを犯す可能性が限りなくゼロでない以上、アラートメールを送ることは簡単な対策だと思いました。
調査結果はここで共有します。
「いいね！」 2
Stephen
(Stephen)
4
Mac.com のメールアドレスは実際には iCloud.com アカウントです。Apple は 5〜6 年前に、Mac.com と me.com のアカウントを iCloud に自動的に移行しました。
ご清説ありがとうございます。つまり、mac.com アドレスからのメールで問題が発生した場合、i.com やその他の iCloud アドレスにも同様の影響が出るということですね。
明確なパターンはありません。却下理由がはっきりしない、または誤っていると思われる事例が21件あります。
- 1件：「メールを処理できません：本文が最近投稿した内容と非常によく似ています」
- 8件：「メールを処理できません：Email::Receiver::BadDestinationAddress」- これらは少し不可解です。なぜアドレスが不良なのでしょうか？
- 3件：「メールを処理できません：Email::Receiver::NoBodyDetectedError」- 2件は本文が正常に見えるようですが、1件は単に「本文なし」と表示されています。
- 1件：「メールを処理できません：Email::Receiver::TooShortPost」
- 6件：「メールを処理できません」
- 1件：「メールを処理できません：申し訳ありませんが、新規ユーザーは投稿に画像を1枚までしか含めることができません」
- 1件：「未処理のエラー：構文エラー、認識できない式：#xxxxxx-email:product at company dot com」
これらのうちいくつかは、顧客による正当なコミュニケーションの試みに関わるものでした。Discourseから送信された却下メールが送信者の迷惑メールフォルダに移動されたのか、それとも単に無視されたのかは、依然として不明です。
pfaffman
(Jay Pfaffman)
7
サポートなど、あなたが処理していないアドレス宛てに送信されたからです。
私には、「ここに存在する」と言っているのに「誰もない」と表示される部分だけが、バグの可能性があるように思えます。考えられるのは、相手が古くて壊れたメールクライアントを使用していることです。
いくつかのケース（Email::Receiver::BadDestinationAddress）を確認しましたが、多くの場合、顧客からの正当な返信のようです。受信者は「replies+longidentifier@discourse.site.com」という形式になっています。Discourse が送信者に送るアラートメールでは、そのメールが参照されているトピックに関連付けられたアドレスとは異なるアドレスから送信されたと示唆されています。これが理由だと思われますが、このようなケースでは、それでもスタッフにアラートを送りたいと考えています。
確かにバグのように見えますが、その修正を望む一方で、このようなケースは常に発生しうると感じています。したがって、メール解析のバグを追及することに加えて、スタッフへのアラートメールを送ることで、それまでの間にタイムリーなサポートを提供できるようにしたいと考えています。
私もそう思っていました。次にこのようなケースが発生した際には、顧客に使用しているメールクライアントについて尋ねるつもりです。
「いいね！」 1
私が言いたいのは、メールが拒否された場合、それは悪意ある行為ではなく、サポートを求めているだけの場合もあるということです。
確かに、Discourse が拒否するメールの中には、拒否すべきものも確かにありますが、サポートメールを見逃すリスクを冒したくないため、拒否リストをポーリングせざるを得ません。
その間、混乱した送信者は、当社のウェブサイトの連絡フォームなど、他の手段で連絡を取ることを余儀なくされます。
大規模なサイトでは、メール拒否のアラートが多すぎて対応しきれない可能性もありますが、私たちにとっては、怒った顧客に対処するよりも、それらを処理する方がはるかに簡単です。
また、Discourse は拒否メールを送信者に送信し、有用な情報を提供していますが、それらのメールがスパムフォルダに入ることもあり、影響を受けた顧客をさらに混乱させていると思います。
「いいね！」 1
pfaffman
(Jay Pfaffman)
10
それは面倒ですね。その一部を解決する方法は、IMAP support for group inboxes かもしれません。
ただし、間違ったメールボックスから返信してしまう問題は、どのように解決すればよいかわかりません。（それに、どちらの立場に立っても、お問い合わせフォームは本当に嫌いです！）
「いいね！」 1
justin
(Justin DiRose)
11
ユーザーがメールが送信されたアドレスとは異なるアドレスから返信した場合、これは想定内の動作です。
もしこれらのメールへの返信を別のメールアドレスから許可すれば、他のユーザーになりすましてアカウントを悪用されるリスクが生じます。Meta のサポートメッセージでも、この問題に時折直面しています。
連絡用メールフォームが使用されている場合、通常はメールから送信され、Reply-To ヘッダーが設定されます。つまり、前述の同じ問題に直面することになります。
私個人としては、ここで素晴らしい解決策が見当たりません。チームの誰かに良いアイデアがあるかもしれません。
「いいね！」 2
jrivettcsa
(Jeff Rivett)
12
はい、おっしゃる通り、それらの返信を却下するのは理にかなっています。しかし、このようなことが起きた際には、私にも通知が届くようにしたいと考えています。
お問い合わせフォームに言及したのは、Discourse が処理するサポートメールアドレスを通じてお客様が私たちに連絡できない場合、やむを得ず代替手段を探すことになり、それは望ましくないからです。
「いいね！」 1
pfaffman
(Jay Pfaffman)
13
それをどう実現すればよいか、確実な方法はわかりません。/admin/email/rejected をウォッチすることはできますが、実際のアラートを受け取るには現在、プラグインが必要です。
jrivettcsa
(Jeff Rivett)
14
私も同じくわかりません。だからこそ、この件を機能リクエストとして投稿したのです。
はい、理解しています。ただ、そのページにアクセスして数分ごとにリフレッシュボタンを押すのは、かなり非効率的に思えます。
プラグインでも構いませんが、なぜこの機能を Discourse 本体に追加できないのか疑問です。私には、これは明らかに実装すべき機能に思えます。Discourse はすでにサイト管理者やスタッフに対して様々なアラートを送信しています。「メール拒否時のアラート」という設定をデフォルトで無効にするだけでも、多くのサイトでは問題ないはずです。
「いいね！」 3
jrivettcsa
(Jeff Rivett)
16
別の例として、顧客が購入時に発生した問題を報告するためにサポート宛にメールを送信したとします。Discourse がそのメールを拒否し、[Email::Receiver::InactiveUserError] を返しました。
Discourse が非アクティブなユーザーからのメールを拒否するのは理にかなっていることは理解していますが、同時にサポート担当者に通知されれば、すぐに顧客に連絡して、何が起きたのか、どう対処できるのかを説明することが可能になります。
一方、拒否リストを頻繁にポーリングしない限り、顧客は自動システムに起因する 2 つの問題に直面することになり、サポート担当者はそのことに気づきません。この段階での人的介入は重要ですが、再度、拒否リストを手動で確認する必要があるため、対応に遅延が生じる可能性があります。
管理者にメール拒否の通知を送信できない技術的な理由はありますか？
「いいね！」 2
adrelanos
(Adrelanos)
17
メールでの返信が短すぎる場合（例：「OK」など）、ユーザーに対して誤ったエラーメッセージのメールが返送されてしまいます。この件については、ここで報告しました：Wrong Error Message for too short replies for Reply-by-Email
また、そのような拒否は /admin/email/rejected にも記録されません。どこか適切な場所に記録されるようになると良いのですが。
「いいね！」 1
