web-dev-qa-db-ja.com

X-Sender-Idは、電子メールの生のソース（フィッシング電子メールにあります）ではどういう意味ですか？

私の会社の誰かがフィッシングの対象になっています。私の最初の提案は、パスワードを変更することだけでした。しかし、しばらくして、私は彼女のアドレスから再び偽のメールを受け取りました。

メールの生のソースを見ると、X-Sender-IDに別の人のメールがあることがわかりました。それは誰なのか疑問に思います。それはメールを送信した人ですか、それとも乗っ取られたアカウントである可能性がありますか？ （メールを「[email protected]」に置き換えました）

X-Virus-Scanned: OK
Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: somebody-AT-Host.com) with ESMTPA id DF2788019C;
    Fri, 21 Nov 2014 07:54:42 -0500 (EST)
X-Sender-Id: [email protected]
Received: from smtp.emailsrvr.com ([UNAVAILABLE]. [2.133.148.211])
    by 0.0.0.0:587 (trex/5.3.2);
    Fri, 21 Nov 2014 12:54:46 GMT

X-Sender-IDとは何ですか？そして、それに含まれる電子メールは何ですか？

email-headersemailrelaysender-idinterchange
5
lisovaccaro

私の審議は、明らかに使用している電子メールのプライバシー強化について説明している this RFCに基づいています。

基本的に、X-Sender-IDについて次のように述べています。

[...]プライバシーが強化されたすべてのメッセージに必要なカプセル化されたヘッダーフィールドは、メッセージの送信者を識別し、送信者のIK識別コンポーネントを提供します。

これは何を意味するのでしょうか？

まず、メールが正しく署名されているかどうかを確認する必要があります。その場合は、[email protected]に証明書があることを確認できます。そして、あなたが受け取ったメールがこのメールアドレスから送信されたことを確認することができます。

あなたの会社が証明書などをどのように展開しているかわからないので、この事実から生じる結果をあなたに伝えることはできません...メールアドレス/証明書もハッキングされて悪用された可能性があります。

これがあなたのさらなる研究に役立つことを願っています。

5
LMF

x-sender-idとx-recipient-idは、メッセージのブロードキャストで使用された交換キーを指定するために使用されます。

X-Sender-IDentity_id : issuing_authority : version
X-Recipient-IDentity_id : issuing_authority : version

  1. 最初のフィールドには、送信者または受信者のIDが含まれます。最初のフィールドは必須であり、一意である必要があり、user@Hostとしてフォーマットされている必要がありますが、ホストは完全修飾ホストアドレスです。

  2. 2つ目は、交換キーを発行した機関の名前を識別します。

  3. 3番目のフィールドは、使用された交換キーの特定のタイプを指定します。これは、発行機関によって発行された多数の交換キーにラベルを付けて整理するために発行機関によって定義された英数字の文字列によって表されます。タイムスタンプを使用することをお勧めしますが、常にそうであるとは限りません。

x-sender-id2番目と3番目のフィールドのフィールド値がx-recipient-idのフィールド値と同じである場合、最後に定義されたフィールドにのみリストされる可能性があります。

参考文献

0
davidcondrey

@LMFの回答は有用な技術情報ですが、可能な代替の説明を提供したいと思います。

電子メールに精通していないスパマー（およびPHP他の悪意のないプログラマー）は、電子メールヘッダーに関してはカーゴカルトプログラミングに屈する傾向があります。言い換えれば、何かがある場合彼らは理解していません、彼らはそれが何か役に立つと思うかもしれません、そして彼らのメッセージテンプレートにそれを含めます。

あなたの電子メールインフラストラクチャ、または比較するあなたの他のメッセージについての知識がなければ、私は単に一番上のReceived:ヘッダーの下のすべてが偽造されており、基本的に意味がないと思います。

trex（多分 これ？ ）と呼ばれるものを実行するシステムがあり、それが本当にそのようなReceived:ヘッダーを書くことができるなら、私は間違っているかもしれません。形式は、いくつかの場所でデファクトスタンダードのSendmailテンプレートから不必要に逸脱していますが、技術的には間違っていません（形式は基本的に自由形式ですが、アドホック構文を導入すると、フィールドの意味を推測するのが難しくなります）。

繰り返しになりますが、あなたの典型的な電子メール（およびあなたの特派員の典型的なメール）がどのように見えるかについてのより多くの情報は、これは推測に重きを置いています。

0
tripleee