ウィキペディアから利用できる電子メール（ウィキメール）については、Help:ウィキメールをご覧ください。 メールは、この項目へ転送されています。その他の用法については「メール (曖昧さ回避)」をご覧ください。 電子メール（でんしメール、electronic mail、略してe-mail、Eメール、メールとも）は、コンピュータネットワークを使用してメッセージを交換する手段である。 目次 1 概要 2 電子メールを支える技術 2.1 一般 2.2 プロトコル 2.3 文字コード 2.4 メール形式 2.5 ヘッダ情報 2.5.1 代表的なヘッダフィールド 3 機能 3.1 CcとBcc 3.2 ReとFw 4 歴史 4.1 電子メールの起源 4.2 一般への浸透 5 問題 5.1 トラフィックの増大と配送遅延 5.2 スパムメール対策の問題点 5.3 コミュニケーション上の問題 6 脚注 7 関連項目 8 外部リンク 編集 概要 インターネットの初期からある通信手段であり、Unix to Unix Copy Protocol (UUCP) やSimple Mail Transfer Protocol (SMTP) などのプロトコルを介して、メールを相手サーバに届ける事ができる。電気的な信号で送受信を行うのでかかる時間は数分程度である。 一方で、インターネットの普及以前にコンピュータ通信手段として広く行われていた、いわゆるパソコン通信でも、加入者同士で文書のやり取りを行うシステムが「電子メール」として提供されていた。ただし、パソコン通信では、一般的に、通信が1つのパソコン通信システム内にとどまっていたので、他のシステムとの間での電子メールの交換機能などの相互通信機能は、一部のケースを除きほとんどなかった。また、各パソコン通信システムごとに独自のシステムが構築されていた事が多かったため、ユーザインタフェース等についても互換がなかった。しかしその後、インターネットの普及に伴い、大手パソコン通信システムとインターネット間で相互に通信が可能にもなった。メール友達（メル友）も、流行になった時期があった。 インターネットが普及し始めた頃（あるいは現在も）は電子掲示板(BBS)の書き込みやブログのコメントさえも含めて、「メール」と呼称していたライトユーザが多かった。 また、携帯電話やPHS間でごく短い文字メッセージ（メール）をやりとりする、ショートメッセージサービス（SMS。iモードなどのサービス開始前より行われている）も、広義の電子メールに含まれる。 クライアント環境にウェブブラウザ以外のソフトウェアを必要としないWebメールも広義の電子メールであり、これを用いたフリーメールサービスも普及している（Yahoo!メール、Hotmail、Gmail、gooメールなど）。 なお、以下ではRFCに準拠した、UUCP/SMTPのプロトコルを使用した電子メールについてのみ記述する。それ以外の電子メールについては上記の各関連項目を参照のこと。 編集 電子メールを支える技術 編集 一般 個々の電子メールのアドレスは、xxxx@example.co.jp などのような形で表現される。実際に電子メールを使うためには独自ドメイン名（この例では "example.co.jp"）を得て、ドメイン名を管理するDNSサーバやメールサーバに登録する必要がある。 一般的には、加入プロバイダや勤務先・通学先の企業・学校などのアドレス（アカウント）になっていることが多い。 容量については理論的には制限はないが、送受信可能な最大容量は、プロバイダの提供する容量で制約を受ける。一般的には、ダイヤルアップ接続時代の名残の数メガバイトから、近年のブロードバンド対応として大容量を謳ったものでは100メガバイト程度に設定されることが多い要出典。これ以上の大容量のデータのやり取りにはFTPやP2Pなどが使われることが多い。 無料アドレス（フリーメールサービス）の場合は、プロバイダなどのアカウントで利用する一般的な電子メールクライアントではなく、Webブラウザを使いWebページ上で、送受信を行うWebメールがほとんどである。 編集 プロトコル 現在、インターネットでは、メールサーバ間での通信およびクライアントからの送信には、一般にSMTPが使われる。古くは、また現在でも希に、UUCPが使われる。メールは、数々のサーバをリレーのように経由して目的のメールサーバに伝えられる。なお、電子メールには、送信者の使用メールソフトや経由サーバなどのヘッダーと呼ばれる情報が付属されている。 メールサーバからメールを読み出す場合には、Post Office Protocol (POP) 、Internet Message Access Protocol (IMAP) などのプロトコルが用いられる。メールの書式については、RFC 5322で規定がある。また、英語以外の言語やテキスト以外のデータをメールで送るなどのためにMultipurpose Internet Mail Extensions (MIME) が規定されている。 編集 文字コード 元来のメールの文字コードはUS-ASCIIのみであったが、上記MIMEの規定により様々な文字コードが使えるようになった。 かつての日本のJUNETではJIS規格に基づくルールを決めて日本語を扱えるようにした[1]。このルールをMIMEの枠組みで再定義したものがISO-2022-JPである。現在の日本語メールでは、このISO-2022-JPが広く用いられている。 RFC 2277では、出来るだけ広く知られた文字コードを選ぶように注意を促している。これはUTF-8が普及するまでの暫定的なものであるが、その期間は50年であるかもしれないので事実上は永遠と考えてよいとも書かれている[2]。 編集 メール形式 元来は、メールはプレーンテキスト形式の物のみであったが、上記MIMEの規定および普及に伴い、メール本文をHTMLにより記述したHTML形式のメールも、RFCに規定され一般にも使われるようになった。HTML形式のメールを単にHTMLメールと呼ぶ事も多い。 HTML形式のメールは、メール本文をHTMLで記述できるため、メールにWebページと同様の表現力を持たせられる利点がある。携帯電話・PHSでも、cHTML形式のメールが一般向け仕様のサービスとして提供されているものもある。 その一方で、特に、Microsoft Windowsと、その標準電子メールクライアントであるOutlook Express（メールの作成はHTML形式がデフォルト）の普及に伴い、HTML形式のメールが送受信されることも多くなった。しかしながら、電子メールクライアントにおいては、メール中のHTMLデータを展開し表示するためのレンダリングエンジン（Internet ExplorerをはじめとするWebブラウザ）にしばしばセキュリティホールが発見されているため、メールを見る（プレビューする）だけで、コンピュータウイルスが侵入する被害を受けたり、迷惑メール・架空請求メール等で画像タグを埋め込んだメールを送りつけて表示させ、メールを表示させた情報を収集（ウェブビーコンと言う）して悪用するなど、セキュリティ上の問題がある（ただし「HTMLメールを表示する事」は「ブラウザでWebページを表示する事」と、技術的には根本的な違いはない）。対策としては、ウイルス対策・迷惑メール対策ソフトを導入するか、もしくはHTML形式のメールをフィルタリング機能で受信を拒否する・ゴミ箱フォルダへ振り分けるなどがある。また、HTMLメールの表示に対応していない電子メールクライアントもあり、断り無くHTML形式のメールを送信しても正しく受信されないおそれがある。 なお、あるファイルデータをメールに添付して送る場合、添付ファイルとしてMIMEなどによってテキスト化（エンコード）をしてメール本文に埋め込んで送信し、受信側で元のデータファイルに復元（デコード）する方法が取られる。添付ファイルには、コンピュータウイルスも仕込む事が可能なため、受信時に添付ファイルを自動的に開く設定になっていると、やはりコンピュータウイルスが侵入する被害を受けるなどの危険もある。 編集 ヘッダ情報 一通一通それぞれのメールは、本文とは別に、ヘッダフィールドと呼ばれる各種の特殊な情報が記載された領域を持つ。殆どの電子メールクライアントでは、何らかの方法（電子メールクライアント毎に異なる）によって、このヘッダフィールドの情報を参照可能である。この情報は、脅迫メールやスパムなどのメールが届く場合などに、送信元の特定などに威力を発揮する。ただし、偽装も可能で必ずしもすべてのヘッダフィールドを付加する必要はないため、完全に判断することはできない。 編集 代表的なヘッダフィールド ヘッダフィールドは フィールド名:フィールド値 という形で記載される。 Return-Path SMTP通信で送信元として伝えられるメールアドレス Received このメールが届くまでに経由したメール転送エージェント（IPアドレス）および経由した日時 Message-ID メール一通一通に付加された固有の番号 In-Reply-To 返信元メールなどのMessage-IDの値のリスト From 著者のメールアドレス[3]。単数または複数の名前やアドレスも含めることができる。 このヘッダの記載は送信者が電子メールクライアントの設定によって自由に変更できる。このような電子メールの仕様から、いわゆる「なりすまし」などの悪用を完全に防ぐことは困難とされる。 Sender 送信者のメールアドレス[4]。名前も含めることができる。著者と送信者が同一、すなわちFromが単一のアドレスでSenderと同じ場合は使うべきではない。逆に、異なる場合は必須である。 To 受取人のメールアドレス。単数または複数の名前やアドレスも含めることができる。 Cc・Bcc それぞれカーボンコピーとブラインドカーボンコピーの受取人のメールアドレス。単数または複数の名前やアドレスも含めることができる。#CcとBccを参照。 Reply-To 送信者が返信先として希望するメールアドレス Subject 話題を表す短い文。日本語ではサブジェクト、件名などと呼ばれる。返信の場合はRe:、転送の場合はFw:が先頭に自動的に付加される場合が多い（#ReとFwを参照）。 Date 送信者が送信を行った日時 MIME-Version MIMEのバージョン X-Priority 送信者が指定した重要度 X-Mailer 電子メールクライアントの種別 X-IP 送信者のグローバルIPアドレス X-FROM-DOMAIN 送信者のドメイン 編集 機能 編集 CcとBcc 電子メールを送信する際の機能として、Cc（カーボンコピー、Carbon Copy）とBcc（ブラインドカーボンコピー、Blind Carbon Copy）とがある。メールの本来の送信先は一般的にTo:に指定して送信するが、本来の送信先以外にも一応コピーを送っておきたい相手などがいる、という場合にこの機能を使用する。 メールを初めて利用する人はもちろん、それなりに使い慣れている人にしても、この機能の本来の使用方法を理解していない事も多い。この機能を使うに当たっては、よく理解して使えばとても便利であるが、私用・公用に限らず、Cc機能とBcc機能の違い・それぞれに指定されて送信された相手に見える自分以外の送信先をよく理解して使わないと、例としてメールアドレスの個人情報漏洩など、色々な意味で問題を起こす事となる。 また、2010年現在でも、Bccとして指定したアドレスを他のユーザーに見せてしまう。または、ヘッダー内の別領域に書いてしまう。という困った障害を起こすソフトウェアが存在するため、Bcc機能を理解していてもあえて使わないユーザーも居る。 Cc（カーボンコピー、Carbon Copy） To:で指定した本来の送信先以外にも、一応コピーを送っておきたい相手などがいる場合に使用する機能である。 To:で宛先を指定するのと同様に、Cc:にコピーを送りたい相手を指定して使用する。To:に指定された本来の相手には、To:とCc:に指定された宛先が全て見える。また、Cc:に指定された相手にも、To:とCc:に指定された宛先が全て見える。 要するに、送信者 (From:)、To:の相手、Cc:の相手、の各3者相互で、各アドレスが各3者全員に知られることになる。 Bcc（ブラインドカーボンコピー、Blind Carbon Copy） To:で指定した本来の送信先以外にも、一応コピーを送っておきたい相手がいる、しかしTo:とCc:に指定した相手にはコピーを送った相手、もしくはその相手がいることを知られたくない、という場合などに使用する機能である。 To:で宛先を指定するのと同様に、Bcc:にコピーを送りたい相手を指定して使用する。メールの送信時に、メールサーバ (MTA) においてBcc:ヘッダを削除して転送するため、To:/Cc:に指定された相手には、このBcc:に指定された宛先は全く見えない。しかし、Bcc:に指定された相手には、To:とCc:に指定された宛先が全て見える。また、Bcc:の宛先アドレスが複数ある場合には、Bcc:指定された各宛先相互間で、自分以外の他の宛先を知ることはできない。 複数の電子メールクライアントから単一のメールアカウント・サーバにアクセスする場合には、Bccを活用したテクニックがある。Bcc:にFrom:（自分自身）と同じアドレスを指定する（電子メールクライアント (MUA) による常時設定も可能）事により、自分が送信したメールがそのままの内容で自分の電子メールクライアントの受信箱にも配信される。POP3等のメールサーバでサーバから電子メールクライアントへ受信したメールをサーバから除去しない（数日後に削除する）設定を電子メールクライアントにすることにより、1つの電子メールクライアントから送信したメールが他の電子メールクライアント全てにコピーとして配信される。これにより、通常は送信した電子メールクライアントの送信済み箱を見ないと分からない所が、複数の電子メールクライアントで送信メールを確認できる。 ネチケットの一つとして推奨されてきた電子メールの送信方法であるが、一斉メールはどのような場合でもBccを使用するべきかといえばそうでもない。例えば全メンバーがメールアドレスを交換し合っているグループ内ではBccを使う必要性はなく、むしろ宛先と目的がはっきりと明示されているToとCcを使いわけるのが普通である。時と場合によりTo/Cc/Bccを適切に使い分けるには高度なネチケット知識が必要である。 なお、時々「ブラックカーボンコピー（Black Carbon Copy）」と言われることがあるが、これは間違いである。 メールを送受信したときの To, Cc, Bcc それぞれの見え方 From:A@example.com To: B@example.com, C@example.com Cc: D@example.com, E@example.com Bcc: F@example.com, G@example.com と送信する場合。 メールアドレスの指定と関係 指定 送受方向 メールアドレス From 送信者 A@example.com To 受信者 B@example.com, C@example.com Cc D@example.com, E@example.com Bcc F@example.com, G@example.com それぞれの送受信者からのメールアドレスの見え方 メールの読み手 表示 A@example.com B@example.com C@example.com D@example.com E@example.com F@example.com G@example.com 送信者 To指定受信者 Cc指定受信者 Bcc指定受信者 A@example.com 表示される B@example.com 表示される 表示されない C@example.com 表示される 表示されない D@example.com 表示される 表示されない E@example.com 表示される 表示されない F@example.com 表示される 表示されない場合もある 表示されない G@example.com 表示される 表示されない 表示されない場合もある この場合 G@example.com から見ると、メールのヘッダ情報から以下のようなことが分かる。 From:A@example.com To: B@example.com, C@example.com Cc: D@example.com, E@example.com Bcc: G@example.com（表示されない場合もある） AからBとCへメールを送信し、同じ内容がDとEに送られたことが分かる。 更に同じ内容が自分 (G) に送られたことが分かる。 しかし同じ Bcc でもFに送られたことを知ることは出来ない。 編集 ReとFw Re 多くの電子メールクライアントでは、返信されたメールのサブジェクト先頭に自動的にRe:またはRE:という記号を付加する。この略号は、受け取ったメールの表題「○○」に対し返事の表題「○○に関して」を自動的に付ける便宜上のものであり、送信者が意図的に削除しても構わない。古くからビジネス文書で使われていた慣習(regardingの意で"RE"をタイピングする)が、電子メール発祥期のメールコマンドに採用され、さらにはRFCに記載されたことで定着したが、他にも諸説ある。 詳細は「Re:」を参照 Fw（フォワード、Forward） 一部の電子メールクライアントでは、メールを転送する際に、サブジェクト先頭に自動的にFw:などの記号を付加することがある。この略号はReと同様単なる便宜的なものであるだけでなく、RFCにすら記述の無い独自仕様である。例えば、Fw:が連続していれば何度も転送されたメールだと考えることもできるが、それはあくまで、一部の電子メールクライアントの仕様に過ぎず、一般的な理解ではない。Fw:の連続はチェーンメールに多いため、チェーンメールかどうかの目安にもなる。そのため、転送時にFw:を削除するように指示する内容が記述されたチェーンメールもある。 編集 歴史 編集 電子メールの起源 電子メールはインターネットに先行して開発された。既存の電子メールシステムはインターネットを作るに当たって重要な道具となった。 最初の電子メールは1965年、メインフレーム上のタイムシェアリングシステムの複数ユーザーが相互に通信する方法として使われ始めた。正確なところは不明だがその類の機能を持つ最初のシステムとして、SDC（ランド研究所からのスピンオフでSAGEのソフトウェア開発を行った会社）のQ32システムとMITのCTSSがある。 電子メールは間もなくユーザーが異なるコンピュータ間でメッセージをやり取りするための「ネットワーク電子メール」に拡張された。1966年には異なるコンピュータ間で電子メールを転送していた（SAGEでの詳細は明らかではないが、もっと早い時期に実現していたかもしれない）。 ARPANETは電子メールの発展に多大な影響を与えた。その誕生直後の1969年にシステム間電子メール転送の実験を行ったというリポートがある[5]。BBN社のレイ・トムリンソンは1971年にARPANET上の電子メールシステムを開発し、初めて@を使ってユーザー名とマシンを指定できるようにした[6]。ARPANET上では電子メール利用者が急激に増大し、1975年には1000人以上が利用するようになっていた。 編集 一般への浸透 ARPANETでの電子メールの利便性と利点が一般に知られるようになると、電子メールの人気が高まり、ARPANETへのアクセスができない人々からもそれを要求する声が出てきた。タイムシェアリングシステムを代替ネットワークで接続した電子メールシステムがいくつも開発された。例えばUUCPやIBMのVNETなどがある。 全てのコンピュータやコンピュータネットワークが直接相互に接続されるわけではないので、電子メールのアドレスにはメッセージの伝達「経路」、つまり送信側コンピュータから受信側コンピュータまでのパスを示す必要があった。電子メールはこの経路指定方法でいくつものネットワーク間（ARPANET、BITNET、NSFNET）でやり取りすることができた。UUCPで接続されたホストとも電子メールをやり取りすることが可能であった。 経路は「バングパス」と呼ばれる方法で指定された。あるホストから直接到達可能なホストのアドレスを書き、そこから次に到達可能なホストのアドレスをバング（感嘆符＝!）で接続して書いていくアドレス指定方式である。 CCITTは、種々の電子メールシステムの相互運用を可能とするために 1980年代にX.400標準規格を開発した。同じ頃、IETFがもっと単純なプロトコルSimple Mail Transfer Protocol (SMTP) を開発し、これがインターネット上の電子メール転送のデファクトスタンダードとなった。インターネットに各家庭から接続するようになった現代では、SMTPベースの電子メールシステムの相互運用性は逆にセキュリティ上の問題を生じさせている。 1982年、ホワイトハウスは国家安全保障会議 (NSC) スタッフのために IBM の電子メールシステム Professional Office System （PROFシステム）を採用した。1985年4月、このシステムがNSCスタッフ向けに完全動作するようになった。1986年11月、ホワイトハウスの残りの部分もオンライン化された。1980年代末ごろまではPROFシステムだけだったが、その後は様々なシステムが導入されている（VAX A-1（オールインワン）や、cc:Mailなど）。 編集 問題 編集 トラフィックの増大と配送遅延 電子メールのトラフィックの多くは実はスパムメールである。ある報告[7]によると、2007年中に送信されたメールのうち90%から95%がスパムメールであったという。大量に送信されるこれらのスパムメールはメールサーバに過大な負荷を与え、メール配送遅延の原因となることもある。たとえば2004年7月下旬から8月上旬にかけて、大手インターネットプロバイダ@niftyで、海外から大量に送信されたスパムメールによりメールサーバに断続的な負担が掛かり、メールの受信に支障が生じる状態が続いた[8]。（2010年10月ロシアで摘発されたスパムメール業者は1日500億通を発信していたという。） また近年、トロイの木馬などのマルウェアに感染したコンピュータ群によって引き起こされるDDoS型のスパム送信の割合が急激に増加しており、ますますメールサーバに多大な負荷を及ぼすものとされている（→ボットネットを参照）。 スパム以外のトラフィック増大要因として、いわゆる「年賀メール」（元旦前後に発生する大量の挨拶メール）の類もある。特に携帯電話・PHSのメール機能は「即時にコミュニケーションを取りあう手段」としてチャット的に利用される場合があるため、一般の電子メールに比べ大量かつ集中的に送信されやすく、これを原因とした配送遅延や輻輳が問題になる場合もある。この対策として、各キャリアが年越時間帯の利用自粛を呼び掛けたり発信制限を行ったりすることもある。かつてパソコン通信が全盛だった時代には、処理の集中を防ぐため、あらかじめ年賀メールをサーバに予約送信しておき元旦に順次配送するといったサービスも提供されていた。 なお、電子メールの配送システムの多くは、メールサーバに一定以上の負荷が掛かると送信を保留し一旦スプールに保存し後に（例えば数時間後に）再送信を試みる仕組みになっているため、トラフィックが一定量を超えると配送の極端な遅延が起こる。この遅延はメール1通毎に起こるため、同時期に送ったメールであっても、あるものは数秒で届きあるものは数時間で届くということになり、これを理解しないユーザ間ではメールを「送った」「送らない」でトラブルになる恐れもある。 一時的なトラフィックの増大でスプールに保存された保留メールは、多くの場合時間の経過と共に処理され正常に戻るが、メールサーバの能力が十分でないと再送処理自体が間に合わなくなり、送信者にエラーが返送されることもある。なお、エラーすら返送されず「消滅」することは原理的にありえない。メールサーバは能力が追い付かない場合メールの受信(SMTPコネクション)自体を拒否するからである。よく年賀メール等で「トラフィック増大が原因であるプロバイダのメールの紛失が起きた」と、あたかも不可抗力であるが如き報道を目にするが、正確にはそのプロバイダのメールサーバの管理が適切でなく、混雑時の処理が正しく動作していないシステム不良である。 同時多発テロ時には、ニューヨーク周辺間のメールが1日遅延するなどした他、2009年には南アフリカでケープタウンとヨハネスブルグ間700kmで実験が行われ、電子メールより伝書鳩の方が早く情報を伝達できた。 編集 スパムメール対策の問題点 スパムメール対策としてサーバ上、クライアント上でのフィルタリングが普及してきたが、誤検知により通常のメールがスパムであると判断されてしまい、不着となるトラブルが増えている（→電子メールフィルタリングを参照）。 編集 コミュニケーション上の問題 方言の違いなどにより話し言葉の発音が通じない人同士の間でも文字でコミュニケーションができるため、人の交流が広域化した現代ではメールによるコミュニケーションは有用である（日本、中国、イギリスなど方言が多様な国では特に）一方、パソコン通信やインターネット等における文字だけのコミュニケーションに見られる問題（炎上、Flaming）は電子メールにおいても見られる。メールの真意、感情が相手に伝わらず、度々トラブルに発展するケースが挙げられている。英語圏では、メールの真意を読み取り間違え、感情に任せて送るメールの呼称（スラング）にFlame Mailというものがある。 編集 脚注 ヘルプ ^ JUNET利用の手引(第1版) ^ Using International Characters in Internet Mail ^ ここでいう「メールアドレス」は、技術的にはメールボックス・リスト (mailbox-list) という。BCC、CC、Reply-To、Toも同様。 ^ ここでいう「メールアドレス」は、技術的にはメールボックス (mailbox) という。 ^ Tom Van Vleck (2001年2月1日). “The History of Electronic Mail”. 2008年2月21日閲覧。 ^ Ray Tomlinson. “The First Network Email”. 2008年2月21日閲覧。 ^ 勝村幸博 (2007年12月14日). “「メールの95％は『迷惑メール』だった」、2007年のスパム動向”. ITpro. 日経BP社. 2008年2月21日閲覧。 ^ “会員サポート > 大量スパムメールによるメール遅延、ならびに対策について”. @nifty. ニフティ (2004年8月13日). 2008年2月21日閲覧。 編集 関連項目 メールアドレス メールマガジン フリーメールサービス プッシュ型電子メール Webメール メーリングリスト メールサーバ - Domain Name System（DNS） 電子メールクライアント（電子メールソフト、メールクライアント、MUA） スパム (メール)（迷惑メール） ストアアンドフォワード 編集 外部リンク 大和総研/コラム：フィッシング詐欺が再喚起するHTMLメールの危険性 署名区切り行：sig-dashes Email Standards Project （英語）