電子メール

概要

インターネットの初期からある通信手段であり、UUCPSMTPなどのプロトコルを介して、メールを相手サーバに届けられる。電気的な信号で送受信を行うのでかかる時間は数分程度である。

一方で、インターネットの普及以前にコンピュータでの通信手段として広く行われていた、いわゆるパソコン通信でも、加入者同士で文書のやり取りを行うシステムが「電子メール」として提供されていた。ただし、パソコン通信では、一般的に、通信が1つのパソコン通信システム内にとどまっていたので、他のシステムとの間での電子メールの交換機能などの相互通信機能はほとんどなかった。また、各パソコン通信システムごとに独自のシステムが構築されていた事が多かったので、ユーザインターフェイス等についても互換がなかった。しかしその後、インターネットの普及に伴って、大手パソコン通信システムとインターネット間で相互に通信が可能にもなった。メール友達(メル友)も、流行になった時期があった。

なお、以下では「広義のメール」と記載が無い物はRFCに準拠した、UUCP、SMTPのプロトコルを使用した電子メールについてのみ記述する。それ以外の電子メールについては上記の各関連項目を参照のこと。

狭義のメール

  • RFCに準拠した、UUCP、SMTPのプロトコルを使用した電子メール。

広義のメール

電子メールを支える技術

一般

個々の電子メールのアドレスは、「Yamada.Tarou@example.wikipedia.org」などのような形で表現される。実際に電子メールを使うためには独自ドメイン名(この例では「example.wikipedia.org」)を得て、ドメイン名を管理するDNSサーバメールサーバに登録する必要があることがほとんどである。

一般的には、加入インターネットプロバイダや勤務先・通学先の企業・学校などのアドレス(アカウント)になっていることが多い。

容量については理論的には制限はないが、送受信可能な最大容量は、プロバイダの提供する容量で制約を受ける。一般的には、ダイヤルアップ接続時代の名残の数メガバイト(MB)から、近年のブロードバンド対応として大容量を謳ったものでは100MB~数GB(ギガバイト)程度に設定されることが多い。主要プロバイダの一例としてはOCNが10MBまで[2]So-netが20MBまで[3]Biglobeが100MBまでである[4]。これ以上の大容量のデータのやり取りにはFTPP2PHTTP等によるオンラインストレージファイル転送サービスアップローダーなどを使用する。

無料アドレス(フリーメールサービス)の場合は、プロバイダなどのアカウントで利用する一般的な電子メールクライアントソフトではなく、ウェブブラウザを使ってウェブページ上で、送受信を行うウェブメールがほとんどである。

プロトコル

現在、インターネットでは、メールサーバ間での通信およびクライアントからの送信には、一般にSMTPが使われる。古くは、また現在でも希に、UUCPが使われる。メールは、数々のサーバリレーのように経由して目的のメールサーバに伝えられる。なお、電子メールには、送信者の使用メールソフトや経由サーバーなどのヘッダーと呼ばれる情報が付属されている。

メールサーバからメールを読み出す場合には、POPIMAPなどのプロトコルが用いられる。メールの書式については、RFC 5322で規定がある。また、英字以外の文字・言語テキスト以外の情報をメールで送るなどのためにMIMEが規定されている。

文字コード

元来のメールの文字コードUS-ASCIIのみであったが、上記MIMEの規定により様々な文字コードが使えるようになった。

かつての日本のJUNETではJIS規格に基づく規則を決めて日本語を扱えるようにした[5]。この規則をMIMEの枠組みで再定義したものがISO-2022-JPである。現在の日本語メールでは、このISO-2022-JPが広く用いられている。

RFC 2277では、出来るだけ広く知られた文字コードを選ぶように注意を促している。これはUTF-8が普及するまでの暫定的なものであるが、その期間は50年であるかもしれないので事実上は永遠と考えてよいとも書かれている[6]

メール形式

元来は、メールは文章程度のプレーンテキスト形式の物のみであったが、上記MIMEの規定および普及に伴って、メール本文をHTMLにより記述したHTML形式のメールも、RFCに規定されて一般にも使われるようになった。

HTML形式のメールは、メール本文がHTMLで記述できるのでメールにWebページと同様の表現力を持たせられる利点がある。携帯電話PHSでも、cHTML形式のメールが一般向け仕様のサービスとして提供されているものもある。

