電子メール

1.電子メール
2.電子メールのヘッダ
3.メールの宛先（To、Cc、Bcc)
4.MIME　マイム
5.Base64
6.BASE64によるエンコードとデコードを実演
7.メールのエンベローブ、ヘッダ
8.メールのフレーム（パケット）構造

1.電子メール

世界中に簡単に、しかもほぼ無料、ほぼリアルタイムに手紙を送れるというのはすごいことだ。

遣隋使は聖徳太子から隋の煬帝（ようだい）への手紙を届けたが、それは大変な航海だったらしい。しかも「日出ずる処の天子」から「日没する処の天子」への手紙という上から目線の手紙であったというエピソード付きである。

さて、くだらない前置きはこれくらいで、ネットワーク試験において、メール関連の問題はそこそこ多いので、きちんと理解しましょう。

まず、概要について説明します。
・電子メールは、メールサーバと、OutlookやThunderbirdなどに代表されるメールクライアント（メールソフト）で構成されます。
・メールは、メールソフトで作成し、SMTPなどのメール送信プトロコルを使って送ります。外部から送信されたメールは、メールサーバのメールボックスに保存されます。利用者は、メールボックスに対して、POP3やIMAPなどのメール受信プロトコルを使ってメールを受信します。

2.電子メールのヘッダ

ネットワークスペシャリスト試験を目指す女性SE

実際にヘッダを見ることをお勧めします。

Outlook Expressの場合、メッセージを開いたうえで、「ファイル」「プロパティ」「詳細」タブ

メールのヘッダ
内容は以下
・Received:経由したメールSV
・From　差出人
・To　宛先
・Subject　タイトル
・Date　送信日付

Receivedはメールが配送されたルートを示している。メールは複数のサーバを経由することが多いので、Receivedは10行くらいになることも多い。
下から上に配送ルートが記載される。一番下が送信側で一番上が受信側。
以下に、Receivedヘッダについて解説を書いてみた。

▼過去問１（H19NW午前問50）
このネットワークスペシャリスト試験の問題では、ヘッダの解説がされている。
mailheader

▼過去問２（H18NW午前問9）
このネットワークスペシャリスト試験の過去問では、ヘッダのContent-MD5フィールドの用途を問われている。

過去問（H18NW午前問9）
問9　インターネットにおける電子メールのヘッダに含まれているContent-MD5フィールドの用途として、適切なものはどれか。ア　電子メール検索の高速化イ　電子メールに含まれているディジタルデータの著作権保護ウ　電子メール配信中のデータ損壊の検出エ　電子メール発信者の認証

↓
↓
↓
↓
↓
正解：ウ
事前知識がなくても、MD5という言葉から正解を導いてほしい問題である。MDはMessageDigestのことである。MessageDigestは、何の目的で利用するか？それはデータの完全性を確保するためである。つまり、データ損壊などといった完全性が失われていないかを確認する。

▼過去問３（H25SC春午前2問20）

過去問（H25SC春午前2問20）
問20　電子メールが配送される途中に経由したMTAのIPアドレスや時刻などの経由情報を, MTAが付加するヘッダフィールドはどれか。ア　Accept イ　Received ウ　Return-Path エ　Via

↓
↓
↓
↓
↓
正解はイのReceivedである。

では、以下の過去問（H20春SV午後1問1）で掲載されたメールヘッダの例です。これをもとに、メールの経路を書いてみましょう。

後半のFromが差出人のメールアドレス、toが宛先メールアドレス、Subjectがタイトルです。
Recievedは、経由したメールサーバの情報が、順に追記されます。一番上がもっとも新しいメールサーバです。Recieved行のbyで記載されたFQDNが経由したメールサーバです。

Q.以下は、上記のメールの経路を図にしたものです。今回はボット感染したPCがV社に迷惑メールを送信したと考えられます。2つのサーバ（下図のイ、ウ）のFQDNおよび、送信元であるボットのメールアドレス（下図のア）、受信者のメールアドレス（下図のエ）をそれぞれ答えよ。
mail

↓
↓
↓
↓
↓
A.ア：naisho-address@○○.jp
　イ：smtp01.v-sya.co.jp
　ウ：pop01.v-sya.co.jp
　エ：tanto@v-sya.co.jp

