あなたが話しているのは偽造されたメッセージです。送信することは可能ですが、受信者がメッセージを受信する可能性はほとんどありません。メッセージの偽造を防ぐためのセキュリティ対策が講じられています。
- ドメインキー
- DKIM
- SPF
- 送信者 ID
DomainKeys は廃止され、DKIM が採用されました。2つは非常に似ています。SO の投稿「DomainKeys と DKIM の違いは?」違いを説明します。
SPF と SenderID は混同されることがありますが、それらは異なります。SPF: SPF と SenderIDを参照してください。
これらのテクノロジを実装して利用するのは、受信者の SMTP サーバーにかかっています。たとえば、メールを受信したが SPF チェックに失敗した場合、メッセージはスパムとしてマークされ、「ジャンク フォルダ」に移動しますが、メッセージは引き続き受け入れられます。さらに一歩進んで、SMTP サーバーはメッセージの DKIM 署名を検証することもできます。検証に失敗すると、メッセージは受け入れられません。これらのポリシーとメール パスは、受信メール サーバー/クライアントによって決定され、大きく異なります。
Sender Policy Framework (SPF) / SenderID
Sender Policy Framework (SPF) は、送信者の IP アドレスを検証することにより、一般的な脆弱性である電子メールのなりすましを検出することにより、電子メール スパムを防止するように設計された電子メール検証システムです。SPF を使用すると、管理者はドメイン ネーム システム (DNS) で特定の SPF レコード (または TXT レコード) を作成することにより、特定のドメインからメールを送信できるホストを指定できます。メール エクスチェンジャーは、DNS を使用して、特定のドメインからのメールが、そのドメインの管理者によって承認されたホストによって送信されていることを確認します。
出典:ウィキペディア
SPF とは対照的に、SenderID は代わりに Purported Responsible Address (PRA) を検証します。RFC 4407を参照してください。
簡単に言えば、これは「IP アドレスXはドメインYにメールを送信できますか?」という DNS チェックです。
次のシナリオを想像してください。スージーはビクトリアに手紙を書きます。先制して、スージーはビクトリアに、スージーの兄弟ジョンとスージー自身だけが彼女に手紙を届けると言います. そこでスージーはジョンに手紙を渡し、通りを歩いてビクトリアに届けるように言いました。ビクトリアはドアをノックする音を聞き、スージーからの手紙を持ったジョンがいます。事前の合意により、スージーは手紙を受け入れます。数日後、スージーはビクトリアに別の手紙を書きますが、ジョンは病気で手紙を届けることができません。代わりに、スージーは隣人のリックに手紙を通りを歩いてビクトリアに届けるように頼みます。リックはヴィクトリアの家のドアをノックし、スージーからの手紙があると言った。ビクトリアは手紙を断り、受け入れません(または、万が一に備えて後で確認するためにテーブルに置くかもしれませんなぜなら、スージーとジョンだけがスージーからの手紙を届けることを彼女は期待しているからです。
example.com の SPF レコードの例:
spf2.0/mfrom ptr:mx.example.com +a +ip4:192.168.1.1 -all
この SPF レコードはmx.example.com
、すべてA records
が example.com に属し、IPv4 アドレスである server からのメールのみ192.168.1.1
が example.com にメールを送信できることを示しています ( -all
)。
DomainKeys Identified Mail (DKIM) / DomainKeys
DomainKeys は半分非推奨になっているため、DKIM に焦点を当てますが、前提は同じです。
DomainKeys Identified Mail (DKIM) は、ドメイン名を電子メール メッセージに関連付けるための方法であり、これにより、個人、役割、または組織がメッセージに対する責任を主張できるようになります。関連付けは、受信者が検証できるデジタル署名によって設定されます。メッセージのヘッダーに DKIM-Signature: フィールドを追加することにより、メッセージの実際の作成者や受信者とは無関係に、署名者が責任を負います。検証者は、DNS を使用して署名者の公開鍵を復元し、署名が実際のメッセージの内容と一致することを検証します。
DKIM は、SPF が DNS のみに関連付けられているという点で SPF とは異なりますが、DKIM はメール自体に存在する署名です。公開鍵暗号化の概念に精通している場合、それが本質的に DKIM です。送信者は、メッセージの暗号化に使用される秘密鍵を持っています。これにより、復号化のみのために公開鍵に (DNS TXT レコードを介して) アクセスできるようになります。
基本的に、DKIM は「私が受信しているメッセージは本当に送信者Xからのものですか?」という質問をします。
次のシナリオを想像してください。スージーはビクトリアに手紙を書きます。手紙と一緒に、スージーが考案した暗号化されたコードがあります。スージーはリックに手紙をヴィクトリアに渡すように頼みます。リックはビクトリアのドアをノックし、暗号化されたコードを含む手紙を提示します. 手紙を受け取る前に、Victoria は自分の「解読本」を取り出します (WhitePages のようなものだと考えてください。公開されている解読コードのリストですが、暗号化用ではありません)。彼女はコードを解読して、それが実際にはスージーの署名であることを確認し、リックからのメッセージを受け入れます。Susie が暗号化キーを解放しない限り、Susie の署名を偽造することはできません。
メールから日付と時刻を偽装する方法はありますか?
すこし。発送日はお持ちの通りです。
$headers .= 'Date: 2010-1-2 12:32:13' . "\r\n";
ただし、受信 SMTP サーバーは常にメッセージに独自のタイムスタンプを付けます。メール サービス/クライアントによっては、Date
ヘッダーが読み取られるか、別のメタ タイムスタンプが読み取られる場合があります (たとえば、受信 SMTP サーバーがヘッダーに追加されます)。
例として、gmail は送信者が設定したヘッダーを尊重すると信じています。1970Date
年 1 月 1 日 (Unix 時代の始まり) のメールを見てきました。これは、特に受信トレイに大量のメッセージがあるメールボックスでは、悪い考えです。メッセージが途中または最後で失われる可能性があります。