その一方で、特に、Microsoft Windows と、その標準メールクライアントである Outlook Express(初期設定ではメールの作成時にHTML形式が選ばれる)の普及に伴って、HTML形式のメールが送受信されることも多くなった。しかしながらメールクライアントにおいては、メール中のHTML情報を展開し表示するためのレンダリングエンジンInternet Explorerをはじめとするウェブブラウザ)にしばしばセキュリティホールが発見されているので、メールを見る(プレビューする)だけで、コンピュータウイルスが侵入する被害を受けたり、迷惑メール架空請求メール等で画像タグを埋め込んだメールを送りつけて表示させて、メールを表示させた情報を収集(ウェブビーコンと言う)して悪用するなど、セキュリティ上の問題がある(ただし「HTMLメールを表示する事」は「ブラウザでWebページを表示する事」と、技術的には根本的な違いはない)。対策としては、ウイルス対策迷惑メール対策ソフトを導入するか、HTML形式のメールをフィルタリング機能で受信を拒否する・ゴミ箱フォルダへ振り分けるなどがある。また、HTMLメールの表示に対応していないメールクライアントもあって、断り無くHTML形式のメールを送信しても正しく受信されないおそれがある。

なお、あるファイルデータをメールに添付して送る場合、添付ファイルとしてMIMEなどによってテキスト化(エンコード)をしてメール本文に埋め込んで送信して、受信側で元のデータファイルに復元(デコード)する方法が取られる。添付ファイルには、コンピュータウイルスも仕込み可能なので、受信時に添付ファイルを自動的に開く設定になっていると、やはりコンピュータウイルスが侵入する被害を受けるなどの危険もある。

ヘッダー情報

一通一通それぞれのメールは、本文とは別に、ヘッダーフィールドと呼ばれる各種の特殊な情報が記載された領域を持つ。ほとんどのメールクライアントでは、何らかの方法(メールクライアント毎に異なる)によって、このヘッダーフィールドの情報を参照可能である。この情報は、脅迫メールやスパムなどのメールが届く場合などに、送信元の特定などに威力を発揮する。ただし、偽装も可能で必ずしもすべてのヘッダフィールドを付加する必要はないので、完全には判断できない。

代表的なヘッダフィールド

ヘッダーフィールドは フィールド名:フィールド値 という形で記載される。