Q.メールヘッダの情報は、送信者によって詐称できる。エラー時などの返信先であるReturn-path以外にも、詐称されている可能性があるのは(i)～(ⅳ)のどれか。全て答えよ。(設問1（１）)

↓
↓
↓
↓
↓
A. まず、送信者の情報である（ⅰ）と（ⅳ）は、偽装された可能性があります。送信者が自由に設定できるからです。また、メールヘッダは、自由に書き換えることができます。なので、Recieved行も全て書き換えられている可能性があります。
じゃあ、（ⅰ）～（ⅳ）の全部が詐称されているかもしれないのですね。

はい、そうです。しかし、下から2つ目のRecieved行は、上記の図にあるように、V社の外部メールサーバで付与しています。V社のメールサーバが乗っ取られていない前提であれば、（ⅱ）のIPアドレスは、改ざんの可能性は低くなります。外部メールサーバが受け取ったIPアドレス情報を基に記載しているからです。
また、（ⅲ）の情報も、V社の外部メールサーバが付与しているので、正しいだろう、と想定できます。
正解は（i）と（ⅳ）です。

3.メールの宛先（To、Cc、Bcc)

電子メールの宛先を入力する欄には、To、Cc、Bccの3つがあります。
以下は、Thunderbirdの画面です。
bcc
3つの違いに関しては、IPAのサイトの丁寧な解説があるので引用します。

（ご参考）アドレス欄の意味
・To: メールを送りたい相手のアドレスを入力する。受け取った本人は自分宛のメールと判断できる。
・Cc: Carbon Copy（カーボン・コピー）の略。参考として同じ内容のメールを送りたい相手のアドレスを入力する。
・Bcc: Blind Carbon Copy（ブラインド・カーボン・コピー）の略。Ccと同じように、入力したアドレス宛に同じ内容のメールが送信される。ただし、ToやCcに入力したアドレスは、受信メールに表示されるため確認できるが、Bccに入力したアドレスは受信メールに表示されないため、他の誰に送信されているか、受信者にはわからない。
（旧リンク）https://www.ipa.go.jp/security/kojinjoho/user.html

過去問（H22春IP）をみてみましょう。

過去問（H22春IP）
問1 電子メールの送信例のうち,受信者への配慮の観点から,最も適切なものはどれか。ア会員から抽出した100名のアドレスを一度にあて先(To)に入れて,会員満足度調査のアンケートを電子メールで送った。イ自社製品を紹介する大容量の資料を,圧縮せずに電子メールに添付して得意先に送った。ウ製品の質問メールへの回答で,その内容を知ってもらいたい複数の顧客のアドレスをCcに入れて返信した。

過去問（H22春IP）

問1 電子メールの送信例のうち,受信者への配慮の観点から,最も適切なものはどれか。
ア会員から抽出した100名のアドレスを一度にあて先(To)に入れて,会員満足度調査のアンケートを電子メールで送った。
イ自社製品を紹介する大容量の資料を,圧縮せずに電子メールに添付して得意先に送った。
ウ製品の質問メールへの回答で,その内容を知ってもらいたい複数の顧客のアドレスをCcに入れて返信した。

↓
↓
↓
↓
↓
正解
エのBCCです。

4.MIME　マイム

従来、電子メールではASCII文字しか利用できなかった。つまり、画像データを送ることができなかった。
そこで、画像データを送れるように、画像などのバイナリデータをASCIIの文字データに変換して送るようにした。この拡張機能がMIMEである。
H22春IP問58では、「電子メールで使用されるMIME (Multipurpose Internet Mail Extensions)」に関して、「画像ファイルなどの添付ファイルを電子メールで送る方法」と述べている。
　

あれ？
公開鍵暗号方式を用いて,電子メールを暗号化して送る方法では？
それはSecureのSが頭につけられた、S/MIMEである。詳しくは別途記載する。

MIME（Multipurpose Internet Mail Extension）は、Base64というエンコード方式を利用している。

以下のメールヘッダにおいて、朱色部分がMIMEヘッダである。

