検索に移動この記事には複数の問題があります。改善やノートページでの議論にご協力ください。出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。(2016年9月)独自研究が含まれているおそれがあります。(2016年9月)ウィキペディアから利用できるEメール(ウィキメール)については、Help:ウィキメールをご覧ください。「メール」はこの項目へ転送されています。(曖昧さ回避)」をご覧ください。日本の郵便サービスの「電子郵便」については「レタックス」をご覧ください。mail、E-mail、Eメール)は、コンピュータネットワークを使用して、郵便のように情報等を交換する手段である。電子郵便(でんしゆうびん)とも言う。外部リンク概要[編集]インターネットの初期からある通信手段であり、UUCPやSMTPなどのプロトコルを介して、メールを相手サーバに届けられる。電気的な信号で送受信を行うのでかかる時間は数分程度である。一方で、インターネットの普及以前にコンピュータでの通信手段として広く行われていた、いわゆるパソコン通信でも、加入者同士で文書のやり取りを行うシステムが「電子メール」として提供されていた。パソコン通信では、一般的に、通信が1つのパソコン通信システム内にとどまっていたので、他のシステムとの間での電子メールの交換機能などの相互通信機能はほとんどなかった。各パソコン通信システムごとに独自のシステムが構築されていた事が多かったので、ユーザインターフェイス等についても互換がなかった。その後、インターネットの普及に伴って、大手パソコン通信システムとインターネット間で相互に通信が可能にもなった。メール友達(メル友)も、流行になった時期があった。以下では「広義のメール」と記載が無い物はRFCに準拠した、UUCP、SMTPのプロトコルを使用した電子メールについてのみ記述する。それ以外の電子メールについては上記の各関連項目を参照のこと。ものであり、電話との使い分けがビジネス・マナーかつ礼儀だった。今後はもう一度、この本来の目的を意識して円滑なコミュニケーションを取ることが課題と言えよう。狭義のメール[編集]RFCに準拠した、UUCP、SMTPのプロトコルを使用した電子メール。クライアントの端末ソフト(ウェブブラウザやTelnet端末など)以外のソフトウェアを必要としないメール。そのサーバまではRFCに準拠した方法で伝達されている。ウェブメールも広義の電子メールであり、これを用いたフリーメールサービスも普及している。インターネットが普及し始めた頃(あるいは現在も)、それらを「メール」と呼称していた初心者がいた。携帯電話等の間でごく短い文章を送受信する、iモードなどのサービス開始前より行われている。総務省の定義ではRFCに準拠したメールとショートメッセージサービスをメールとしている。電子メールを支える技術[編集]一般[編集]個々の電子メールのアドレスは、「Yamada.Tarou@example.wikipedia.org」などのような形で表現される。実際に電子メールを使うためには独自ドメイン名(この例では「example.wikipedia.org」)を得て、ドメイン名を管理するDNSサーバやメールサーバに登録する必要があることがほとんどである。一般的には、加入インターネットプロバイダや勤務先・通学先の企業・学校などのアドレス(アカウント)になっていることが多い。容量については理論的には制限はないが、送受信可能な最大容量は、プロバイダの提供する容量で制約を受ける。一般的には、ダイヤルアップ接続時代の名残の数メガバイト(MB)から、近年のブロードバンド対応として大容量を謳ったものでは100MB~数GB(ギガバイト)程度に設定されることが多い[要出典]。主要プロバイダの一例としてはOCNが10MBまで[2]、So-netが20MBまで[3]、Biglobeが100MBまでである[4]。これ以上の大容量のデータのやり取りにはFTPやP2P、HTTP等によるオンラインストレージ、ファイル転送サービス、アップローダーなどを使用する。無料アドレス(フリーメールサービス)の場合は、プロバイダなどのアカウントで利用する一般的な電子メールクライアントソフトではなく、ウェブブラウザを使ってウェブページ上で、送受信を行うウェブメールがほとんどである。プロトコル[編集]現在、インターネットでは、メールサーバ間での通信およびクライアントからの送信には、一般にSMTPが使われる。古くは、また現在でも希に、UUCPが使われる。メールは、数々のサーバをリレーのように経由して目的のメールサーバに伝えられる。電子メールには、送信者の使用メールソフトや経由サーバーなどのヘッダーと呼ばれる情報が付属されている。メールサーバからメールを読み出す場合には、POP、IMAPなどのプロトコルが用いられる。5322で規定がある。英字以外の文字・言語やテキスト以外の情報をメールで送るなどのためにMIMEが規定されている。文字コード[編集]元来のメールの文字コードはUS-ASCIIのみであったが、上記MIMEの規定により様々な文字コードが使えるようになった。日本のJUNETではJIS規格に基づく規則を決めて日本語を扱えるようにした[5]。この規則をMIMEの枠組みで再定義したものがISO-2022-JPである。現在の日本語メールでは、このISO-2022-JPが広く用いられている。2277では、出来るだけ広く知られた文字コードを選ぶように注意を促している。これはUTF-8が普及するまでの暫定的なものであるが、その期間は50年であるかもしれないので事実上は永遠と考えてよいとも書かれている[6]。メール形式[編集]元来は、メールは文章程度のプレーンテキスト形式の物のみであったが、上記MIMEの規定および普及に伴って、メール本文をHTMLにより記述したHTML形式のメールも、RFCに規定されて一般にも使われるようになった。HTML形式のメールは、メール本文がHTMLで記述できるのでメールにWebページと同様の表現力を持たせられる利点がある。携帯電話・PHSでも、cHTML形式のメールが一般向け仕様のサービスとして提供されているものもある。Express(初期設定ではメールの作成時にHTML形式が選ばれる)の普及に伴って、HTML形式のメールが送受信されることも多くなった。Explorerをはじめとするウェブブラウザ)にしばしばセキュリティホールが発見されているので、メールを見る(プレビューする)だけで、コンピュータウイルスが侵入する被害を受けたり、迷惑メール・架空請求メール等で画像タグを埋め込んだメールを送りつけて表示させて、メールを表示させた情報を収集(ウェブビーコンと言う)して悪用するなど、セキュリティ上の問題がある(ただし「HTMLメールを表示する事」は「ブラウザでWebページを表示する事」と、技術的には根本的な違いはない)。対策としては、ウイルス対策・迷惑メール対策のソフトを導入するか、HTML形式のメールをフィルタリング機能で受信を拒否する・ゴミ箱フォルダへ振り分けるなどがある。HTMLメールの表示に対応していないメールクライアントもあって、断り無くHTML形式のメールを送信しても正しく受信されないおそれがある。あるファイルデータをメールに添付して送る場合、添付ファイルとしてMIMEなどによってテキスト化(エンコード)をしてメール本文に埋め込んで送信して、受信側で元のデータファイルに復元(デコード)する方法が取られる。添付ファイルには、コンピュータウイルスも仕込み可能なので、受信時に添付ファイルを自動的に開く設定になっていると、やはりコンピュータウイルスが侵入する被害を受けるなどの危険もある。ヘッダー情報[編集]一通一通それぞれのメールは、本文とは別に、ヘッダーフィールドと呼ばれる各種の特殊な情報が記載された領域を持つ。ほとんどのメールクライアントでは、何らかの方法(メールクライアント毎に異なる)によって、このヘッダーフィールドの情報を参照可能である。この情報は、脅迫メールやスパムなどのメールが届く場合などに、送信元の特定などに威力を発揮する。偽装も可能で必ずしもすべてのヘッダフィールドを付加する必要はないので、完全には判断できない。CcBccCcは写し受信者[7](32.08.04)、Bccは秘密受信者[7](32.08.05)の受取人のメールアドレス。単数や複数の名前やアドレスも含められる。#CcとBccを参照。Date送信者が送信を行った日時From著者のメールアドレス[8]。単数または複数の名前やアドレスも含められる。このヘッダーの記載は送信者がメールクライアントの設定によって自由に変更できる。このようなメールの仕様から、いわゆる「なりすまし」などの悪用を完全に防ぐことは困難とされる。In-Reply-To返信元メールなどのMessage-IDの値の一覧Message-IDメール一通一通に付加された固有の番号MIME-VersionMIMEのバージョンReceivedこのメールが届くまでに経由したメール転送エージェント(IPアドレス)および経由した日時Reply-To送信者が返信先として希望するメールアドレスReturn-PathSMTP通信で送信元として伝えられるメールアドレスSender送信者のメールアドレス[9]。著者と送信者が同一、すなわちFromが単一のアドレスでSenderと同じ場合は使うべきではない。逆に、異なる場合は必須である。主題[7](32.03.03)話題を表す短い文。返信の場合はRe:、転送の場合はFw:が先頭に自動的に付加される場合が多い(#ReとFwを参照)。To受取人のメールアドレス。単数または複数の名前やアドレスも含められる。保存形式[編集]この節の加筆が望まれています。eml形式:1メール1ファイルmbox:複数のメールを1ファイルにまとめる(ユーザー毎に1フォルダ1メール作成)Maildir:1メール1ファイルMH::1メール1ファイルな点は似るが、ディレクトリの仕様が違う機能[編集]CcとBcc[編集]メールを送信する際の機能として、Cc(写し受信者[7](32.08.04)[10])とBcc(秘密受信者[7](32.08.05)[11])の2種類ある。メールの本来の送信先は一般的にTo:に指定して送信するが、本来の送信先以外にも一応複製を送っておきたい相手などがいるという場合にこの機能を使用する。メールを初めて利用する人はもちろん、それなりに使い慣れている人にしても、この機能の本来の使用方法を理解していない事も多い[独自研究?]。この機能を使うに当たっては、よく理解して使えばとても便利であるが、私用・公用に限らず、Cc機能とBcc機能の違い・それぞれに指定されて送信された相手に見える自分以外の送信先をよく理解して使わないと、例としてメールアドレスの個人情報漏洩など、色々な意味で問題を起こす事となる。Bccとして指定したメールアドレスを他の受信者に見せたり、ヘッダー内の別領域に書くなどの欠陥を持つメールソフトが存在するので、Bcc機能を理解していてもあえて使わない利用者も居る[要出典]。CcToで指定した本来の送信先以外にも、一応複製を送っておきたい相手などがいる場合に使用する機能である。Toで宛先を指定するのと同様に、Ccに複製を送りたい相手を指定して使用する。Toに指定された本来の相手には、ToとCcに指定された宛先が全て見える。Ccに指定された相手にも、ToとCcに指定された宛先が全て見える。(From)、Toの相手、Ccの相手、の各3人相互で、各アドレスが各3人全員に知られることになる。BccToで指定した本来の送信先以外にも一応複製を送っておきたい相手がいるが、ToとCcに指定した相手には、複製を送信した相手のメールアドレス及び複製を送信した事実を知られたくない場合などに使用する機能である。Toで宛先を指定するのと同様に、Bccに複製を送りたい相手を指定して使用する。DATA)から削除されるので、To、Ccに指定された相手には、このBccに指定された宛先は全く見えない。Bccに指定された相手には、ToとCcに指定された宛先が全て見える。Bccの宛先アドレスが複数ある場合には、Bcc指定された各宛先相互間で、自分以外の他の宛先は分からない。複数のメールクライアントから単一のメールアカウント・サーバーに接続する場合には、Bccを活用した技がある。よる常時設定も可能)事によって、自分が送信したメールがそのままの内容で自分のメールクライアントの受信箱にも配信される。POP3等のメールサーバーでサーバーかメールクライアントへ受信したメールをサーバーから除去しない(数日後に削除する)設定をメールクライアントにすることによって、1つのメールクライアントから送信したメールが他のメールクライアント全てに複製として配信される。これによって、通常は送信したメールクライアントの送信済み箱を見ないと分からない所が、複数のメールクライアントで送信メールが確認できる。ネチケットの一つとして推奨されてきたメールの送信方法であるが、一斉メールはどのような場合でもBccを使用するべきかといえばそうでもない。特定の一斉送信されたメールについて、全ての受信者がメールアドレスを交換し合っている場合にはBccを使う必要性はなく、どちらかというと宛先と目的がはっきりと明示されているToとCcを使いわけるのが普通である。時と場合によりTo、Cc、Bccを適切に使い分けるためには高度なネチケット知識が必要である。時々「ブラックカーボンコピー[12]」と言われることがあるが、これは間違いである。ReとFw[編集]Re(返信)多くの電子メールクライアントでは、返信されたメールの件名の先頭に自動的にRe:またはRE:という記号を付加する。この略号は、受け取ったメールの表題「○○」に対し返事の表題「○○に関して」(Regarding~)を自動的に付ける便宜上のものであり、返信であることを示すマークではないから、送信者が意図的に削除しても構わない。古くから商用文で使われていた慣習が、電子メール発祥期のメールコマンドに採用され、さらにはRFCに記載されたことで定着したが、他にも諸説ある。記号を付加することがある。同様単なる便宜的なものであるだけでなく、RFCにすら記述の無い独自仕様である。連続していれば何度も転送されたメールだと考えることもできるが、それはあくまで、一部の電子メールクライアントの仕様に過ぎず、一般的な理解ではない。連続はチェーンメールに多いため、チェーンメールかどうかの目安にもなる。削除するように指示する内容が記述されたチェーンメールもある。歴史[編集]先駆的活動[編集]テキスト形式のメッセージを電気的に伝える方法は1800年代中頃のモールス信号による電報に遡る事が出来る。ドイツが使用したテレタイプ端末は[15]、その後テレックスが世界的に普及する1960年代末まで使われた。アメリカには同様なTWXがあり、1980年代末まで重要な通信方法の位置を占めた[16]。mail(エレクトロニック・メール)」という用語は一般的に電子化された送信文書全般を指して用いられた。1970年代前半にはファクシミリによる文書送信を指す用語として用いられる例もあった[17][18]。電子メールの起源[編集]電子メールはインターネットに先行して開発された。既存の電子メールシステムはインターネットを作るに当たって重要な道具となった。最初の電子メールは1965年、メインフレーム上のタイムシェアリングシステムの複数の利用者が相互に通信する方法として使われ始めた。1350台の端末間を繋ぎ、1件あたり平均3000文字のメッセージを月間3000万件取り扱えるようになった。AUTODINは18台の計算機化された大きな切替装置が運用を支え、さらに約2500台の端末を繋げるアメリカ共通役務庁(英語版)のアドバンスト・レコード・システムとも接続された[19]。正確なところは不明だがその類の機能を持つ最初のシステムとして、SDC(ランド研究所からのスピンオフでSAGEのソフトウェア開発を行った会社)のQ32システムがある。マサチューセッツ工科大学は1961年にCTSSを導入し[20]、複数の利用者が離れた端末から電話回線を使って中央システムにログインし、ディスクにファイルを保存し共有できる体制を整えた[21]。電子メールは間もなく利用者が異なるコンピュータ間で情報をやり取りするための「ネットワーク電子メール」に拡張された。1966年には異なるコンピュータ間で電子メールを転送していた(SAGEでの詳細は明らかではないが、もっと早い時期に実現していたかもしれない)。オンラインのインターネットコミュニティシステムにおいて、「個人的な注意」を通知するための電子メールが広く使われた[19][29]。OfficeVisionのPROFS[31][32]1982年:ディジタル・イクイップメント・コーポレーションのALL-IN-1[33]ARPANETは電子メールの発展に多大な影響を与えた。その誕生直後の1969年にシステム間電子メール転送の実験を行ったという報告がある[34]。BBN社のレイ・トムリンソンは1971年にARPANET上の電子メールシステムを開発し、初めて@を使って利用者名と機器とを指定できるようにした[35]。ARPANET上では電子メール利用者が急激に増大し、1975年には1000人以上が利用するようになっていた。その他にも、1978年までにUNIXメールがネットワーク化されUUCPとなり[36]、1981年にはIBMのメインフレームの電子メールがBOTNETで接続された[37]。一般への浸透[編集]ARPANETでの電子メールの利便性と利点が一般に知られるようになると、電子メールの人気が高まり、ARPANETへの接続ができない人々からもそれを要求する声が出てきた。タイムシェアリングシステムを代替ネットワークで接続した電子メールシステムがいくつも開発された。UUCPやIBMのVNETなどがある。全てのコンピュータやコンピュータネットワークが直接相互に接続されるわけではないので、電子メールのアドレスには情報の伝達「経路」、つまり送信側コンピュータから受信側コンピュータまでのパスを示す必要があった。電子メールはこの経路指定方法でいくつものネットワーク間(ARPANET、BITNET、NSFNET)でやり取りすることができた。UUCPで接続されたホストとも電子メールをやり取りすることが可能であった。経路は「バングパス」と呼ばれる方法で指定された。あるホストから直接到達可能なホストのアドレスを書き、そこから次に到達可能なホストのアドレスをバング(感嘆符=!)で接続して書いていくアドレス指定方式である。1980年代にX.400標準規格を開発した。開発し、これがインターネット上の電子メール転送のデファクトスタンダードとなった。インターネットに各家庭から接続するようになった現代では、SMTPを基礎とする電子メールシステムの相互運用性は逆にセキュリティ上の問題を生じさせている。(PROFシステム)を採用した。1985年4月、このシステムがNSC従事者向けに完全動作するようになった。1986年11月、ホワイトハウスの残りの部分もオンライン化された。A-1(オールインワン)や、cc:Mailなど)。問題[編集]トラフィックの増大と配送遅延[編集]電子メールのトラフィックの多くは実はスパムメールである。バラクーダネットワークスの報告[38]によると、2007年中に送信されたメールのうち90%から95%がスパムメールであったという。大量に送信されるこれらのスパムメールはメールサーバに過大な負荷を与え、メール配送遅延の原因となることもある。2004年7月下旬から8月上旬にかけて、大手インターネットプロバイダ@niftyで、海外から大量に送信されたスパムメールによりメールサーバに断続的な負担が掛かり、メールの受信に支障が生じる状態が続いた[39]。(2010年10月ロシアで摘発されたスパムメール業者は1日500億通を発信していたという。)また近年、トロイの木馬などのマルウェアに感染したコンピュータ群によって引き起こされるDDoS型のスパム送信の割合が急激に増加しており、ますますメールサーバに多大な負荷を及ぼすものとされている(→ボットネットを参照)。スパム以外のトラフィック増大要因として、いわゆる「年賀メール」(元旦前後に発生する大量の挨拶メール)の類もある。携帯電話等のメール機能は「即時の意思疏通を図る手段」としてチャット的に利用される場合があるため、一般の電子メールに比べ大量かつ集中的に送信されやすく、これを原因とした配送遅延や輻輳が問題になる場合もある。この対策として、各通信事業者が年越時間帯の利用自粛を呼び掛けたり発信制限を行ったりすることもある。パソコン通信が全盛だった時代には、処理の集中を防ぐため、あらかじめ年賀メールをサーバに予約送信しておき元旦に順次配送するといったサービスも提供されていた。電子メールの配送システムの多くは、メールサーバに一定以上の負荷が掛かると送信を保留し一旦スプールに保存し後に(例えば数時間後に)再送信を試みる仕組みになっているため、トラフィックが一定量を超えると配送の極端な遅延が起こる。この遅延はメール1通毎に起こるため、同時期に送ったメールであっても、あるものは数秒で届きあるものは数時間で届くということになり、これを理解していない利用者の間ではメールを「送った」「送らない」で揉める恐れもある。一時的なトラフィックの増大でスプールに保存された保留メールは、多くの場合時間の経過と共に処理され正常に戻るが、メールサーバの能力が十分でないと再送処理自体が間に合わなくなり、送信者に失敗通知が返送されることもある。失敗通知すら返送されず「消滅」することは原理的にありえない。メールサーバは能力が追い付かない場合メールの受信(SMTPコネクション)自体を拒否するからである。年賀メール等で「トラフィック増大が原因であるプロバイダのメールの紛失が起きた」と、あたかも不可抗力であるが如き報道を目にするが、正確にはそのプロバイダのメールサーバの管理が適切でなく、混雑時の処理が正しく動作していないシステム不良である。[要出典]同時多発テロ時には、ニューヨーク周辺間のメールが1日遅延するなどした他、2009年には南アフリカでケープタウンとヨハネスブルグ間700kmで実験が行われ、電子メールより伝書鳩の方が早く情報を伝達できた。スパムメール対策の問題点[編集]スパムメール対策としてサーバ上、クライアント上でのフィルタリングが普及してきたが、誤検知により通常のメールがスパムであると判断されてしまい、不着となる問題が増えている(→電子メールフィルタリングを参照)。コミュニケーション上の問題[編集]方言などが原因で口頭での意思疏通が叶わない人同士でも、文字による意思疏通を図れるため、人の交流が広域化した現代ではメールによる意思疏通は有用である(日本、中国、イギリスなど方言が多様な国では特に)。パソコン通信やインターネット等における文字だけの遣り取りに見られる問題(炎上、Flaming)は電子メールにおいても見られる。メールの真意、感情が相手に伝わらず、度々揉め事に発展するケースが挙げられている。Mailというものがある。