「@」(単価記号 、アットマーク)はすべてのSMTP メールアドレス で使われる[ 1]
電子メール (でんしメール)あるいはEメール (英 : electronic mail 、email )は、コンピュータネットワーク を使用して、まるで郵便 による手紙 のように文章 (や添付したファイルや写真データなど)のやりとりをすること、およびその技術。
概要
インターネット の初期からある通信手段であり、UUCP やSMTP などのプロトコル を介して、メールを相手サーバ に届けられる。電気的な信号 で送受信を行うので、地球の裏側にいる相手に送る場合でも隣の部屋にいる相手に送る場合でも、かかる時間は一般的には数十秒から数分程度である。
一方で、インターネットの普及以前にコンピュータでの通信手段として広く行われていた、いわゆるパソコン通信 でも、加入者同士で文書のやり取りを行うシステムが「電子メール」として提供されていた。ただし、パソコン通信では、一般的に、通信が1つのパソコン通信システム内にとどまっていたので、他のシステムとの間での電子メールの交換機能などの相互通信機能はほとんどなかった。また、各パソコン通信システムごとに独自のシステムが構築されていた事が多かったので、ユーザインターフェイス 等についても互換 がなかった。しかしその後、インターネットの普及に伴って、大手パソコン通信システムとインターネット間で相互に通信が可能にもなった。メール友達(メル友 )も、流行になった時期があった。
電子郵便とも言った[要出典 ] 。
英語では1990年代や2000年代あたりでは「e-mail」とハイフンを入れて表記することが一般的だったが、2010年代や最近の英語ではemailとハイフンも省略することが増えている。
なお、以下では「広義のメール」と記載が無い物はRFC に準拠した、UUCP、SMTPのプロトコルを使用した電子メールについてのみ記述する。それ以外の電子メールについては上記の各関連項目を参照のこと。
狭義のメール
RFC に準拠した、UUCP、SMTPのプロトコルを使用した電子メール。
広義のメール
電子メールを支える技術
アドレスの表現法
個々の電子メールのアドレス は、「john_smith@examplecompany.com
」のような形で表現される。
実際に電子メールを使うためには独自ドメイン名 (上の例では「examplecompany.com
」)を得て、ドメイン名を管理するDNSサーバ やメールサーバ に(手動であれ、自動であれ)登録することで送受信できるようになる。かつては、加入インターネットプロバイダ や勤務先・通学先の企業・学校などのアドレス(アカウント )が多かったが、『Yahoo!メール』や『gmail 』が普及してからはむしろそれらのアドレスのほうが多数派になっている。
容量
一通の電子メールの容量について、理論的には制限はないが、メールサーバ設置者(多くはプロバイダだがそれ以外もある)が設定している容量(「送受信可能な最大容量」などと表現されている)の制約を受ける。プロバイダごとにまちまちである。小さい容量では、ダイヤルアップ接続 時代の名残の数メガバイト (MB)程度のものから、ブロードバンド が一般化してからは10~20MB程度が一般的で、一部のプロバイダでは100MB程度としている。数Gギガバイト(GB)程度に設定するプロバイダもある [要出典 ] 。
日本の主要プロバイダの例としては、たとえばOCN では10MBまで[ 2] 、So-net が20MBまで[ 3] 、Biglobe が100MBまでである[ 4] 。これ以上の大容量のデータのやり取りはできない。そのため、別の手段でデータを転送しメール本文ではその受け取り方法を記載する。メールクライアントによってはこの作業を自動的に行うものもある(gmailなど)。別の手段の具体的な例としてFTP やP2P 、HTTP 等によるオンラインストレージ 、ファイル転送サービス 、アップローダー 、宅配便などでメディアを送るなどが使用される。
gmailの受信メールは一通50MBまで[ 5] (送信のほうに関しては25MB超の添付ファイルはGoogleドライブ や他のファイル共有サービスを使用を求める)[ 6] 。
送受信に使うアプリケーション
電子メールの送受信を行う時に一般ユーザの側が使うアプリケーションソフト に関しては、1990年代などはもっぱらパソコンにインストールした電子メールクライアント ソフトで送受信を行った。
2000年代や2010年代あたりからウェブブラウザ でサーバにアクセスしてアカウントにログインしてウェブページ 上で送受信を行う方式(ウェブメール )も広まった。このウェブメール方式は、POP3、IMAP4、SMTPなどの細かい設定が不要であり、
社内の他部署や出先や旅先など自分のパソコンを持ち歩いていない状態でも、インターネットのウェブサイトにブラウザでアクセスできるパソコンがあれば自分の個人的なアドレスで電子メールの送受信ができる利点がある。またコンピュータウィルスが含まれているファイルが添付されているウィルスメールが送られてきた場合でもそれの影響を遮断しやすく、また悪意で意図的に大容量のメールを送って他者を困らせようとする者がいる場合でもそれの悪影響を遮断しやすい(メールのタイトルと容量だけ確認して、必要なメールだけ選んで中身を読んで、怪しいと思えるメールなどはメールの実体を自分のパソコンに受信せずに済ますこともできる)など、つまりコンピュータセキュリティ上のメリットや運用上のメリットもある。
無料アドレス(フリーメールサービス )の場合は、ウェブブラウザを使ってウェブページ上で、送受信を行うウェブメールがほとんどである。
プロトコル
現在、インターネットでは、メールサーバ 間での通信およびクライアント からの送信には、一般にSMTP が使われる。古くは、また現在でも希に、UUCP が使われる。メールは、数々のサーバ をリレー のように経由して目的のメールサーバに伝えられる。なお、電子メールには、送信者の使用メールソフトや経由サーバーなどのヘッダー と呼ばれる情報が付属されている。
メールサーバからメールを読み出す場合には、POP 、IMAP などのプロトコルが用いられる。メールの書式については、RFC 5322 で規定がある。また、英字以外の文字・言語 やテキスト 以外の情報をメールで送るなどのためにMIME が規定されている。
文字コード
元来のメールの文字コード はUS-ASCII のみであったが、上記MIME の規定により様々な文字コードが使えるようになった。
かつての日本のJUNET ではJIS規格 に基づく規則を決めて日本語 を扱えるようにした[ 7] 。この規則をMIME の枠組みで再定義したものがISO-2022-JP である。現在の日本語メールでは、このISO-2022-JPが広く用いられている。
RFC 2277では、出来るだけ広く知られた文字コードを選ぶように注意を促している。これはUTF-8 が普及するまでの暫定的なものであるが、その期間は50年であるかもしれないので事実上は永遠と考えてよいとも書かれている[ 8] 。
メール形式
元来は、メールは文章 程度のプレーンテキスト 形式 の物のみであったが、上記MIME の規定および普及に伴って、メール本文をHTML により記述したHTML形式のメール も、RFC に規定されて一般にも使われるようになった。Microsoft Windows の標準メールクライアントであったOutlook Express の初期設定ではメールの作成時にHTML形式が選ばれていたため、送受信の機会も多くなった。
HTML形式のメールは、メール本文がHTMLで記述できるのでメールにウェブページ と同様の表現力を持たせられる利点がある。携帯電話 ・PHS でも、cHTML 形式のメールが一般向け仕様のサービスとして提供されているものもある。
その一方で、ただし「HTMLメールを表示する事」は「ブラウザでWebページを表示する事」と技術的には根本的な違いはないため、メール中のHTML情報を展開し表示するためのレンダリングエンジン のセキュリティホール を突いて、メールを見る(プレビューする)だけでコンピュータウイルス が侵入する被害を受けたり、迷惑メール ・架空請求 メール等で画像タグ を埋め込んだメールを送りつけて表示させ、情報を収集(ウェブビーコン と言う)して悪用するなど、セキュリティ 上の問題が相次いだ。
対策としては、ウイルス対策 ・迷惑メール対策 のソフト を導入するか、HTML形式のメールをフィルタリング機能で受信を拒否する・ゴミ箱フォルダ へ振り分けるなどがある。また、HTMLメールの表示に対応していないメールクライアントもあって、断り無くHTML形式のメールを送信しても正しく受信されないおそれがある。
なお、あるファイルデータをメールに添付して送る場合、添付ファイルとしてMIMEなどによってテキスト化(エンコード )をしてメール本文に埋め込んで送信して、受信側で元のデータファイルに復元(デコード )する方法が取られる。添付ファイルには、コンピュータウイルスも仕込み可能なので、受信時に添付ファイルを自動的に開く設定になっていると、やはりコンピュータウイルスが侵入する被害を受けるなどの危険もある。
ヘッダー情報
一通一通それぞれのメールは、本文とは別に、ヘッダー フィールド と呼ばれる各種の特殊な情報が記載された領域を持つ。ほとんどのメールクライアントでは、何らかの方法(メールクライアント毎に異なる)によって、このヘッダーフィールドの情報を参照可能である。この情報は、脅迫 メールやスパム などのメールが届く場合などに、送信元の特定などに威力を発揮する。ただし、偽装 も可能で必ずしもすべてのヘッダフィールドを付加する必要はないので、完全には判断できない。
代表的なヘッダフィールド
ヘッダーフィールドは フィールド名 :
フィールド値 という形で記載される。
Cc
Bcc
Ccは写し受信者(32.08.04) 、Bccは秘密受信者(32.08.05) の受取人のメールアドレス。単数や複数の名前やアドレスも含められる。#CcとBcc を参照。
Date
送信者が送信を行った日時
From
著者のメールアドレス[ 注釈 1] 。単数または複数の名前やアドレスも含められる。
このヘッダーの記載は送信者がメールクライアントの設定によって自由に変更できる。このようなメールの仕様から、いわゆる「なりすまし」などの悪用を完全に防ぐことは困難とされる。
In-Reply-To
返信元メールなどのMessage-IDの値の一覧
Message-ID
メール一通一通に付加された固有の番号
MIME-Version
MIMEのバージョン
Received
このメールが届くまでに経由したメール転送エージェント (IPアドレス )および経由した日時
Reply-To
送信者が返信先として希望するメールアドレス
Return-Path
SMTP通信で送信元として伝えられるメールアドレス
Sender
送信者のメールアドレス[ 注釈 2] 。名前も含められる。著者と送信者が同一、すなわちFromが単一のアドレスでSenderと同じ場合は使うべきではない。逆に、異なる場合は必須である。
Subject
主題(32.03.03)
話題を表す短い文。返信の場合はRe: 、転送の場合はFw: が先頭に自動的に付加される場合が多い(#ReとFw を参照)。
To
受取人のメールアドレス。単数または複数の名前やアドレスも含められる。
X-FROM-DOMAIN
送信者のドメイン
X-IP
送信者のグローバルIPアドレス
X-Mailer
メールクライアントの種別
X-Priority
送信者が指定した重要度
保存形式
機能
CcとBcc
メールを送信する際の機能として、Cc
(写し受信者 (32.08.04) [ 注釈 3] )とBcc
(秘密受信者 (32.08.05) [ 注釈 4] )の2種類ある。メールの本来の送信先は一般的にTo:に指定して送信するが、本来の送信先以外にも一応複製を送っておきたい相手などがいるという場合にこの機能を使用する。
メールを初めて利用する人はもちろん、それなりに使い慣れている人にしても、この機能の本来の使用方法を理解していない事も多い [独自研究? ] 。この機能を使うに当たっては、よく理解して使えばとても便利であるが、私用・公用に限らず、Cc機能とBcc機能の違い・それぞれに指定されて送信された相手に見える自分以外の送信先をよく理解して使わないと、例としてメールアドレスの個人情報 漏洩など、色々な意味で問題を起こす事となる。
また、Bcc
として指定したメールアドレスを他の受信者に見せたり、ヘッダー内の別領域に書くなどの欠陥を持つメールソフトが存在するので、Bcc
機能を理解していてもあえて使わない利用者も居る [要出典 ] 。
Cc
To
で指定した本来の送信先以外にも、一応複製を送っておきたい相手などがいる場合に使用する機能である。技術的には「名目が違うだけのTo
」と言える。To
に指定された相手には、To
とCc
に指定された宛先が全て見える。また、Cc
に指定された相手にも、To
とCc
に指定された宛先が全て見える。
Bcc
To
やCc
に指定した相手には知られずに、複製を送信したい相手を指定する場合に使用する機能である。To
やCc
に指定された相手にはBcc
に誰が指定されたかの情報は伝わらない。多くの電子メールクライアントソフトでは、Bcc
で指定された相手にはTo
やCc
に誰が指定されたかが分かるように電子メールの送信処理をする。この場合、Bcc
で受信した者がうっかりそのメールの受信者全員宛に返信してしまうと、同じメールを受信していたことがTo
やCc
の受信者に知られてしまう。そこで一部の電子メールクライアントソフトでは、To
やCc
にて送付したメールを転送する形で処理にすることで、そのような事故を防いでいる。いずれの方式の電子メールクライアントソフトでも、Bcc
の宛先アドレスが複数ある場合には、Bcc
指定された各宛先相互間で、自分以外の他の宛先は分からない。
複数のメールクライアントから単一のメールアカウント・サーバーに接続する場合には、Bccを活用した技がある。Bcc
にFrom
(自分自身)と同じアドレスを指定する(メールクライアント (MUA) による常時設定も可能)事によって、自分が送信したメールがそのままの内容で自分のメールクライアントの受信箱にも配信される。POP3等のメールサーバーでサーバーかメールクライアントへ受信したメールをサーバーから除去しない(数日後に削除する)設定をメールクライアントにすることによって、1つのメールクライアントから送信したメールが他のメールクライアント全てに複製として配信される。これによって、通常は送信したメールクライアントの送信済み箱を見ないと分からない所が、複数のメールクライアントで送信メールが確認できる。
ネチケット の一つとして推奨されてきたメールの送信方法であるが、一斉メールはどのような場合でもBccを使用するべきかといえばそうでもない。例えば特定の一斉送信されたメールについて、全ての受信者がメールアドレスを交換し合っている場合にはBccを使う必要性はなく、どちらかというと宛先と目的がはっきりと明示されているToとCcを使いわけるのが普通である。時と場合によりTo、Cc、Bccを適切に使い分けるためには高度なネチケット知識が必要である。
Bcc の語源は「ブラックカーボンコピー[ 注釈 5] 」ではなく「ブラインドカーボンコピー」である。
ReとFw
Re(返信)
多くの電子メールクライアント では、返信されたメールの件名の先頭に自動的にRe:またはRE:という記号を付加する。この略号は、受け取ったメールの表題「○○」に対し返事の表題「○○に関して」(英 : Regarding~ )を自動的に付けることで人間の便宜を図るものであり、技術的な意味は何もないものであるので、送信者が意図的に削除しても構わない。古くから商用文で使われていた慣習が、電子メール発祥期のメールコマンドに採用され、さらにはRFC に記載されたことで定着したが、他にも諸説ある。
Fw、Fwd[ 注釈 6] (転送)
一部の電子メールクライアント では、メールを転送する際に、件名の先頭に自動的に Fw: などの記号を付加することがある。この略号は Re と同様単なる便宜的なものであるだけでなく、RFCにすら記述の無い独自仕様である。例えば、Fw: が連続していれば何度も転送されたメールだと考えることもできるが、それはあくまで、一部の電子メールクライアント の仕様に過ぎず、一般的な理解ではない。Fw: の連続はチェーンメール に多いため、チェーンメールかどうかの目安にもなる。そのため、転送時に Fw: を削除するように指示する内容が記述されたチェーンメールもある。
歴史
先駆的活動
テキスト形式のメッセージを電気的に伝える方法は1800年代中頃のモールス信号 による電報に遡る事が出来る。1939年のニューヨーク万国博覧会 では、IBM が将来郵便に替わる高速の自社用電波を用いた通信で、祝福の文書をサンフランシスコからニューヨークに送った[ 10] 。第二次世界大戦 中、ドイツが使用したテレタイプ端末 は[ 11] 、その後テレックス が世界的に普及する1960年代末まで使われた。アメリカには同様なTWXがあり、1980年代末まで重要な通信方法の位置を占めた[ 12] 。
歴史的に「electronic mail (エレクトロニック・メール)」という用語は一般的に電子化された送信文書全般を指して用いられた。例えば、1970年代前半にはファクシミリ による文書送信を指す用語として用いられる例もあった[ 13] [ 14] 。
電子メールの起源
電子メールはインターネットに先行して開発された。既存の電子メールシステムはインターネットを作るに当たって重要な道具となった。
最初の電子メールは1965年 、メインフレーム 上のタイムシェアリングシステム の複数の利用者が相互に通信する方法として使われ始めた。1970年代初頭までに、アメリカ国防総省 の自動デジタル・ネットワーク (英語版 ) (AUTODIN) は1350台の端末間を繋ぎ、1件あたり平均3000文字のメッセージを月間3000万件取り扱えるようになった。AUTODINは18台の計算機化された大きな切替装置が運用を支え、さらに約2500台の端末を繋げるアメリカ共通役務庁 (英語版 ) のアドバンスト・レコード・システムとも接続された[ 15] 。正確なところは不明だがその類の機能を持つ最初のシステムとして、SDC(ランド研究所 からのスピンオフでSAGE のソフトウェア開発を行った会社)のQ32システムがある。マサチューセッツ工科大学 は1961年にCTSS を導入し[ 16] 、複数の利用者が離れた端末から電話回線を使って中央システムにログインし、ディスクにファイルを保存し共有できる体制を整えた[ 17] 。
電子メールは間もなく利用者が異なるコンピュータ間で情報をやり取りするための「ネットワーク電子メール」に拡張された。1966年 には異なるコンピュータ間で電子メールを転送していた(SAGEでの詳細は明らかではないが、もっと早い時期に実現していたかもしれない)。
ARPANET は電子メールの発展に多大な影響を与えた。その誕生直後の1969年 にシステム間電子メール転送の実験を行ったという報告がある[ 30] 。BBN社 のレイ・トムリンソン は1971年 にARPANET上の電子メールシステムを開発し、初めて@ を使って利用者名と機器とを指定できるようにした[ 31] 。ARPANET上では電子メール利用者が急激に増大し、1975年 には1000人以上が利用するようになっていた。
その他にも、1978年までにUNIXメールがネットワーク化されUUCP となり[ 32] 、1981年にはIBMのメインフレーム の電子メールがBITNET で接続された[ 33] 。
一般への浸透
ARPANETでの電子メールの利便性と利点が一般に知られるようになると、電子メールの人気が高まり、ARPANETへの接続ができない人々からもそれを要求する声が出てきた。タイムシェアリングシステムを代替ネットワークで接続した電子メールシステムがいくつも開発された。例えばUUCP やIBM のVNETなどがある。
全てのコンピュータ やコンピュータネットワーク が直接相互に接続されるわけではないので、電子メールのアドレスには情報の伝達「経路」、つまり送信側コンピュータから受信側コンピュータまでのパスを示す必要があった。電子メールはこの経路指定方法でいくつものネットワーク間(ARPANET 、BITNET 、NSFNET )でやり取りすることができた。UUCPで接続されたホストとも電子メールをやり取りすることが可能であった。
経路は「バングパス」と呼ばれる方法で指定された。あるホストから直接到達可能なホストのアドレスを書き、そこから次に到達可能なホストのアドレスをバング(感嘆符 =! )で接続して書いていくアドレス指定方式である[ 34] 。
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 が開発されている[ 7] (電子メール#文字コード )。
1980年代後半時点におけるUNIX上でのメール作成時の日本語入力システム (FEP とも呼ばれた)としては、UNIX環境にてWnn を使用する方法があった(日本語入力システムとしては、後にCanna も出開発された)。それとは別に、MS-DOS にてシリアルポート 経由での通信を目的としたKEK-Kermit 等を起動してパソコンをUNIX端末としておき[ 35] 、日本語入力システムとしてATOK あるいは松茸 を利用して、パソコン側で漢字コードまでを生成し、KEK-Kermit等でパソコンローカル側の漢字コードである Shift JIS をUNIX側で指定された漢字コードであるEUC 又はJIS 等に変換しつつ、UNIX側に送り込むことでUNIX上でのメール作成時の漢字入力手段とする方法もあった。逆に、UNIX側で受け取った漢字入り電子メールをUNIX端末としているパソコン側で表示する際、パソコン側で受診した漢字コードは KEK-Kermit等によって再びShift JIS に変換されてから表示されていた。
これに続く時代にて大学や企業にてパソコンが直接 Ethernet 接続されるようになり、また、一般家庭にもダイヤルアップ接続が拡大する中、様々な種類の電子メールクライアント が出現する。
問題
トラフィックの増大と配送遅延
電子メールのトラフィックの多くは実はスパムメール である。バラクーダネットワークス の報告[ 36] によると、2007年 中に送信されたメールのうち90%から95%がスパムメールであったという。大量に送信されるこれらのスパムメールはメールサーバに過大な負荷を与え、メール配送遅延の原因となることもある。たとえば2004年 7月下旬から8月上旬にかけて、大手インターネットプロバイダ@nifty で、海外から大量に送信されたスパムメールによりメールサーバに断続的な負担が掛かり、メールの受信に支障が生じる状態が続いた[ 37] 。(2010年10月ロシア で摘発されたスパムメール業者は1日500億通を発信していたという。)
また近年[いつ? ] 、トロイの木馬 などのマルウェア に感染したコンピュータ群によって引き起こされるDDoS型のスパム送信の割合が急激に増加しており、ますますメールサーバに多大な負荷を及ぼすものとされている(→ボットネット を参照)。
スパム以外のトラフィック増大要因として、いわゆる「年賀メール」(元旦前後に発生する大量の挨拶メール)の類もある。特に携帯電話等のメール機能は「即時の意思疏通を図る手段」としてチャット的に利用される場合があるため、一般の電子メールに比べ大量かつ集中的に送信されやすく、これを原因とした配送遅延や輻輳 が問題になる場合もある。この対策として、各通信事業者が年越時間帯の利用自粛を呼び掛けたり発信制限を行ったりすることもある。かつてパソコン通信が全盛だった時代には、処理の集中を防ぐため、あらかじめ年賀メールをサーバに予約送信しておき元旦に順次配送するといったサービスも提供されていた。
なお、電子メールの配送システムの多くは、メールサーバに一定以上の負荷が掛かると送信を保留し一旦スプールに保存し後に(例えば数時間後に)再送信を試みる仕組みになっているため、トラフィックが一定量を超えると配送の極端な遅延が起こる。この遅延はメール1通毎に起こるため、同時期に送ったメールであっても、あるものは数秒で届きあるものは数時間で届くということになり、これを理解していない利用者の間ではメールを「送った」「送らない」で揉める恐れもある。
一時的なトラフィック の増大でスプール に保存された保留メールは、多くの場合時間の経過と共に処理され正常に戻るが、メールサーバの能力が十分でないと再送処理自体が間に合わなくなり、送信者に失敗通知が返送されることもある。なお、失敗通知すら返送されず「消滅」することは原理的にありえない。メールサーバは能力が追い付かない場合メールの受信(SMTP コネクション)自体を拒否するからである。よく年賀メール等で「トラフィック増大が原因であるプロバイダのメールの紛失が起きた」と、あたかも不可抗力であるが如き報道を目にするが、正確にはそのプロバイダのメールサーバの管理が適切でなく、混雑時の処理が正しく動作していないシステム不良である。 [要出典 ]
同時多発テロ 時には、ニューヨーク周辺間のメールが1日遅延するなどした他、2009年には南アフリカ でケープタウン とヨハネスブルグ 間700kmで実験が行われ、電子メールより伝書鳩の方が早く情報を伝達できた。
スパムメール対策の問題点
スパムメール対策としてサーバ上、クライアント 上でのフィルタリング が普及してきたが、誤検知により通常のメールがスパム であると判断されてしまい、不着となる問題が増えている(→電子メールフィルタリング を参照)。
コミュニケーション上の問題
文字だけのやりとりに見られる問題(炎上 、Flaming )は電子メールにおいても見られる。メールの真意、感情が相手に伝わらず、度々揉め事に発展するケースが挙げられている。英語圏では、メールの真意を読み取り間違え、感情に任せて送るメールの呼称(スラング )にFlame Mailというものがある。
安全性の問題
電子メールにおけるテキストベースな平文は、サーバー やネットワーク 上でスニッフィング(傍受)される可能性が高くセキュリティー の観点から好ましいとは言えない。フィル・ジマーマン が開発し、公開した暗号 ソフトウェア(Pretty Good Privacy :PGP)のプラグインなどを導入することで安全性を高められる。
脚注
注釈
^ ここでいう「メールアドレス」は、技術的にはメールボックス・リスト (mailbox-list) という。BCC、CC、Reply-To、Toも同様。
^ ここでいう「メールアドレス」は、技術的にはメールボックス (mailbox) という。
^ 英 : carbon copy
^ 英 : blind carbon copy
^ 英 : black carbon copy
^ 英 : forward
出典
^ “RFC 5321 - Simple Mail Transfer Protocol ”. Network Working Group (October 2008). 2010年2月 閲覧。
^ OCN公式ページ
^ 会員サポート…基本メールボックスの容量と保管期間
^ BIGLOBEメールの仕様
^ 「最大 50 MB のメールを受信できます。[1] 」
^ 「注: 25 MB を超える添付ファイルを送信するには、Google ドライブや他のファイル共有サービスを使用してください。[2] 」
^ a b JUNET 利用の手引(第1版)
^ Using International Characters in Internet Mail [リンク切れ ]
^ The Watsons: IBM's Troubled Legacy
^ See File:Gestapo anti-gay telex.jpg
^ Telex and TWX History 、ドナルド・E・キンバーリン、1986年
^ Ron Brown, Fax invades the mail market, New Scientist , Vol. 56, No. 817 (Oct., 26, 1972), pages 218-221.
^ Herbert P. Luckett, What's News: Electronic-mail delivery gets started, Popular Science , Vol. 202, No. 3 (March 1973); page 85
^ a b 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.
^ "CTSS, Compatible Time-Sharing System" (September 4, 2006), サウスアラバマ大学 (英語版 ) , USA-CTSS .
^ Tom Van Vleck , "The IBM 7094 and CTSS" (September 10, 2004), Multicians.org (Multics ), web: Multicians-7094 .
^ IBM (pdf). 1440/1460 Administrative Terminal System (1440-CX-07X and 1460-CX-08X) Application Description (Second Edition ed.). IBM. H20-0129-1. http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/144x/H20-0185-1_1440_ATS_termOpe.pdf 2013年2月22日 閲覧。
^ IBM. System/36O Administrative Terminal System DOS (ATS/DOS) Program Description Manual . IBM. H20-0508
^ IBM. System/360 Administrative Terminal System-OS (ATS/OS) Application Description Manual . IBM. H20-0297
^ Version 3 Unix mail(1) manual page from 10/25/1972
^ Version 6 Unix mail(1) manual page from 2/21/1975
^ APL Quotations and Anecdotes , including Leslie Goldsmith 's story of the Mailbox
^ History of the Internet, including Carter/Mondale use of email
^ David Wooley, PLATO: The Emergence of an Online Community , 1994.
^ Stromberg, Joseph (22 February 2012). “A Piece of Email History Comes to the American History Museum ”. スミソニアン博物館 . 11 June 2012 閲覧。
^ "...PROFS changed the way organizations communicated, collaborated and approached work when it was introduced by IBM’s Data Processing Division in 1981..." , IBM.com
^ "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
^ Gordon Bell's timeline of Digital Equipment Corporation
^ Tom Van Vleck (2001年2月1日). “The History of Electronic Mail ”. 2008年2月21日 閲覧。
^ Ray Tomlinson . “The First Network Email ”. 2008年2月21日 閲覧。
^ 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
^ "BITNET History" , livinginternet.com
^ rfc976 https://datatracker.ietf.org/doc/html/rfc976 UUCP Mail Interchange Format Standard 5節“Summary”に、( ! でホスト名をつないでメールアドレスを表現する) bang path の説明がある。bang path の例としては hosta!hostb!user などがある。
^ 木村広, 田井村明博「電子メール・電子ニュースの使い方 」『長崎大学教養部紀要 自然科学篇』第33巻第1号、長崎大学教養部、1992年7月、65-109頁、ISSN 02871319 、NAID 120000916619 。 、の「5.1モデム(デジタル電話)とパソコン間のセットアップ」など]
^ 勝村幸博 (2007年12月14日). “「メールの95%は『迷惑メール』だった」、2007年のスパム動向 ”. ITpro . 日経BP社 . 2008年2月21日 閲覧。
^ “会員サポート > 大量スパムメールによるメール遅延、ならびに対策について ”. @nifty . ニフティ (2004年8月13日). 2008年2月21日 閲覧。 [リンク切れ ]
参考文献
関連項目
外部リンク