・・・・・・
Received: from yyyyy1.co.jp [100.200.200.1]
by zzzzz1.co.jp with SMTP id xxxxx;
Tue, 24 Jul 2007 13:05:50 +0900
Received: from xxx (xxxxx1.co.jp [100.100.100.1])
by yyyyy1.co.jp (Postfix) with ESMTP id xxxx
for <user1@network-exam.com>; Tue, 24 Jul 2007 13:05:50 +0900 (JST)
From:Network　Master<master@network-exam.com>
To: user1 <user1@network-exam.com>
Subject: dns server
Date: Tue, 24 Jul 2007 13:05:49 +0900
Message-ID: <XXXXXX>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6822
・・・・・・

5.Base64

（１）なぜBASE64が必要？
メールはもともと7bitのASCII文字で送受信されることを想定していました。なので、日本語文字やら画像は送れません。
ネットワークスペシャリストを目指す女性SEあれ？　

いや、添付ファイルに画像をつけて送ることができますよ
はい、ただし、一工夫しています。そのままではバイナリデータを送れないので、Base64というエンコードを用い、文字列に変換して送っています。

（２）BASE64の概要
BASE64では、全てのデータを64個の文字（a-z、A-Z,0-9、+,/）で表す。
ネットワークスペシャリストを目指す女性SEハテナ　

なぜ64個？　
詳しく説明しますね。画像でも日本語でも、すべて01データです。以下でもう少し補足します。
❶文字
・アルファベットや数字：何らかの文字コード（基本的にはASCIIコード）で2進数にする　（※JISコードなどでもアルファベットや数字部分は、ASCII変換でも結果が同じ）
・漢字やひらがなは、2バイト文字であるため、ASCIIコードでは表現できない。なので、JISコードなどの2バイトの文字コードを使って2進数に変換する。※文字コードによって変換結果は異なる。メールで送るときは、文字コードを伝えてあげないと、文字化けする

❷バイナリデータ
画像や音声などのバイナリデータは、011001などと2進数で表されています。そのデータをそのまま使います。

この0と1のデータを変換して、テキストデータにします。
やり方は、01データを6ビットずつに区切ります。6ビットなので、000000～111111の64パターン。だから、64個の文字があれば、すべてのビットパターンを表現できのです。
※厳密にはパディングの=があるので、65個です。パティングは、ちょうど6ビットに収まらなかった場合に=で詰め物をします。

また、暗号化ではありません。元に戻すことも簡単です。

（３）エンコードの実例
たとえば、Helloという文字を送る場合。
「Hello」は8ビット文字として以下のようにあらわされる。
Hello
01001000　　・・・H
01100101　　・・・e
01101100　　・・・l
01101100　　・・・l
01101111　　・・・o

ここで、6ビットに変換する。

010010　
000110　
010101　
101100　
011011　
000110　
1111　　　←端数がでるので、最後は0埋めし、111100とする。

変換表に基づき、文字に変換する。

010010　S
000110　G
010101　V
101100　s
011011　b
000110　G
111100　8

SGVsbG8=　となる。　※=はパディング　
6ビットで区切り、8ビットの文字に変換するため、データは4/3倍に膨れ上がる。

（４）過去問
過去問（H18SV午後2問2）を紹介する。

過去問（H18SV午後2問2）
S/MIMEを使用した場合,添付されるバイナリデータは,ASCIIで表現される64種類の文字と特殊用途の“="を使って表現する［　f　］方式に従って,テキストデータに変換される。64種類の情報を表現するために必要なビット数は,［　g　］ビットである。ここで, 1バイトが8ビットで,［　g　］と8の最小公倍数が［　h　］になり,［　h　］ビットは［　i　］バイトである。したがって,［　i　］バイトのバイナリデータから, 4バイトのテキストデータが生成される。　つまり,添付されるテキストデータは,パディング文字や改行文字などを無視すると,バイナリデータの［　j　］倍になる。このことから,調達ファイルのような大量のデータを転送する場合には注意が必要である。

過去問（H18SV午後2問2）

