メールクライアントがメールの送信日付（Date:フィールド）の値を正しく処理できなかった場合に、変な日付で表示されることがあります。
「1970年からスパムメールが届いた」という記事を見かけたので、「日付を正しく処理できなかった場合には、表示上の日付が紀元日時（1970年1月1日）となることがある」という記事をトラックバックしたのですが、ちょっと誤解があったようです。
この記事によれば、多くの場合「日時順に並べると最新メールの位置に表示」されるように故意に未来の日付でメールを発しているとか。
ところが「2038年01月19日03時14分07秒」を1秒でも過ぎてしまうと、システムの関係で「1970年01月01日09時00分00秒」なる日付に化けてしまうらしい。
過去からのメール・その後。 - オオカミの遠吠え通信
太字は、原文のまま。
残念ながら、2038年01月19日03時14分07秒(UTC)よりも未来だからといって、必ずしも紀元日時になる訳じゃないんです。
日付を1970年01月01日00時00分00秒(UTC)からの経過秒数で表現していて、経過秒数に32ビット符号付整数を採用しているシステムでは、2038年01月19日03時14分07秒(UTC)／2038年01月19日12時14分07秒(JST)のときの経過秒数が2,147,483,647(0x7FFFFFFF)という正の整数の最大値です。
そういうシステムでは、2038年01月19日03時14分07秒(UTC)の1秒後の経過秒数が負の値になるために、紀元日時から2,147,483,648を引いた1901年12月13日20時45分52秒(UTC)／1901年12月14日05時45分52秒(JST)になったり、「経過秒数に負は有り得ない」ということで日付エラーとして紀元日時である1970年01月01日00時00分00秒(UTC)／1970年01月01日09時00分00秒(JST)として扱ったりすることがあるのです。
2039年のメール しかし、OSのHP-UX（64ビット版）やメールクライアントソフトのThunderbirdなどのように、2038年01月19日以降も日付を正しく扱うことができるものもあります。理由は簡単で、経過秒数として64ビット符号付整数を採用していたり、日付の扱い方がまるっきり違ったりするからです。
それでは何故、Thunderbirdで受信したメールの送信日時が1970年01月01日09時00分00秒(JST)になっていたのでしょうか。
一つは、メール発信者が「送信日時は1970年01月01日00時00分00秒」などと申請した場合で、それらのメールは「Date:フィールド」が「Date: 1 Jan 1970 00:00:00 -0000」とか「Date: Thu, 01 Jan 1970 09:00:00 +0900」とかになっている筈です。
＃ メールのソースをご覧になってみてください
日付のないメール そしてもう一つは、メール発信者（含むメールクライアント）が故意に「Date:フィールド」を付けなかった場合です。
＃ メール規約では、メール発信者が「Date:フィールド」を付けることになっていますが、スパマーはルールなど守りません
どうもThunderbirdは、メールヘッダに「Date:フィールド」が見つからなかった場合には、メール日付を初期値である1970年01月01日00時00分00秒(UTC)のまま表示しているようです。
＃ タイムゾーンがJSTのマシンなら、1970年01月01日09時00分と表示される
それ以外にも、日付が1970年01月01日00時00分00秒(UTC)となるケースがあるかも知れませんので、メールのソースを確認しないと本当の原因は分かりませんけど（わは）。
＃ メールが無くなってしまって、もうソースを確認できないかも知れませんが
Windows XPのThunderbirdなら、%APPDATA%\Thunderbird\Profiles\プロファイルフォルダ名\Mail\Local Foldersに削除してしまったメールのソースが残っていることもあるので、片っ端から探すという手もなくはないのですが、スパムのためにそこまでするのはナンですね。
過去からのメール・その後。 - オオカミの遠吠え通信 2006年05月08日23:23
2038年問題とUNIX時間 2005年11月27日01:55
ヘッダフィールド一覧 - インターネットメールの注意点
