hartz
(adam hartz)
1
これは単なる私の個人的な欠陥なのかもしれませんが、リプライ・バイ・メールを設定した後、いくつかのエラー報告について少し混乱しています。
誰かが自分のアカウントに関連付けられていないメールアドレスからメッセージに返信した場合、（セルフホスト型の Discourse インスタンスで）表示されるエラーメッセージが間違っている可能性があります。これは、誤ったアドレス宛てに送信した場合に受け取るべきメッセージのように見えますが、実際には認識されていないアドレスから送信された場合のメッセージのようです。
その場合、私が受け取るメッセージの件名は Email issue – Unknown To: Address であり、本文は以下のようになっています：
_申し訳ありませんが、[“SNIP”]（件名：Re: Help Please）宛てに送信されたメールメッセージが正常に機能しませんでした。
宛先のメールアドレスのいずれも認識されていません、またはメール内の Message-ID ヘッダーが変更されています。スタッフから提供された正しいメールアドレス宛てに送信していることを確認してください。_
返信の From: アドレスをアカウントに関連付けられたアドレスに一致させることで、問題が解決したようです。
この動作を変更する簡単な方法はありますか？何か設定を間違えているのでしょうか？
（本来期待しているのは、From: ヘッダーを完全に無視し、代わりに こちら で議論されているようにリプライキーを使用するオプションです。そのような機能の実現の可能性はありますか？）
hartz
(adam hartz)
2
ああ、もしかすると、これは公開トピックではなくプライベートメッセージ（PM）への返信だからかもしれません。Discourse は、そのメールアドレスを送信した人物（有効なユーザーとして認識されていない）がそのアドレスに送信できるはずがないと考えているのでしょう。
それなら、送信元アドレス（From:）ではなく宛先アドレス（To:）が無効とマークされている理由も説明がつきますね。
それまでの間、そのメッセージの文言を変更して、「From:」の問題である可能性もあれば、「To:」の問題である可能性もあることを明確にしました。
なぜ Discourse は、対象サイトの有効なユーザーアカウントと一致しないランダムなメールアドレスを受け入れるのでしょうか？
Discourse で投稿するには、常に有効な認証済みアカウントを持っている必要があります。
（ステージングされたユーザーには例外がありますが、これは Discourse の PM を通じてメール受信箱を処理する場合に限定されたものです）
riking
(Kane York)
4
これは、権限エラーがスタックのどこかで「見つかりません」エラーに変換され、その後、メールコードが「見つかりません」のメッセージを使用しているためです…
hartz
(adam hartz)
5
reply_id（トピックと返信した人の両方をマッピングしているように見える）だけで識別子として十分であり、reply_id のなりすましはメールアドレスのなりすましよりも難しいため、正しいメールアドレスから送信されなくても実質的には同等の強度を持つと主張することもできます。
しかし、私は実際にはそのように主張しようとしているわけではありません。ここであなたが言っていることは完全に理にかなっています。そして、考えてみると、この挙動につながっているのは確かにエッジケースだと気づきました（SSO で大学のメールアドレスを使ってアカウントを作成していますが、人々はそれらを他のアドレスに転送し、そのアドレスから返信することがあります）。
私の本当の疑問は、その場合にユーザーが受信するエラーメールの内容についてです。それは誤解を招く可能性があるように思えます。真の問題、あるいは少なくともこの場合エラーメールを受け取る人が制御できるのは、宛先アドレスではなく、「差出人」アドレス（およびアカウントに関連付けられたアドレス）だと私は考えています。
とにかく、私はすでに以下の回避策を講じています：
- そのメッセージの内容を変更すること（Discourse がこれほどカスタマイズ可能なのは素晴らしいですね！）
- メールで返信したい場合はメールアドレスを変更するよう人々に伝えること
しかし、この潜在的な混乱を踏まえると、どのような状況でどのようなエラーメッセージを送信するかについて何か変更を加えるべきかどうか疑問に思っています。
その答えが「いいえ、現状で問題ありません」であっても、全く問題ありません。
現時点では、ユーザーごとに代替メールアドレスのサポートが部分的に実装されています。
@sam さん、@eviltrout さん、ユーザーが二次的なメールアドレスを追加できるように、これをもう少し正式なものにするのはいつになるでしょうか？これは 2.5 のロードマップに追加すべきでしょうか？
sam
(Sam Saffron)
7
まずは管理画面のユーザーページでこれを表示し、2.5 用のメールアドレスを確認・追加できるようにすることから始めるべきだと考えます。その後、十分にテスト済みの Rake タスクが利用可能になったことに伴い、管理画面にユーザーのマージを行うための基本的な UX を追加するのはいかがでしょうか。
Discourse が、極めて容易に偽装可能な From: ヘッダーを信頼・検証する理由がいまだに理解できません。
Reply-Id ヘッダーは、悪意のある人物が推測・把握できないため、有用な検証手段となります。
From: ヘッダーを検証するだけでは、異なるメールアドレスから返信した場合（予想以上に一般的なエッジケース）に、正当なユーザーがメールによる投稿で混乱を招く拒否を受け、困惑することになります。
メールはアイデンティティです。「異なるメールアドレス」とは、「異なる DNA」と言っているのと同じです。
私は多くのメールアドレスを持っており、私のユーザーの中にも同じような人がいます。
ここで喧嘩をふっかけようとしているわけではありません。単に、この問題で少し傷ついているだけです。なぜなら、この問題が私のフォーラムの重要なメンバーの一人が、もう貢献しないことを選ぶ原因となったからです。
それなら、ユーザーあたりの複数メールアドレス設定の進展を訴えるべきでしょう。上にスクロールして、少し読んでみるのはどうですか？
残念ながら、提案されている機能が私の Discourse インスタンスで発生している問題を解決できるかどうかはわかりません。
私のケースでは、そのユーザーは市民団体の会長です。彼女は 2 つのメールアドレスと、それぞれに対応する 2 つの Discourse アカウントを持っていました。1 つは個人のアイデンティティを表し、もう 1 つは市民団体 behalf での「公式」投稿用でした。
彼女はメールで返信する際、頻繁に「間違った」メールアドレスから返信してしまい、その結果返信が拒否されていました。
上記で議論されている機能は、1 つの Discourse アカウントに複数のメールアドレスを割り当てることを想定していると思われますが、当然ながら 1 つのメールアドレスに複数の Discourse アカウントを割り当てることは許可しないでしょう。したがって、残念ながら私のユースケースには対応できないと思われます。
downey
(Michael Downey)
14
アカウントを統合して、一方のメールアドレスをセカンダリにすることはできませんか？
できない場合、残念ながら現在Discourseには、ユーザーがどの「帽子」を被っているかを思い出させるためのツールはありません。
技術的には可能ですが、ユーザーが2つの異なるアイデンティティ（個人／市民社会を代表して）で投稿できるようにすることは意図的な設計です。
downey
(Michael Downey)
16
はい。確かに、そのような状況に陥る人もいますが、これは「エッジケース」というより「コーナーケース」と呼ぶべきかもしれません 
この人は実質的に 2 つのアイデンティティを持っているが、何らかの理由で両方が同じメールアカウントに集約されてしまっている、という理解で合っていますか？もしそうなら、Discourse だけでなく、他の場所でも同様の問題に直面しているはずです。もしかすると、メールクライアント側で処理した方が適しているケースかもしれません。
私も仕事用のメールアカウントに業務関連のエイリアスを持っていますが、クライアントは返信先の「From」アドレスを、メールが送られてきたアドレスに一致させるようになっています…
同意します。これは特殊なケースであり、もし彼女がそれほど著名なユーザーでなかったなら、それほど大きな問題にはならなかったでしょう。
Discourse アカウントを 2 つ作成するために、Gmail のドットハックを使用し、彼女が Gmail の受信トレイに 2 つのメールアドレスを作成できるようにしました。その結果、彼女は 2 つの Discourse アカウントを作成できました。
彼女がフォーラムの投稿にメールで返信する際、Gmail は必ずしも Discourse が期待するメールアドレスのバリアントを使用するとは限りません。
私の考えでは、返信 ID が有効であれば、Discourse はその返信を受け入れるべきです。
riking
(Kane York)
18
ドットハックは非常に脆弱で、代わりにプラスアドレスを使ったほうがはるかに快適に使えるでしょう。
両方のアカウントがプラスアドレスを使用し、裸のアドレス（プラス記号なしのアドレス）を直接使用するアカウントがない場合、From: アドレス切り替え機能は正常に動作します。切り替えの設定を忘れたとしても、メールが誤ったアカウントに送信されるのではなく、単に拒否されるだけになります。
ドットではなくプラス記号を使うことで、フィルタの設定もはるかに明確になりますね 
dan さん、これをあなたのリストに追加してくれますか？
dan
(Dan Ungureanu)
21
複数のメールアドレスのサポートを改善するプルリクエストを提出しました：