S/MIMEを使用した場合,添付されるバイナリデータは,ASCIIで表現される64種類の文字と特殊用途の“="を使って表現する［　f　］方式に従って,テキストデータに変換される。64種類の情報を表現するために必要なビット数は,［　g　］ビットである。ここで, 1バイトが8ビットで,［　g　］と8の最小公倍数が［　h　］になり,［　h　］ビットは［　i　］バイトである。したがって,［　i　］バイトのバイナリデータから, 4バイトのテキストデータが生成される。　つまり,添付されるテキストデータは,パディング文字や改行文字などを無視すると,バイナリデータの［　j　］倍になる。このことから,調達ファイルのような大量のデータを転送する場合には注意が必要である。

↓
↓
↓
↓
↓
正解は、以下。
f：BASE64
g：6
h：24
i：3
j：1.3　※4/3を四捨五入。

もう一問。

過去問（H18NW午前問29）
問29　30kバイトのJPEGファイルを電子メールに添付するとき、実際の転送データはおよそ何kバイトになるか。ここで、添付ファイルはMIME　Base64を用いてエンコーディングされるものとする。

↓
↓
↓
↓
↓
正解：40kバイト

（５）エンコードデコードのツール
以下のツールを使うと、Base64の変換などがWebで簡単にできる
https://gchq.github.io/CyberChef/
BASE64やハッシュ関数あたりが使えそう

また、rot13を使うと（検索から）、シーザー暗号を指定文字だけずらすことができる。
rot13（シーザー暗号）については、Linuxのコマンドtrでも可能。trの後半の文字列は、〇〇を△△に変換、などの意味だろうが、よくわかっていない。
# echo abc | tr 'n-za-mN-ZA-M' 'a-zA-Z'
nop　←abcを13文字ずらした文字になった。

ハッシュ関数などの演算処理は、opensslコマンドでも可能
ためしにBASE64でエンコードしてみよう
# echo -n abc | openssl base64
YwJj
※echoでパイプで渡している。-nが無いと、最後に改行コードが入ってしまう。

6.BASE64によるエンコードとデコードを実演

❶エンコードしたいファイルを該当場所に置く。
※今回は、Cドライブ直下に、org.txtというファイルを置いた。

❷コマンドプロンプトを管理者で実行する
Base64をやってみる1

❸以下のコマンドを実行。とても簡単。

c:\>certutil -encode org.txt result.txt
入力長 = 5
出力長 = 66
CertUtil: -encode コマンドは正常に完了しました。

❹作成したファイルを確認する。
※今回は同じ場所（Cドライブ直下）にresult.txtというファイルができている。

-----BEGIN CERTIFICATE-----
SGVsbG8=
-----END CERTIFICATE-----

では、別の実験をする。添付ファイルもこれをすれば文字列になる。
であれば、添付ファイルが送れない環境であっても、メール本文に画像をBASE64のエンコードをしてテキスト化して貼り付けて送付し、受信した側でそのテキストをデコードすれば、画像を受け取れるのではないか。ためしにやってみよう。

❶画像ファイルを該当場所に置く
以下の画像を、seeeko.jpgという名でCドライブ直下に置いた
ネットワークスペシャリストを目指す女性SE
❷先ほどと同じように、コマンドプロンプトからエンコードを実行

c:\>certutil -encode org.txt result.txt
入力長 = 5
出力長 = 66
CertUtil: -encode コマンドは正常に完了しました。

ファイルサイズは5kだったものが6kとなっただけで、あまり変わっていない。
以下が、result.txtの中身。

❸ここで、この内容をメールで送る。

❹メールを受信する。
そして、同じようにテキストファイルに貼り付ける。

❺同じようにコマンドプロンプトを開き、こんどはデコード（decode）をする

c:\>certutil -decode result.txt seeeko.jpg
入力長 = 6138
出力長 = 4422
CertUtil: -decode コマンドは正常に完了しました。

すると、もとの画像ファイルが復元できた。

7.メールのエンベローブ、ヘッダ

メールは、メールヘッダ（SubjectやFromなどの情報）とメール本文からなる。
この点は理解しやすいだろう。加えて、エンベロープというものがある？
エンベロープ(envelope)は、英語の通り、封筒という意味である。手紙に「○○さんへ」と宛先を書いたり、自分の名前を書いた上で封筒に宛名と差出人を書く。そんなイメージをしてほしい。
この処理は、メールソフトが自動で作成するため、ユーザにはわからないかもしれない。試験では、本当にたまに出題され、H23春SC午後Ⅱでも出題されている。
図で書いたほうがわかるので、以下を参照ください。
エンベロープ (1)