Cc
Bcc
Ccは写し受信者[7](32.08.04)、Bccは秘密受信者[7](32.08.05)の受取人のメールアドレス。単数や複数の名前やアドレスも含められる。#CcとBccを参照。
Date
送信者が送信を行った日時
From
著者のメールアドレス[8]。単数または複数の名前やアドレスも含められる。
このヘッダーの記載は送信者がメールクライアントの設定によって自由に変更できる。このようなメールの仕様から、いわゆる「なりすまし」などの悪用を完全に防ぐことは困難とされる。
In-Reply-To
返信元メールなどのMessage-IDの値の一覧
Message-ID
メール一通一通に付加された固有の番号
MIME-Version
MIMEのバージョン
Received
このメールが届くまでに経由したメール転送エージェントIPアドレス)および経由した日時
Reply-To
送信者が返信先として希望するメールアドレス
Return-Path
SMTP通信で送信元として伝えられるメールアドレス
Sender
送信者のメールアドレス[9]。名前も含められる。著者と送信者が同一、すなわちFromが単一のアドレスでSenderと同じ場合は使うべきではない。逆に、異なる場合は必須である。
Subject 主題[7](32.03.03)
話題を表す短い文。返信の場合はRe:、転送の場合はFw:が先頭に自動的に付加される場合が多い(#ReとFwを参照)。
To
受取人のメールアドレス。単数または複数の名前やアドレスも含められる。
X-FROM-DOMAIN
送信者のドメイン
X-IP
送信者のグローバルIPアドレス
X-Mailer
メールクライアントの種別
X-Priority
送信者が指定した重要度

保存形式

  • 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機能を理解していてもあえて使わない利用者も居る

Cc
Toで指定した本来の送信先以外にも、一応複製を送っておきたい相手などがいる場合に使用する機能である。
Toで宛先を指定するのと同様に、Ccに複製を送りたい相手を指定して使用する。Toに指定された本来の相手には、ToCcに指定された宛先が全て見える。また、Ccに指定された相手にも、ToCcに指定された宛先が全て見える。
要するに、送信者 (From)、Toの相手、Ccの相手、の各3人相互で、各アドレスが各3人全員に知られることになる。
Bcc
Toで指定した本来の送信先以外にも一応複製を送っておきたい相手がいるが、ToCcに指定した相手には、複製を送信した相手のメールアドレス及び複製を送信した事実を知られたくない場合などに使用する機能である。
Toで宛先を指定するのと同様に、Bccに複製を送りたい相手を指定して使用する。メール転送時にBccヘッダーはメール文面(SMTP DATA)から削除されるので、ToCcに指定された相手には、このBccに指定された宛先は全く見えない。しかし、Bccに指定された相手には、ToCcに指定された宛先が全て見える。これが意味するところは、Bccで受信した人がうっかりと Reply-all で返信してしまった場合、BccしていたことがToCcの受信者に知られてしまうということである。Bccの実装によっては、ToCcにて送付したメールを転送する形式にすることで、こういったうっかりがあっても、Fromの人物にしかメールが届かないようになっているものもある。どのような副作用があるのかBccを使用する場合には、よくよく注意を要する。また、Bccの宛先アドレスが複数ある場合には、Bcc指定された各宛先相互間で、自分以外の他の宛先は分からない。
複数のメールクライアントから単一のメールアカウント・サーバーに接続する場合には、Bccを活用した技がある。BccFrom(自分自身)と同じアドレスを指定する(メールクライアント (MUA) による常時設定も可能)事によって、自分が送信したメールがそのままの内容で自分のメールクライアントの受信箱にも配信される。POP3等のメールサーバーでサーバーかメールクライアントへ受信したメールをサーバーから除去しない(数日後に削除する)設定をメールクライアントにすることによって、1つのメールクライアントから送信したメールが他のメールクライアント全てに複製として配信される。これによって、通常は送信したメールクライアントの送信済み箱を見ないと分からない所が、複数のメールクライアントで送信メールが確認できる。
ネチケットの一つとして推奨されてきたメールの送信方法であるが、一斉メールはどのような場合でもBccを使用するべきかといえばそうでもない。例えば特定の一斉送信されたメールについて、全ての受信者がメールアドレスを交換し合っている場合にはBccを使う必要性はなく、どちらかというと宛先と目的がはっきりと明示されているToとCcを使いわけるのが普通である。時と場合によりTo、Cc、Bccを適切に使い分けるためには高度なネチケット知識が必要である。
なお、時々「ブラックカーボンコピー[12]」と言われることがあるが、これは間違いである。

ReとFw

Re(返信)
多くの電子メールクライアントでは、返信されたメールの件名の先頭に自動的にRe:またはRE:という記号を付加する。この略号は、受け取ったメールの表題「○○」に対し返事の表題「○○に関して」(Regarding~)を自動的に付ける便宜上のものであり、返信であることを示すマークではないから、送信者が意図的に削除しても構わない。古くから商用文で使われていた慣習が、電子メール発祥期のメールコマンドに採用され、さらにはRFCに記載されたことで定着したが、他にも諸説ある。
Fw、Fwd[13](転送)
一部の電子メールクライアントでは、メールを転送する際に、件名の先頭に自動的に Fw: などの記号を付加することがある。この略号は Re と同様単なる便宜的なものであるだけでなく、RFCにすら記述の無い独自仕様である。例えば、Fw: が連続していれば何度も転送されたメールだと考えることもできるが、それはあくまで、一部の電子メールクライアントの仕様に過ぎず、一般的な理解ではない。Fw: の連続はチェーンメールに多いため、チェーンメールかどうかの目安にもなる。そのため、転送時に Fw: を削除するように指示する内容が記述されたチェーンメールもある。

歴史

先駆的活動

テキスト形式のメッセージを電気的に伝える方法は1800年代中頃のモールス信号による電報に遡る事が出来る。1939年のニューヨーク万国博覧会では、IBMが将来郵便に替わる高速の自社用電波を用いた通信で、祝福の文書をサンフランシスコからニューヨークに送った[14]第二次世界大戦中、ドイツが使用したテレタイプ端末[15]、その後テレックスが世界的に普及する1960年代末まで使われた。アメリカには同様なTWXがあり、1980年代末まで重要な通信方法の位置を占めた[16]

歴史的に「electronic mailエレクトロニック・メール」という用語は一般的に電子化された送信文書全般を指して用いられた。例えば、1970年代前半にはファクシミリによる文書送信を指す用語として用いられる例もあった[17][18]

電子メールの起源

電子メールはインターネットに先行して開発された。既存の電子メールシステムはインターネットを作るに当たって重要な道具となった。

最初の電子メールは1965年メインフレーム上のタイムシェアリングシステムの複数の利用者が相互に通信する方法として使われ始めた。1970年代初頭までに、アメリカ国防総省自動デジタル・ネットワーク (AUTODIN) は1350台の端末間を繋ぎ、1件あたり平均3000文字のメッセージを月間3000万件取り扱えるようになった。AUTODINは18台の計算機化された大きな切替装置が運用を支え、さらに約2500台の端末を繋げるアメリカ共通役務庁のアドバンスト・レコード・システムとも接続された[19]。正確なところは不明だがその類の機能を持つ最初のシステムとして、SDC(ランド研究所からのスピンオフでSAGEのソフトウェア開発を行った会社)のQ32システムがある。マサチューセッツ工科大学は1961年にCTSSを導入し[20]、複数の利用者が離れた端末から電話回線を使って中央システムにログインし、ディスクにファイルを保存し共有できる体制を整えた[21]。 電子メールは間もなく利用者が異なるコンピュータ間で情報をやり取りするための「ネットワーク電子メール」に拡張された。1966年には異なるコンピュータ間で電子メールを転送していた(SAGEでの詳細は明らかではないが、もっと早い時期に実現していたかもしれない)。

ARPANETは電子メールの発展に多大な影響を与えた。その誕生直後の1969年にシステム間電子メール転送の実験を行ったという報告がある[34]BBN社レイ・トムリンソン1971年にARPANET上の電子メールシステムを開発し、初めて@を使って利用者名と機器とを指定できるようにした[35]。ARPANET上では電子メール利用者が急激に増大し、1975年には1000人以上が利用するようになっていた。

その他にも、1978年までにUNIXメールがネットワーク化されUUCPとなり[36]、1981年にはIBMのメインフレームの電子メールがBITNETで接続された[37]

一般への浸透

ARPANETでの電子メールの利便性と利点が一般に知られるようになると、電子メールの人気が高まり、ARPANETへの接続ができない人々からもそれを要求する声が出てきた。タイムシェアリングシステムを代替ネットワークで接続した電子メールシステムがいくつも開発された。例えばUUCPIBMのVNETなどがある。

全てのコンピュータコンピュータネットワークが直接相互に接続されるわけではないので、電子メールのアドレスには情報の伝達「経路」、つまり送信側コンピュータから受信側コンピュータまでのパスを示す必要があった。電子メールはこの経路指定方法でいくつものネットワーク間(ARPANETBITNETNSFNET)でやり取りすることができた。UUCPで接続されたホストとも電子メールをやり取りすることが可能であった。

経路は「バングパス」と呼ばれる方法で指定された。あるホストから直接到達可能なホストのアドレスを書き、そこから次に到達可能なホストのアドレスをバング(感嘆符!)で接続して書いていくアドレス指定方式である[38]

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など)。

