メール受信者における「Resent-*」の尊重

特徴
1

Discourse を E メールアーカイブとして使用するワークフローがあります。グループメールアドレスがあり、エージェントは顧客とのメールスレッドを開始する際にそのアドレスを Cc に追加します。

これは、顧客が Cc や Reply-To ヘッダーをすべて無視してエージェントに直接返信した場合に問題が発生します。エージェントは、その E メールをグループメールアドレスにバウンス（再送信）する必要があります。バウンスは、Discourse が元の E メールを元のヘッダー、タイムスタンプなどを含めてアーカイブするため、ここで推奨される方法です。

E メールのバウンスは、メッセージ全体をコピーし、Resent-From および Resent-To ヘッダーを追加することで行われます。これらは残念ながら Email::Receiver によって無視されます。Resent-* を通常のフィールドに単純に追加するだけでよいはずです。

実装を開始し、create_incoming_email がフィールドを考慮するようにしました。これにより、Discourse の受信メールリストで、Resent-To から取得した受信者を含むメールを確認できるようになりました。

しかし、get_all_recipients も Resent-* フィールドを尊重するようにするには、まだ成功していません。mail フィールドの %i() 配列に resent-to resent-cc resent-bb を追加しましたが、これらのフィールドからの受信者が返されないようです。

この変更のための PR を作成できるように、どんな助けでも歓迎します！

2

これは非常に危険で、なりすましにもつながりやすい機能のように思えます。再送信者はどのように認証されることを想定していますか？

また、Discourse には既に転送されたメールの処理機能が存在します。

3

「これはかなり危険で、なりすましを起こしやすい機能のように思えます。再送信者はどのように認証されるのですか？」

Resent-From ヘッダーを使用します。しかし、それは実際には重要ではありません。重要なのは、元の送信者を認証できるかどうかであり、再送信者ではありません。

「また、Discourse にはすでに転送メールの処理機能があります。」

引用された転送のみです。これにはいくつかの問題があります。

  • 元のメールはアーカイブされず、本文の引用されたコピーのみがアーカイブされます。
  • 添付ファイルとして転送されたメッセージ（完全なヘッダー付き）のサポートはありません。
  • 不完全です（転送されたメールを認識するために、件名に特別な接頭辞に依存しています）。
4

それは具体的にどのように行われるのですか？再送信者が自分だけに送信されたとされるメールを偽造したらどうなりますか？

5

「それは具体的にどのように機能するのですか？もし再送信者が自分だけに送信されたとされるメールを嘘をついて完全に捏造したらどうなりますか？」

その場合、彼らは Resent- の情報をすべて省略して、最初からなりすますことができます。自分に最初に送信されたと主張する必要もなくなるでしょう。

Resent- ヘッダーが実際には 何もしない ということについて、あなたは誤解していると思います。メールサーバーが SPF や DKIM をチェックする際にも考慮されないため、再送信されたメールになりすますことは、元のメールになりすますことと同じくらい困難です。

私のケースでは、外部の知らない人からの再送信メールは、SPF違反によりスパムフィルターによってブロックされます。エージェントがメールを Discourse に再送信する私のシナリオが機能するのは、それらが私たちのメールサーバーに認証した後、これらのチェックから除外されるためです。

したがって、Discourse が Resent-To ヘッダーを使用できるようにすることは、単なる利便性の機能にすぎません。なぜなら、通常のメールクライアントが以前受信したメールのなりすましコピーを作成する方法だからです。認証に関しては何も変わりません。

「いいね！」 1