エンベローブ（封筒）	MAIL FROM：送信元メールアドレス RCPT TO：送信先メールアドレス
メールヘッダ	DATE:時刻 FROM：送信元メールアドレス TO:宛先メールアドレス Subject：題名・・・・・
メール本文	こんにちは、来週の会議について、、、、

エンベローブがなぜいるのですか？
なくてはいけないの？
エンベローブはSMTP通信において、必須なのである。逆にメールヘッダは不要。なくても通信ができる。
メールが作成されるところをイメージしてもらうといいが、利用者は使いやすいメールソフトでメールを作る。そのときに作られるのがメールヘッダとメール本文である。それを実際に通信するときは、SMTPコマンドで通信するため、エンベローブにメールヘッダの情報がコピーされて、通信される。

過去問（R1秋SC午後Ⅰ問1）では、「エンベロ－プの送信者メールアドレス（以下, Envelope-FROMという）と，メールデータ内のメールヘッダで指定される送信者メールアドレス（以下, Header-FROMという）がある。」とあります。

先の表に記載しましたように、送信されるコマンドも違います。
・Envelope-from　→　MAIL FROMコマンド
・Header-From　→　DATAコマンド

※余談ですが、エンベロープFromの情報は、メールヘッダではReturn-Pathに記載される。古いメーリングリストなどでは、メールを転送（送信者→送信者のメールサーバ→メーリングリストのメールサーバ→宛先）する際に、Return-Pathは送信者のままとしていた。すると、宛先からすると、エンベロープFromは送信者のドメインであり、実際に送られてくるのはメーリングリストのサーバからなので、SPFに失敗する。今では、エンベロープFrom（つまりメールヘッダではReturn-Path）には、メーリングリストの管理者に設定するので、SPFは失敗しない）

8.メールのフレーム（パケット）構造

以下は、ネスペ27で書いた内容です。メールのフレーム構造（パケット構造）を理解するのにちょうどいいと思いますので掲載します。
固有名詞などは、この書籍のままです。詳しくは、本書をご確認ください。

「この図において、服部課長のPCから私の携帯にメールを送るとする。このとき、服部課長のPCから出た直後のフレーム構造、パケット構造を書いて欲しい」

宛先MACアドレス	送信元MACアドレス	タイプ	送信元IPアドレス	宛先IPアドレス	プロトコル	送信元ポート番号	宛先ポート番号	データ	FCS
						20000（仮）		―	―

↓
↓
↓
↓
↓
A.服部課長から送られたメールは、社内のメールサーバに送られます。よって、宛先IPアドレスはメールサーバ（10.1.1.25）になります。また、宛先MACアドレスは、L3SWのMACアドレスです。L2のフレームは、ルータなどのL3デバイスを超えられないからです。そして、メール送信はSMTP通信なので、宛先ポート番号は25番です。
正解をまとめると、以下のようになります。

宛先MACアドレス	送信元MACアドレス	タイプ	送信元IPアドレス	宛先IPアドレス	プロトコル	送信元ポート番号	宛先ポート番号	データ	FCS
L3SWのMACアドレス	服部課長のPCのMACアドレス	IPv4	192.168.1.101	10.1.1.25	TCP	20000（仮）	25	―	―

ネットワークスペシャリスト - SE娘の剣 -

左門至峰によるネットワークスペシャリストの試験対策サイトです。勉強方法、合格体験談、合格のコツ、過去問解説、基礎知識などの紹介します。

1.電子メール

2.電子メールのヘッダ

3.メールの宛先（To、Cc、Bcc)

4.MIME　マイム

5.Base64

6.BASE64によるエンコードとデコードを実演

7.メールのエンベローブ、ヘッダ

8.メールのフレーム（パケット）構造

1.電子メール

2.電子メールのヘッダ

3.メールの宛先（To、Cc、Bcc)

4.MIME マイム

5.Base64

6.BASE64によるエンコードとデコードを実演

7.メールのエンベローブ、ヘッダ

8.メールのフレーム（パケット）構造

4.MIME　マイム