日本では1984年からJUNETが大学間の接続を始めており、その後企業の研究機関も含めて接続が広がった。当初はASCII文字のみの想定であったが、後に JUNET において、電子メールなどで日本語(漢字)使用を可能とする文字符号化方式ISO-2022-JPが開発されている[5](電子メール#文字コード)。

1980年代後半時点におけるUNIX上でのメール作成時の日本語入力システム(FEPとも呼ばれた)としては、UNIX環境にてWnnを使用する方法があった(日本語入力システムとしては、後にCannaも出開発された)。それとは別に、MS-DOS にてシリアルポート経由での通信を目的としたKEK-Kermit等を起動してパソコンをUNIX端末としておき[39]、日本語入力システムとしてATOKあるいは松茸を利用して、パソコン側で漢字コードまでを生成し、KEK-Kermit等でパソコンローカル側の漢字コードである Shift JIS をUNIX側で指定された漢字コードであるEUC又はJIS等に変換しつつ、UNIX側に送り込むことでUNIX上でのメール作成時の漢字入力手段とする方法もあった。逆に、UNIX側で受け取った漢字入り電子メールをUNIX端末としているパソコン側で表示する際、パソコン側で受診した漢字コードは KEK-Kermit等によって再びShift JISに変換されてから表示されていた。

これに続く時代にて大学や企業にてパソコンが直接 Ethernet 接続されるようになり、また、一般家庭にもダイヤルアップ接続が拡大する中、様々な種類の電子メールクライアントが出現する。

問題

トラフィックの増大と配送遅延

電子メールのトラフィックの多くは実はスパムメールである。バラクーダネットワークスの報告[40]によると、2007年中に送信されたメールのうち90%から95%がスパムメールであったという。大量に送信されるこれらのスパムメールはメールサーバに過大な負荷を与え、メール配送遅延の原因となることもある。たとえば2004年7月下旬から8月上旬にかけて、大手インターネットプロバイダ@niftyで、海外から大量に送信されたスパムメールによりメールサーバに断続的な負担が掛かり、メールの受信に支障が生じる状態が続いた[41]。(2010年10月ロシアで摘発されたスパムメール業者は1日500億通を発信していたという。)

また近年、トロイの木馬などのマルウェアに感染したコンピュータ群によって引き起こされるDDoS型のスパム送信の割合が急激に増加しており、ますますメールサーバに多大な負荷を及ぼすものとされている(→ボットネットを参照)。

スパム以外のトラフィック増大要因として、いわゆる「年賀メール」(元旦前後に発生する大量の挨拶メール)の類もある。特に携帯電話等のメール機能は「即時の意思疏通を図る手段」としてチャット的に利用される場合があるため、一般の電子メールに比べ大量かつ集中的に送信されやすく、これを原因とした配送遅延や輻輳が問題になる場合もある。この対策として、各通信事業者が年越時間帯の利用自粛を呼び掛けたり発信制限を行ったりすることもある。かつてパソコン通信が全盛だった時代には、処理の集中を防ぐため、あらかじめ年賀メールをサーバに予約送信しておき元旦に順次配送するといったサービスも提供されていた。

なお、電子メールの配送システムの多くは、メールサーバに一定以上の負荷が掛かると送信を保留し一旦スプールに保存し後に(例えば数時間後に)再送信を試みる仕組みになっているため、トラフィックが一定量を超えると配送の極端な遅延が起こる。この遅延はメール1通毎に起こるため、同時期に送ったメールであっても、あるものは数秒で届きあるものは数時間で届くということになり、これを理解していない利用者の間ではメールを「送った」「送らない」で揉める恐れもある。

一時的なトラフィックの増大でスプールに保存された保留メールは、多くの場合時間の経過と共に処理され正常に戻るが、メールサーバの能力が十分でないと再送処理自体が間に合わなくなり、送信者に失敗通知が返送されることもある。なお、失敗通知すら返送されず「消滅」することは原理的にありえない。メールサーバは能力が追い付かない場合メールの受信(SMTPコネクション)自体を拒否するからである。よく年賀メール等で「トラフィック増大が原因であるプロバイダのメールの紛失が起きた」と、あたかも不可抗力であるが如き報道を目にするが、正確にはそのプロバイダのメールサーバの管理が適切でなく、混雑時の処理が正しく動作していないシステム不良である。

同時多発テロ時には、ニューヨーク周辺間のメールが1日遅延するなどした他、2009年には南アフリカケープタウンヨハネスブルグ間700kmで実験が行われ、電子メールより伝書鳩の方が早く情報を伝達できた。

スパムメール対策の問題点

スパムメール対策としてサーバ上、クライアント上でのフィルタリングが普及してきたが、誤検知により通常のメールがスパムであると判断されてしまい、不着となる問題が増えている(→電子メールフィルタリングを参照)。

コミュニケーション上の問題

方言などが原因で口頭での意思疏通が叶わない人同士でも、文字による意思疏通を図れるため、人の交流が広域化した現代ではメールによる意思疏通は有用である(日本、中国イギリスなど方言が多様な国では特に)。一方、パソコン通信インターネット等における文字だけの遣り取りに見られる問題(炎上Flaming)は電子メールにおいても見られる。メールの真意、感情が相手に伝わらず、度々揉め事に発展するケースが挙げられている。英語圏では、メールの真意を読み取り間違え、感情に任せて送るメールの呼称(スラング)にFlame Mailというものがある。

安全性の問題

電子メールにおけるテキストベースな平文は、サーバーネットワーク上でスニッフィング(傍受)される可能性が高くセキュリティーの観点から好ましいとは言えない。フィル・ジマーマンが開発し、公開した暗号ソフトウェア(Pretty Good Privacy:PGP)のプラグインなどを導入することで安全性を高められる。

脚注

  1. RFC 5321 - Simple Mail Transfer Protocol”. Network Working Group (2008年10月). 2010年2月閲覧。
  2. OCN設定サポート…OCNのメール送信容量は通常10MBまで送信可能です
  3. So-net会員サポート…基本メールボックスの容量と保管期間
  4. BIGLOBEメールの仕様
  5. JUNET利用の手引(第1版)
  6. Using International Characters in Internet Mail
  7. JISX0032 1999.
  8. ここでいう「メールアドレス」は、技術的にはメールボックス・リスト (mailbox-list) という。BCC、CC、Reply-To、Toも同様。
  9. ここでいう「メールアドレス」は、技術的にはメールボックス (mailbox) という。
  10. : carbon copy
  11. : blind carbon copy
  12. : black carbon copy
  13. : forward
  14. The Watsons: IBM's Troubled Legacy
  15. See File:Gestapo anti-gay telex.jpg
  16. Telex and TWX History、ドナルド・E・キンバーリン、1986年
  17. Ron Brown, Fax invades the mail market, New Scientist, Vol. 56, No. 817 (Oct., 26, 1972), pages 218-221.
  18. Herbert P. Luckett, What's News: Electronic-mail delivery gets started, Popular Science, Vol. 202, No. 3 (March 1973); page 85
  19. USPS Support Panel, Louis T Rader, Chair, Chapter IV: Systems, Electronic Message Systems for the U.S. Postal Service, National Academy of Sciences, Washington, D.C., 1976; pages 27-35.
  20. "CTSS, Compatible Time-Sharing System" (September 4, 2006), サウスアラバマ大学, USA-CTSS.
  21. Tom Van Vleck, "The IBM 7094 and CTSS" (September 10, 2004), Multicians.org (Multics), web: Multicians-7094.
  22. IBM (pdf). 1440/1460 Administrative Terminal System (1440-CX-07X and 1460-CX-08X) Application Description. Second Edition. IBM.. H20-0129-1. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/144x/H20-0185-1_1440_ATS_termOpe.pdf 2013年2月22日閲覧。
  23. IBM. System/36O Administrative Terminal System DOS (ATS/DOS) Program Description Manual. IBM.. H20-0508
  24. IBM. System/360 Administrative Terminal System-OS (ATS/OS) Application Description Manual. IBM.. H20-0297
  25. Version 3 Unix mail(1) manual page from 10/25/1972
  26. Version 6 Unix mail(1) manual page from 2/21/1975
  27. APL Quotations and Anecdotes, including Leslie Goldsmith's story of the Mailbox
  28. History of the Internet, including Carter/Mondale use of email
  29. David Wooley, PLATO: The Emergence of an Online Community, 1994.
  30. Stromberg, Joseph (2012年2月22日). A Piece of Email History Comes to the American History Museum”. スミソニアン博物館. 2012年6月11日閲覧。
  31. "...PROFS changed the way organizations communicated, collaborated and approached work when it was introduced by IBM’s Data Processing Division in 1981...", IBM.com
  32. "1982 - The National Security Council (NSC) staff at the White House acquires a prototype electronic mail system, from IBM, called the Professional Office System (PROFs)....", fas.org
  33. Gordon Bell's timeline of Digital Equipment Corporation
  34. Tom Van Vleck (2001年2月1日). The History of Electronic Mail”. 2008年2月21日閲覧。
  35. Ray Tomlinson. The First Network Email”. 2008年2月21日閲覧。
  36. Version 7 Unix manual: "UUCP Implementation Description" by D. A. Nowitz, and "A Dial-Up Network of UNIX Systems" by D. A. Nowitz and M. E. Lesk
  37. "BITNET History", livinginternet.com
  38. rfc976 https://tools.ietf.org/html/rfc976 UUCP Mail Interchange Format Standard 5節“Summary”に、( ! でホスト名をつないでメールアドレスを表現する) bang path の説明がある。bang path の例としては hosta!hostb!user などがある。
  39. 木村広, 田井村明博「電子メ-ル・電子ニュ-スの使い方」『長崎大学教養部紀要 自然科学篇』第33巻第1号、長崎大学教養部、1992年7月、 65-109頁、 ISSN 02871319 NAID 120000916619、の「5.1モデム(デジタル電話)とパソコン間のセットアップ」など]
  40. 勝村幸博 (2007年12月14日). 「メールの95%は『迷惑メール』だった」、2007年のスパム動向”. ITpro. 日経BP社. 2008年2月21日閲覧。
  41. 会員サポート > 大量スパムメールによるメール遅延、ならびに対策について”. @nifty. ニフティ (2004年8月13日). 2008年2月21日閲覧。

参考文献

関連項目

外部リンク

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.