6

以前 Google App Engine で尋ねたこの質問によると、標準の電子メールのすべての情報にアクセスできる場合、フィールドだけFromでなく、すべてのヘッダーと MIME 情報にもアクセスできる場合、その 2 つの受信電子メールを確認するにはどうすればよいですか同じアドレスのメールは、実際には同じ差出人からのものです。ToSubjectBodyFrom

私がこれまでに検討したこと:

  • メールの送信サーバーのIPアドレスを確認する
  • メールの送信サーバーの DNS レコードを確認する
  • 電子メールの送信エージェントを確認します (つまり、Web インターフェイス、Outlook、Thunderbird など)。
  • 返信先欄を確認する
  • 等。

これは複雑な質問だと思います (Posterous のような企業は、この問題にかなりの時間を費やしてきたと思います)。予備的に始めるためのいくつかの基準を探しています。ありがとう!

アップデート:

これまでの回答は本当に役に立ちましたが、それらを助けるために、私のプロジェクトのコンテキストは、ユーザーから Web アプリとして大量の電子メールを受け取ることになるということです。彼らは私のシステムにデータを入力する主な方法として電子メールを使用していました。これが私が後世のアナロジーを作った理由です。使用例は非常に似ています。

4

5 に答える 5

3

おっしゃる通り、すべてのヘッダーをまとめて、「既知の正常な」電子メールと比較すると、なりすましの可能性が高い電子メールを特定するのに役立ちます。

あなたが開発しているものは、せいぜいアルゴリズムではなくヒューリスティックでしょう。

時間帯によってフィールドを重み付けし、「既知の良好な」メールの時間帯にどれだけ近いかを検討します...

また、「既知の正常な」電子メールが疑わしいものとは異なる構造になっている場合。つまり、インライン画像、html、短縮 URL などです。

于 2009-12-04T14:51:26.310 に答える
2

以前に投稿した兄弟を褒めるために:

これを分析したいコンテキストがわからないため、非常に一般的であるため、不正な送信元からの電子メールが受け入れられる可能性を制限するために、最初の呼び出しポートは SPF または DomainKeys にすることをお勧めします。また、SSL セキュリティを備えた SMTP サーバーを 1 つだけ使用することをお勧めします。私はこれを行い、世界中を旅していますが、メールを送信できない状況に陥ることはめったにありません。そのような場合、機能したのはウェブメールだけでした (安全なローカル SMTP はありません)。

それに加えて、メールが本当にあなた自身から来ていることを確認している場合は、PGPツールを使用して送信時にメールに署名し、有効な署名のないメールをフィルタリングすることもできます. Thunderbird の Enigmail は自動署名の優れたソースであり、Outlook 用のプラグインもあります。

その後、電子メールでさらに法医学的な仕事をしたい場合は、スパムベイズを使用して、以前の電子メールのデータベースに対して電子メールにスコアを付けることができます一意でないデータ (「To:」などのエントリを除く) に関するトークンのデータベースを構築し、以前の電子メールと同様である可能性について電子メールにスコアを付けます。理論的には、どのメールでも非常に高いスコアを獲得する必要があります。

明らかにあなたの状況はわかりませんが、多くのテクニックがあると思いますが、問題を解決しようとするよりも、問題の根本にたどり着く方が簡単な場合があります.

アップデート

提供されたコンテキストに基づいて:

「アドレス拡張」を使用することを検討します。これは、ユーザーが電子メールアドレスを使用した参照を含むアドレスにメールを送信できる場所です: emailname+extension@domain.com hi-jinx なしで正しい emailname@domain.com に送信します。ユーザーに固有の ID を拡張子として付けたメールを配信させることができます。そうすれば、それがユーザーから送信されたものであることがわかり、ユーザーはより特別な気分になります。明らかに、誰かが発信メールや受信メールを盗聴して独自のコードを盗むことができますが、それは常に可能であり、誰かがそれを行うことができれば、おそらくメールを挿入することもできます.

本当に分析ルートをたどりたいだけの場合は、SpamAssassin のユーザーごとのベイズ マッチの逆を使用することをお勧めします。すべてのメールを送信者からのメールのデータベースと比較する場所 (メールをアカウントに「送信する」伝統的な照合の代わりに)。データベースが誤検知で汚染されると、誤検知を削除するか、その送信者の照合の完全性を危険にさらす必要があることに注意してください。

于 2009-12-04T15:16:38.950 に答える
2

おそらく実用的ではありませんが、うまくいくもの:

受信メールが届いたら、「送信者への返信」機能を使用して、送信したかどうかを確認します。これは、自動的に生成される確認リンクなどの形式である可能性があります。

しかし、プロジェクトの詳細がわからないので、これは実用的ではないかもしれません...たとえば、各ユーザーに対してこれを複数回行う必要がある場合、誰も我慢しません。

于 2009-12-04T15:17:01.180 に答える
2

Sender Policy Frameworkの使用を検討してください。あなたが探しているものとは正確には異なるかもしれませんが、役立つかもしれません。

簡単に言うと、SPF レコードの設計意図は、受信 MTA (メッセージ転送エージェント) が電子メール (送信者) に表示されるドメインのネーム サーバーに問い合わせて、メールの発信元 IP (送信元) が正しいかどうかを判断できるようにすることです。送信者のドメインにメールを送信する権限があります。

ウィキペディアからリッピング:

Sender Policy Framework (SPF) は、RFC 4408 で定義されているように、一般的な脆弱性である送信元アドレス スプーフィングに対処することで電子メール スパムを防止するように設計された電子メール検証システムです。SPF を使用すると、電子メール管理者は、パブリック DNS レコードに特定の DNS SPF レコードを作成することにより、そのドメインから送信されたと主張する電子メールの送信を許可するインターネット ホストを指定できます。次に、メール交換者は DNS レコードを使用して、電子メール管理者が発行したリストと照合して送信者の身元を確認します。

于 2009-12-04T16:17:18.227 に答える
2

spamassassin や、ベイズ スコアを付加するようなフィルターを介して電子メールを実行してみませんか。その後、そのスコアを読み取ることができます。車輪の再発明を省くことができます。

個人からの以前のすべての電子メールのデータベースに対して、電子メールにベイズ スコアを付けることができます。

また、SpamAssassin が実行できる Sender Permitted Framework と DomainKeys の検索もあります。

于 2009-12-04T15:01:14.733 に答える