この文書はemailのヘッダーに関する包括的な入門である。 基本的には迷惑 emailの真の（普通、偽装されている）の発信源を特定したいと思っている被害者に役立つ：これはまた、他の偽装（偽造）emailの理解に役立つはずだ。 さらにこの文書はインターネットでのメールの配送について概括的入門に興味のある読者にも役立つかもしれない。
ここでは“偽装のやり方”に関する考察は意識的に避けてはいるが、やる気があればここでの情報は悪用されるかもしれない。筆者はもちろん悪意のある、あるいは人を欺くような偽装emailを是認はしないし、ここでの情報を悪用するいかなる利用もここでの目的に反している。
本文には性質上、IPアドレスと関連したいくつかの架空のドメイン名がある。将来にわたって、このどれかが使用される可能性はゼロではない。同様に、例題 で使用された全てのIPアドレスは執筆の時点では未確認であるが、いつかは確実に割り当てられるであろう。もちろん、これらドメイン名あるいはIPアドレ スの将来の利用者に迷惑をかけるつもりのものはこの文書内には無い。
このセクションでは一通のemailの生涯について簡潔に解析する。ここでの予備知識はヘッダーが語っていることを理解するのに重要である。
表面的にはemailは送信者のマシンから受信者のマシンへ直接やり取りされるようにみえるが、普通、これは正しくない；典型的な一通のemailは少なくとも４台のコンピュータを通過する。
ほとんどの組織はメールサーバと呼ばれるメール専用マシンを持っているからこうなるのだが、通常メールサーバはユーザがメールを読むときに使ってい るマシンではない。家庭のコンピュータからダイアルインするユーザをもつISP(Internet Service Provider)の普通の場合は、クライアントコンピュータはユーザの家庭にあるマシンで、サーバはISPに所属する“ある”マシンである。 ユーザがメールを送るときはユーザのコンピュータでメールを書き、そして、ISPのメールサーバにメールを送る。この時点でユーザのコンピュータの仕事は 完了する・・・がメールサーバはまだメールを配送しなければならない。メールサーバは受信者側のサーバを探し、そのサーバと“相談し”メッセージを送る。 メッセージは受信者がをやってきてそのメールを読むまで第二のメールサーバに置かれる。受信者は自分のコンピュータにメッセージを取り込むが、普通その過 程でメッセージはメールサーバから削除される。
Illustration.（挿し絵）
一組の仮想ユーザ <rth@bieberdorf.edu> と <tmh@immense-isp.com> を考えよう。tmhはimmense.ISP社のダイアルアップ接続の利用者で、Loris Mailという仮想的なメールプログラムを使っているとしよう。rthはBieberdorf大学に所属しており大学のネットワークに接続されたワークス テーションを使っているとしょう。
rthがtmhにメールを送るとき、彼のワークステーション（alpha.bieberdorf.edu としておこう）でメールを書く。作成された文書はそこからメールサーバーmail.bieberdorf.eduへ渡される（rthが係わるのはここまで で、あとの処理はマシンが人の助けなしで行う）。メールサーバはimmense-isp.comのだれかに渡すメッセージを持っているわけだから、その メールサーバ --おそらく mailhost.immense-isp.com と呼ばれる --とコンタクトし、メールを配送する。メッセージはtmhがホームコンピュータからダイアルインし、メールをチェックするまで mailhost.immense-isp.com に保管される。tmhがダイアルインした時点でrthのメールと共に保管されていた他のメールも一緒にメールサーバーがホームコンピュータに配送する。
Illustration.（挿し絵）
この全過程でヘッダーがメッセージに3 回付け加えられる：文書作成時（rthがどのようなemail プログラムを使っていても）；このプログラムがmail.bieberdorf.eduへメールのコントロールを移した時点；そして、 bieberdorfからimmenseへのメール移転の時点である。（通常、メッセージを取り出すダイアルアップ接続ノードはヘッダーを付け足さない） これらヘッダーの発展を見ていこう。
rthのメーラで起草し、mail.bieberdorf.eduへ渡すものとして:
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
X-Mailer: Loris v2.32
Subject: Lunch today?
mail.bieberdorf.edu がメッセージをmailhost@immense-isp.com に送信するときのままの状態で:
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?
mailhost@immense-isp.comがメッセージの処理を終え、tmhが取り出すために保管するときのままの状態で:
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?
この最後のヘッダーはtmhが彼のメールをダウンロードしてそれを読むときに見るものである。これらのヘッダーを一行ごと、意味が何かを見て行こう。
Received: from mail.bieberdorf.edu
このメールはmail.bieberdorf.eduと‘名のる’マシンから受け取った...
(mail.bieberdorf.edu [124.211.3.78])
...事実、これはmail.bieberdorf.eduと命名されており、IPアドレス124.211.3.78である。
by mailhost.immense-isp.com (8.8.5/8.7.2)
メールを受けたマシンはmailhost.immense-isp.comでsendmailのVersion 8.8.5/8.7.2と呼ばれるプログラムが走っている。
with ESMTP id LAA20869
受けたマシンはメッセージにId番号 LAA20869を割り振った。（これはマシン内部で使用される--システム管理者がマシンのログファイルからこのメッセージを調べるのに知っておく必要があるぐらいで、それ以外通常、意味がない）
for <tmh@immense-isp.com>;
このメッセージはtmh@immense-isp.com宛である。このヘッダーは To: には関係 ない ことに注意すること。
Tue, 18 Mar 1997 14:39:24 -0800 (PST)
このメールの配送は1997年3月18日 火曜日 午後2時39分24秒 太平洋標準時 (これはグリニッジ標準時より８時間進んでいるので" -0800 "となる)に行なわれた。
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
この行はalpha.bieberdorf.edu(rthのワークステーション）からmail.bieberdorf.eduへのメールの移管を 裏付けている。この移管は午後2時36分17秒 太平洋標準時に行われた。送信マシンはalpha.bieberdorf.eduと思われるが、実際 alpha.bieberdorf.eduと命名され、IPアドレスは[124.211.3.11]である。bieberdorfのメールサーバーは sendmail Ver. 8.8.5が走っている。さらに、内部処理上この書簡にidナンバー004A21が割り振られた。
From: rth@bieberdorf.edu (R.T. Hood)
このメールはrth@bieberdorf.edu から送られた。このアカウントの利用者名はR.T.Hoodとなっている。
To: tmh@immense-isp.com
宛先はtms@immense-isp.comである。
Date: Tue, Mar 18 1997 14:36:14 PST
メッセージは1997年3月18日 14時36分14秒 太平洋標準時に書かれた。
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
このメッセージには識別のため(mail.bieberdorf.eduによって)このナンバーが割り当てられた。このIDはReceived: ヘッダーのSMTP, ESMTPのIDナンバーとは異なる、なぜなら、このメッセージに常についてまわる。それに引き替え他のIDナンバーは特定のマシンの特定のメール処理に 付随したものだからだ、よって、ひとつのマシンのIDナンバーは他のマシンには何の意味も持たない。しばしば、この例に見られるようにメッセージIDはそ の中に送信者のemail アドレスが埋め込まれているが、明確な意味があるわけではない。
X-Mailer: Loris v2.32
このメッセージはLoris v2.32と呼ばれるプログラムを使って送られた。
Subject: Lunch today?
ご覧の通りです。（今日、ランチ御一緒しない？）
このセクションは他より少し技術的で、メールの配送に焦点を当てている。全ての用語を理解する必要はないが、この項目に習熟しておくと妙なことに遭 遇しても慌てることはなくなる。email スパマーはしばしば故意にこのような奇妙な状況を(被害者を混乱させるために)つくりだすので、このような状況を理解する能力が非常に役に立つ。
ネットワークで通信するためにコンピュータはポートと呼ばれる入り口をしばしば使用する；コンピュータがネットワークをつかって情 報交換をするチャンネルと思っていただきたい。一度に多くの情報交換をするためには、コンピュータは複数のポートを持つ必要がある：ポートを識別するため に一般に番号が付けられている。インターネットに接続されたコンピュータ上ではポート25がここでのディスカッションでは特に重要である：このポートは emailのやり取りに使用されるポートである。
直前のセクションの例に戻ろう、具体的にはmail.bieberdorf.eduがmailhost.immense-isp.comと通信して いるとする。ここで実際行われていることは mail.bieberdorf.edu が mailhost.immense-isp.com のポート25 のコネクションを開きそして管理データと一緒にメールをコネクションを通じて送ることである。これを行うために使用するコマンド、受けているシステムから発行され応答はおおよそ判読可能である。これらはSimple Mail Transfer Protocol SMTPと呼ばれるもの中のコマンドである。マシン間のやり取りを盗聴する者がいたら以下のようなものであろう。（mail.bieberdorf.eduから発行されるコマンドはボールドである）
220 mailhost.immense-isp.com ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 1997 14:38:58 -0800 (PST)
HELO mail.bieberdorf.edu
250 mailhost.immense-isp.com Hello mail.bieberdorf.edu [124.211.3.78], pleased to meet you
MAIL FROM: rth@bieberdorf.edu
250 rth@bieberdorf.edu... Sender ok
RCPT TO: tmh@immense-isp.com
250 tmh@immense-isp.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?
Do you have time to meet for lunch?
--rth
.
250 LAA20869 Message accepted for delivery
QUIT
221 mailhost.immense-isp.com closing connection
この処理の全てはSMTPの中核をなす五つのコマンドによっている： HELO, MAIL, FROM, RCPT TO, DATA そしてQUITである。
HELOは送信マシンを識別する。 "HELO mail.bieberdorf.edu" は "Hello I'm mail.bieberdorf.edu" と解釈する。送信者はうそがつける；"Hello, I'm frobozz.xyzzy.gov " (HELO frobozz.xyzzy.gov) あるいは "Hello, I'm a misconfigured computer" (HELO a misconfigured computer) と述べても mail.bieberdorf.eduはこれを防ぐ手段を原理的にもっていない。しかし、ほとんどの状況で受信者はこれを発見するツールを持っており送信者のマシンの真のIDを見つけだす。
MAIL FROM はメールの処理を着手する：これは“私はどこそこからメールを出します”という意味である。与えられたアドレスはいわゆる"envelope From"になり、これは送信者自身のアドレスである必要はない！この明白なセキュリティーホールは避けることができないが、ある状況下では有用になる。
RCPT TO はMAIL FROMと対をなす。これはメールの受取人を指定している。一通のメールは複数のRCPT TOコマンドで容易に複数の受取人に送ることができる。与えられたアドレスはいわゆる"envelope To"になり、これが実際、To:の行が何かにかかわらずメールが配送される人を決めてしまう。
DATA で実際のメールの記入を開始する。DATAコマンドの後に入力される全てはメッセージの一部と見なされ、形式に制限はない。一つの単語とコロンで始まる （最初の空行の前の）メッセージの行は、（筆者の）ほとんどのメールプログラムでヘッダーとみなされる。ピリオドだけの行はメッセージを終了する。
QUITで接続を終了する。
SMTPはRFC 821ですべてが規定されている。RFCはWebから広く入手可能（訳注：日本語訳もある）で、メール処理の込み入ったことを解く助けとして一読の価値はある - ただし分量は多い。
上述のシナリオは少し簡略化しすぎている。最大の仮定は二つの組織のメールサーバは一方から自由にアクセスできるということである。これはインター ネットの初期ではほとんどがそうであったが今日でもまだ、ときおり見受けられる。しかし、セキュリティーがますます大きな懸念になり組織とネットワークも ますます巨大化した結果、しばしば多数の分離したメールサーバが必要となっているのでこのようなことはますます稀になってきている。
インターネットに接続しているコンピュータを有する組織の多く、おそらくそのほとんどが何らかのファイアーウォールで守られている。ファイアー ウォールとはネットの巨大なうす汚い世界と組織の所有マシンの間で門番のごとく働くことを第一の任務としたコンピュータである。ファイアーウォールの背後 にあるシステムにメールを届けたい他のコンピュータからすれば、この意味はシステムとは直接やり取りすることはできず、ファイアーウォールとやり取りしな ければならないということである。
驚くことはない；これは１通のemailの旅路（journey）のなかにメールが通過する別のマシンとして機能するファイアーウォールによる“小 旅行 (hop)”を取り入れているだけだ。（journeyは陸路の長旅を、hop は飛行機を使ったちょっとした旅行を指すようだ：訳注）
The picture above might be modified to look like this:
Illustration.（挿し絵）
もし、immense-isp.comの適当な場所にファイアーウォールがあった場合のいままでの例でのemail のヘッダーを示す。最初のReceived: 行に注目してほしい。（筆者はファイアーウォールマシンはfirewall.immense-isp.comであると仮定している；実際、 firewallのような名前を付けることは世界中の十代全てのクラッカー予備軍の連中を招くに等しいので、ファイアーウォールは普通、月並で刺激的でな い名前を付けている）。
Received: from firewall.immense-isp.com (firewall.immense-isp.com [121.214.13.129]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA20869 for <TMH@IMMENSE-ISP.COM>; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?
同様に、仮にbieberdorf.eduから出ていく全てのメールがファイアーウォールを通って経路制御されていれば、もう一つの Received: 行がファイアーウォールマシンによって挿入されるであろう。さらに厳密にはファイアーウォールではないが、単にルーティングのためのマシンがあるかもしれ ない -- おそらく、immense-isp.comは多くの地点にマシンをもっており、そのいくつかは独立したメールサーバである。そして、一つのマシン （mailgate.immense-isp.comとする）を到着メールをどのサーバに持っていくかの経路制御に使用している。よって、以下のヘッダー のセットは少し極端な例だがありえないものではない:
Received: from mailgate.immense-isp.com (mailgate.immense-isp.com [121.214.11.102]) by mailhost3.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA30141 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:41:08 -0800 (PST)
Received: from firewall.immense-isp.com (firewall.immense-isp.com [121.214.13.129]) by mailgate.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from firewall.bieberdorf.edu (firewall.bieberdorf.edu [124.211.4.13]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA28874 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:39:34 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by firewall.bieberdorf.edu (8.8.5) with ESMTP id LAA61271; Tue, 18 Mar 1997 14:39:08 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?
メッセージの履歴はReceived:ヘッダーを下から上に読むことで再構成できる：このメッセージはalpha.bieberdorf.edu -> mail.bieberdorf.edu -> firewall.bieberdorf.edu -> firewall.immense-isp.com -> mailgate.immense-isp.com -> mailhost3.immense-isp.com、最後がtmhがやってきて読むところである。
これまで述べてきたいずれとも異なる“ライフサイクル”を持つメッセージのヘッダーをご覧いただく:
Received: from unwilling.intermediary.com (unwilling.intermediary.com [98.134.11.32]) by mail.bieberdorf.edu (8.8.5) id 004B32 for <rth@bieberdorf.edu>; Wed, Jul 30 1997 16:39:50 -0800 (PST)
Received: from turmeric.com ([104.128.23.115]) by unwilling.intermediary.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer <junkmail@turmeric.com>
To: (recipient list suppressed)
Message-Id: <w45qxz23-34ls5@unwilling.intermediary.com>
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???
ヘッダーの様子からこれがジャンクメールの一部だろうことは察しがつくであろうが、ここで注目するのはReceived: 行である。turmeric.comに起源を持つこのメッセージはここからunwilling.intermediary.com へ、そして、そこからmail.bieberdorf.eduの最終目的地へパスされている。それはそれでいいのだが、 unwilling.intermediary.comは送信者あるいは受信者としてやることは何も無いのにどうしてここに在るのだろう？
答えを理解するにはSMTPの知識をいくらか必要とする。要するにturmeric.comは単にunwilling.intermediary.comのポートに接続してメッセージをrth@bieberdorf.eduに送るよう命じている。これはRCPT TO: rth@bieberdorf.edu が 実行されたであろうことが直観的に想像される。その時点でunwilling.intermediary.comはメッセージの処理を引き継いだ；他のド メイン（bieberdorf.edu）のユーザにそれを送るよう命じられたから送信し、そのドメインのメールサーバを見つけていつも通りそのメールを取 り扱った。この過程はメールの中継と知られている。
歴史的に中継を許可するもっともな理由が存在する。1980年代後期まで多くのネットでは、マシン同士がお互いやり取りしてメールを送ることは稀であっ た。むしろ、マシンはメッセージのトラベルのため一つのルートを取り仕切り、メールをステップバイステップでルートに沿って運んでいた。これは厄介なシス テムであった（特に送信者がルートを決めなければならなかったから）。同様なことを手紙をサンフランシスコからニューヨークまで配送するとして封筒の宛名 書きは以下のようであるとしよう。
San Francisco, Sacramento, Reno, Salt Lake City, Rock Springs, Laramie, North Platte, Lincoln, Omaha, Des Moines, Cedar Rapids, Dubuque, Rockford, Chicago, Gary, Elkhart, Fort Wayne, Toledo, Cleveland, Erie, Elmira, Williamsport, Newark, New York City, Greenwich Village, #12 Desolation Row, Apt. #35, R.A. Zimmermann
郵便局員の立場では、これが便利な住所書きモデルである理由は明らかだ。Gary, indiana の郵便局はChicagoとElkhartにある両隣の郵便局と連絡がとれさえすればよい。NewYorkまでどのように行くのかを解決するためにリソー スを割かなくともよい。(これはまた手紙を書く人の立場に立てば良い考えではないことも明らかで、このためemailがもはや、このやり方で経路制御され ていない理由でもある)。
これがまさにemailを送る方法であった；そこであるマシンは次のようなもう一つの指示を与えることが重要であった -- rth@bieberdorf.edu へのemail があります。経路はあなたからturmeric.com, galangal.com, asafoetida.com, bieberdorf.edu の順番です。これがすなわち中継である。
しかし、現在、中継は反道義的な広告主がそのメッセージの発信元を隠すためのテクニックとして使っており、苦情がスパマー自身のISPではなく無実 の中継サイトへいくように仕向けている。（そのうえ、アドレス処理と受信者への連絡の仕事をスパマーのマシンから無関係な第三者のマシンに押し付けてい る。中継、特に大規模な中継はサービスの窃盗を構成し、はなはだ深刻である）ここで気がつく本質的な点はメッセージの内容は送信された場所で策定されてい ることである -- 上記の例でのturmeric.com。中間のリンク、unwilling.intermediary.com は不本意な橋渡し役として登場するだけである。送り主をコントロールすることはできない、これはGrayの郵便局がサンフランシスコで手紙を書くだれかに 干渉できないのと同様だ。（中継をストップする能力はある。）
例題のヘッダーでのもう一つの注意点：Message-id: 行は送信マシン(turmeric.com) のものではなく中継マシン(unwilling.intermediary.com)のもので埋められている。これは中継されたメールの共通した特徴であ る：これは送信マシンがMessage-idを発行するものではないという事実を反映しているだけだ。
SMTPに関するセクションで“message”と“envelope”ヘッダーの違いを間接的ではあるが言及した。この違いとその結果のいくつかをここで詳しく述べることにする。
簡単に言えば、“envelope”ヘッダーは送信者ではなく、メッセージを受けたマシンによって生成される。この約束に従えば、 Received: ヘッダーはenvelope headerである、しかしenvelope headerと言えば通常は“envelope From”と“envelope To”のみを指す。
envelope From ヘッダーはMAIL FROMコマンド内の情報に由来するヘッダーである。たとえば、送信マシンがMAIL FROM: ginger@turmeric.com と指示すれば、受信マシンは以下のようはenvelope From ヘッダーを生成するであろう:
>From ginger@turmeric.com
コロン（：）が無いことに注目してほしい-- "From" であって"From:" ではない。しばしば、envelope ヘッダーは後にコロンがついていない；全てそうである訳ではないが、注意するにこしたことはない。
対照的に、envelope To はRCPT TO コマンド から派生している。送信者が RCPT TO: tmh@bieberdorf.edu と指示すれば、envelope To は tmh@bieberdorf.edu となる。この情報を含む実際のヘッダーがたびたび存在することはなく、ときには Received: ヘッダーの中にはめ込まれている。
envelope 情報の存在で一つの重要な結果はmessage From: と To: ヘッダーには意味がないということだ。 From: ヘッダーの内容は送信者が規定できる；To: ヘッダーも直感に反するが同じである。メールはmessage To: ヘッダーでは無くenvelope To: のみに基づいて経路制御（ルーティング）される。
実際、これを理解するため、以下のSMTP処理を考えよう:
HELO galangal.org
250 mail.bieberdorf.edu Hello turmeric.com [104.128.23.115], pleased to meet you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org... Sender ok
RCPT TO: tmh@bieberdorf.edu
250 tmh@bieberdorf.edu... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
.
250 OAA08757 Message accepted for delivery
対応するヘッダーは次のようになる（抜粋）:
>From forged-address@galangal.org
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5) for <tmh@bieberdorf.edu>...
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
envelope From, message From:, そしてmessage To: は全て発信者によって規定されており、信ぴょう性が全くうかがえない。ここの例で From, From: そして To: ヘッダーは偽装の可能性のあるメールでは全く信用できないものだということに注意してほしい；偽装はとても簡単だ。
上の例ですでに見たが、Received: ヘッダーはメッセージの履歴の詳細な記録を与える。だから他のヘッダーが偽装されていても、emailの起源についていくつか推定を思い描くことができ る。このセクションではこれらの特に重要なヘッダーに関する詳細、そして、特にありふれた偽装テクニックの回避方法を検討する。
明らかに、Received: ヘッダー内の単純でもっとも有効な偽装“よけ”は受信ホストによって記録された送信者からの情報である。送信者は受信者へのHELO コマンドにゴミ情報を置くことでその身元を詐称できることを思い出してほしい；幸い、近年のメールプログラムはこのような間違った情報を検出し訂正してく れる。
もし、たとえば、マシン turmeric.com, IP アドレス 104.128.23.115 が mail.bieberdorf.eduにメールを送るのだが、偽ってHELO galangal.org と指示すれば、結果としてReceived: 行は次のようになるであろう:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
(残りの部分は省略）
bieberdorf.edu は真の送信マシンが galangal.org でないことをはっきりと示しているわけではないが、送信者の 正しいIP アドレスをはっきりと記録していることに注意してほしい。もし、メールの受信者が galangal.org が偽装者の細工で持ち込まれたものとの考えて、IP アドレス 104.128.23.115を調べれば（UNIXプログラムのnslookupのようなツールで）、このアドレスが galangal.org のものではなく実際は turmeric.com に属するものであることが判明する。言い換えれば、送信マシンのIP アドレスの記録は疑わしい偽装を確認するに十分な情報を与える。
多くのモダンなメールプログラムは実のところ送信マシンのドメイン名を調べるこの処理を自動化している。(この調査処理をDomain Name Servieの逆引きと呼んでいる)---経路制御処理のためのドメイン名からIP アドレスへの通常の変換の逆なので"reverse" である。もし、mail.bieberdorf.edu がこれ行うソフトウエアを使っていれば、Received: 行はつぎのようになるであろう:
Received: from galangal.org (turmeric.com [104.128.23.115]) by mail.bieberdorf.edu...
偽装は明らかだ；この行には報告されたその名称 galangal.org は実は“turmeric.com でそのIP アドレスは 104.128.23.115”と書かれている。言うまでもなく、この様な情報は偽装 emailの追跡と確認に非常に有用である（このため、スパマーは逆引き情報を報告するマシンを中継マシンとして使うのを避けようとする）。ときどき、彼 等は前段落で述べた IP を記録をしないマシンを探し出すことさえする--- しかし、ネット上にそんなにあるわけではない。
email の偽装者に使われる別のトリック - これは増加傾向にあるが - は目障りなメールを送る前に偽のReceived: ヘッダーを追加することである。これはturmeric.com から送られた仮のemailが次のようなReceived: 行を持つかもしれないということだ:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from nowhere by fictitious-site (8.8.3/8.7.2)...
Received: No Information Here, Go Away!
明らかに最後の二行は完全に無意味で、送信者が書き、送信前にメッセージに付けている。
送信者はメッセージが一度 turmeric.comを出るとそれをコントロールできない、そしてReceived: ヘッダーは常に上に追加されので、偽装された行はリストの下に現われなければならないことになる。これはメッセージの履歴を辿るために上から下へヘッダー 行を読む人は最初の偽装された行以後は何でも安全に捨てることができる；仮にその行以降のReceived: 行がもっともらしく見えても偽装されたものと保証できる。
もちろん、送信者はゴミとわかるものを使わなくてもいい；ほんとうにずるい偽装者は下のReceived: 行のような、まことしやかなリストを作るかもしれない:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)...
Received: from graprao.com by lemongrass.org (8.6.4)...
ここで、唯一の足どりは最初のReceived: 行のgalngal.orgの不正確な IP アドレスである。もし偽装者が lemongrass.org と graprao.com に正確な IP アドレスを書いたなら偽装を見破るのがちょっと困難であろう。しかし、一行目のIP アドレスのミスマッチはこのメッセージが偽装されていることを暴露している。すなわち、104.128.23.115 (turmeric.com) サイトが挿入されている。しかし、ほとんどのヘッダー偽装者は著しくセンスに欠けており、余分の Received: 行は見ればゴミと判る。
© 1997 Nathan Tenny and Ken Lucke- all rights reserved
Translated by permission of Ken Lucke
© 2002 Fuminori Takeda - all rights reserved