# メール拒否のより良い処理
**URL:** https://meta.discourse.org/t/better-handling-of-email-rejection/163834
**Category:** Feature
**Created:** [2020 年 9 月 12 日午後 4:07 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834 "2020-09-12T16:07:49Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 12 日午後 4:07 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/1 "2020-09-12T16:07:49Z")
メールが実際には拒否されるべきではないのに、却って拒否されてしまう奇妙なケースが多数見られます。つまり、ユーザーからサポート宛てに送信されたメールが、私たちに届かないことがたまにあるのです。
例えば、[mac.com](http://mac.com) のアドレスからサポート宛てに送信されたメールは、本文がないという理由（Email::Receiver::NoBodyDetectedError）で拒否されることがよくあります。しかし、これらのメールには実際には本文が含まれていることが多く、パース処理に問題がある可能性があります。
誤った拒否の原因を修正することとは別に、新しい拒否が発生した際に通知を受け取れるようにできれば幸いです。そうすれば、拒否が適切だったかどうかを確認できます。
その方法としては、すべての拒否に対してスタッフにアラートを送信するオプションを追加するか、単にすべての拒否メールをスタッフに CC するオプションを設定するなどが考えられます。
そうでなければ、Discourse のバックエンドで「拒否されたメール」リストを常にポーリングして、サポートへの着信メールを見逃さないようにする必要がありますが、これは手間がかかり、不要な作業です。
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [2020 年 9 月 12 日午後 7:10 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/2 "2020-09-12T19:10:47Z")
> [@jrivettcsa](#):
>
> [mac.com](http://mac.com) アドレスからサポート宛に送信されたメールは、本文がないとして拒否されることがよくあります（Email::Receiver::NoBodyDetectedError）。しかし、実際にはこれらのメールには本文が含まれていることが多く、パース処理に問題がある可能性があります。
具体的な例に焦点を当てる方が良いでしょう。「よく」拒否されるとのことですが、メールの内容に特定の傾向は見られますか？もし常時問題であれば、`mac.com` からのすべてのメールが失敗するはずです。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 12 日午後 8:17 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/3 "2020-09-12T20:17:55Z")
まあ……「よく」というのは「うっとうしいほど頻繁に」という意味です。私たちの主な懸念は、サポートチームからの対応がないと人々が誤解して怒ってしまうことです。
私が気づいた事例のパターンを調べてみました。当初は [mac.com](http://mac.com) のメール処理に問題があるのではないかと考えましたが、その後、[mac.com](http://mac.com) アドレスを持つ約 30 人のユーザーに同様の問題は見られないことが分かりました。
また、[mac.com](http://mac.com) にウェブメールクライアントがあれば、HTML メールを非標準的な方法で処理している可能性もあると考えました。しかし、そもそも [mac.com](http://mac.com) にウェブメールクライアントがあるのかも確信がありません。
最近の事例ではメール本文に引用行しか含まれていなかったことに気づき、原因を特定できたかと思いましたが、その後のテストで Discourse はそのようなメールを正しく解析することが分かりました。
今後、ログを確認してこのような事態がどれほど頻繁に発生しているか、そしてパターンがあるかどうかを調べます。Discourse がたまにこのようなミスを犯す可能性が限りなくゼロでない以上、アラートメールを送ることは簡単な対策だと思いました。
調査結果はここで共有します。
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [2020 年 9 月 12 日午後 8:19 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/4 "2020-09-12T20:19:54Z")
> [@jrivettcsa](#):
>
> もし [mac.com](http://mac.com) にウェブメールクライアントがあれば、HTML メールを非標準的な方法で処理しているかもしれないと思いました。しかし、[mac.com](http://mac.com) にウェブメールクライアントがあるかどうかさえ確信が持てません。
[Mac.com](http://Mac.com) のメールアドレスは実際には [iCloud.com](http://iCloud.com) アカウントです。Apple は 5〜6 年前に、[Mac.com](http://Mac.com) と [me.com](http://me.com) のアカウントを iCloud に自動的に移行しました。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 12 日午後 9:02 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/5 "2020-09-12T21:02:47Z")
ご清説ありがとうございます。つまり、[mac.com](http://mac.com) アドレスからのメールで問題が発生した場合、[i.com](http://i.com) やその他の iCloud アドレスにも同様の影響が出るということですね。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 14 日午前 8:19 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/6 "2020-09-14T08:19:09Z")
明確なパターンはありません。却下理由がはっきりしない、または誤っていると思われる事例が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から送信された却下メールが送信者の迷惑メールフォルダに移動されたのか、それとも単に無視されたのかは、依然として不明です。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2020 年 9 月 14 日午後 1:55 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/7 "2020-09-14T13:55:43Z")
> [@jrivettcsa](#):
>
> なぜアドレスが悪いかというと？
サポートなど、あなたが処理していないアドレス宛てに送信されたからです。
私には、「ここに存在する」と言っているのに「誰もない」と表示される部分だけが、バグの可能性があるように思えます。考えられるのは、相手が古くて壊れたメールクライアントを使用していることです。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 14 日午後 3:50 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/8 "2020-09-14T15:50:22Z")
> [@pfaffman](#):
>
> サポートなど、あなたが管理していないアドレス宛てに送信されたようです。
いくつかのケース（Email::Receiver::BadDestinationAddress）を確認しましたが、多くの場合、顧客からの正当な返信のようです。受信者は「replies+longidentifier@discourse.site.com」という形式になっています。Discourse が送信者に送るアラートメールでは、そのメールが参照されているトピックに関連付けられたアドレスとは異なるアドレスから送信されたと示唆されています。これが理由だと思われますが、このようなケースでは、それでもスタッフにアラートを送りたいと考えています。
> [@pfaffman](#):
>
> 私には、存在すると述べているのに本文がない部分だけが、バグの可能性があります。
確かにバグのように見えますが、その修正を望む一方で、このようなケースは常に発生しうると感じています。したがって、メール解析のバグを追及することに加えて、スタッフへのアラートメールを送ることで、それまでの間にタイムリーなサポートを提供できるようにしたいと考えています。
> [@pfaffman](#):
>
> 可能性として、古い壊れたメールクライアントを使用していることに関連しているかもしれません。
私もそう思っていました。次にこのようなケースが発生した際には、顧客に使用しているメールクライアントについて尋ねるつもりです。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 14 日午後 4:04 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/9 "2020-09-14T16:04:56Z")
私が言いたいのは、メールが拒否された場合、それは悪意ある行為ではなく、サポートを求めているだけの場合もあるということです。
確かに、Discourse が拒否するメールの中には、拒否すべきものも確かにありますが、サポートメールを見逃すリスクを冒したくないため、拒否リストをポーリングせざるを得ません。
その間、混乱した送信者は、当社のウェブサイトの連絡フォームなど、他の手段で連絡を取ることを余儀なくされます。
大規模なサイトでは、メール拒否のアラートが多すぎて対応しきれない可能性もありますが、私たちにとっては、怒った顧客に対処するよりも、それらを処理する方がはるかに簡単です。
また、Discourse は拒否メールを送信者に送信し、有用な情報を提供していますが、それらのメールがスパムフォルダに入ることもあり、影響を受けた顧客をさらに混乱させていると思います。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2020 年 9 月 14 日午後 5:21 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/10 "2020-09-14T17:21:01Z")
それは面倒ですね。その一部を解決する方法は、[IMAP support for group inboxes](https://meta.discourse.org/t/imap-support-for-group-inboxes/160588) かもしれません。
ただし、間違ったメールボックスから返信してしまう問題は、どのように解決すればよいかわかりません。（それに、どちらの立場に立っても、お問い合わせフォームは本当に嫌いです！）
---
### Author:  [@justin](https://meta.discourse.org/u/justin)
#### Post date: [2020 年 9 月 14 日午後 5:43 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/11 "2020-09-14T17:43:51Z")
> [@jrivettcsa](#):
>
> いくつか確認しました（Email::Receiver::BadDestinationAddress）。これら多くは顧客からの正当な返信のようで、宛先は [replies+longidentifier@discourse.site.com](mailto:replies+longidentifier@discourse.site.com) という形式になっています。Discourse が送信者に送信するアラートメールには、そのメールが関連トピックに関連付けられたアドレスではなく、別のアドレスから送信されたことが示されています。これが理由だと思われますが、このようなケースでもスタッフに通知が届くようにしたいと考えています。
ユーザーがメールが送信されたアドレスとは異なるアドレスから返信した場合、これは想定内の動作です。
もしこれらのメールへの返信を別のメールアドレスから許可すれば、他のユーザーになりすましてアカウントを悪用されるリスクが生じます。Meta のサポートメッセージでも、この問題に時折直面しています。
> [@pfaffman](#):
>
> （それに、連絡フォームは本当に嫌いですね。どちらの立場に立っても！）
連絡用メールフォームが使用されている場合、通常はメールから送信され、Reply-To ヘッダーが設定されます。つまり、前述の同じ問題に直面することになります。
私個人としては、ここで素晴らしい解決策が見当たりません。チームの誰かに良いアイデアがあるかもしれません。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 14 日午後 6:19 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/12 "2020-09-14T18:19:47Z")
> [@justin](#):
>
> ユーザーがメールが送信されたアドレスとは異なるアドレスから返信する場合、これは想定内の動作です。
はい、おっしゃる通り、それらの返信を却下するのは理にかなっています。しかし、このようなことが起きた際には、私にも通知が届くようにしたいと考えています。
> [@justin](#):
>
> お問い合わせフォームが使用されている場合、通常はメールから送信され、Reply-To ヘッダーが設定されます。つまり、上記で述べたのと同じ問題に直面することになります。
お問い合わせフォームに言及したのは、Discourse が処理するサポートメールアドレスを通じてお客様が私たちに連絡できない場合、やむを得ず代替手段を探すことになり、それは望ましくないからです。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2020 年 9 月 14 日午後 6:29 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/13 "2020-09-14T18:29:46Z")
> [@jrivettcsa](#):
>
> しかし、このことが起きた際には通知を受け取りたいと考えています。
それをどう実現すればよいか、確実な方法はわかりません。`/admin/email/rejected` をウォッチすることはできますが、実際のアラートを受け取るには現在、プラグインが必要です。
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 14 日午後 6:37 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/14 "2020-09-14T18:37:06Z")
> [@pfaffman](#):
>
> それがどうやって実現できるかよくわかりません
私も同じくわかりません。だからこそ、この件を機能リクエストとして投稿したのです。
> [@pfaffman](#):
>
> `/admin/email/rejected` を監視することは可能です
はい、理解しています。ただ、そのページにアクセスして数分ごとにリフレッシュボタンを押すのは、かなり非効率的に思えます。
> [@pfaffman](#):
>
> 実際のアラートを得るには、現在ではプラグインが必要です
プラグインでも構いませんが、なぜこの機能を Discourse 本体に追加できないのか疑問です。私には、これは明らかに実装すべき機能に思えます。Discourse はすでにサイト管理者やスタッフに対して様々なアラートを送信しています。「メール拒否時のアラート」という設定をデフォルトで無効にするだけでも、多くのサイトでは問題ないはずです。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2020 年 9 月 14 日午後 6:39 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/15 "2020-09-14T18:39:05Z")
> [@jrivettcsa](#):
>
> だから私はこれを機能リクエストとして投稿したのです。
ええと、はい。すみません。🤷♂️
---
### Author:  [@jrivettcsa](https://meta.discourse.org/u/jrivettcsa)
#### Post date: [2020 年 9 月 16 日午前 10:45 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/16 "2020-09-16T10:45:07Z")
別の例として、顧客が購入時に発生した問題を報告するためにサポート宛にメールを送信したとします。Discourse がそのメールを拒否し、[Email::Receiver::InactiveUserError] を返しました。
Discourse が非アクティブなユーザーからのメールを拒否するのは理にかなっていることは理解していますが、同時にサポート担当者に通知されれば、すぐに顧客に連絡して、何が起きたのか、どう対処できるのかを説明することが可能になります。
一方、拒否リストを頻繁にポーリングしない限り、顧客は自動システムに起因する 2 つの問題に直面することになり、サポート担当者はそのことに気づきません。この段階での人的介入は重要ですが、再度、拒否リストを手動で確認する必要があるため、対応に遅延が生じる可能性があります。
管理者にメール拒否の通知を送信できない技術的な理由はありますか？
---
### Author:  [@adrelanos](https://meta.discourse.org/u/adrelanos)
#### Post date: [2021 年 5 月 1 日午前 8:49 UTC](https://meta.discourse.org/t/better-handling-of-email-rejection/163834/17 "2021-05-01T08:49:35Z")
メールでの返信が短すぎる場合（例：「OK」など）、ユーザーに対して誤ったエラーメッセージのメールが返送されてしまいます。この件については、ここで報告しました：[Wrong Error Message for too short replies for Reply-by-Email](https://meta.discourse.org/t/wrong-error-message-for-too-short-replies-for-reply-by-email/188702)
また、そのような拒否は `/admin/email/rejected` にも記録されません。どこか適切な場所に記録されるようになると良いのですが。