コンテンツにスキップ

電子メール

リンクを編集
出典: フリー百科事典『ウィキペディア（Wikipedia）』
ウィキペディア ウィキペディアから利用できるEメール（ウィキメール）については、Help:ウィキメールをご覧ください。
曖昧さ回避 「メール」はこの項目へ転送されています。日本の郵便サービスの「電子郵便」については「レタックス」を、その他の用法については「メール (曖昧さ回避)」をご覧ください。
「@」（単価記号、アットマーク）はすべてのSMTP メールアドレスで使われる[1]
インターネット
Visualization of Internet routing paths
Opte Project（英語版）による、インターネットの一部を通したルーティングパスの視覚化
主要項目
ガバナンス
情報基盤（英語版）
サービス

電子メール（でんしメール）あるいは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は写し受信者[9](32.08.04)、Bccは秘密受信者[9](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 主題[9](32.03.03)
話題を表す短い文。返信の場合はRe:、転送の場合はFw:が先頭に自動的に付加される場合が多い（#ReとFwを参照）。
To
受取人のメールアドレス。単数または複数の名前やアドレスも含められる。
X-FROM-DOMAIN
送信者のドメイン
X-IP
送信者のグローバルIPアドレス
X-Mailer
メールクライアントの種別
X-Priority
送信者が指定した重要度

保存形式

[編集]

機能

[編集]

CcとBcc

[編集]

メールを送信する際の機能として、Cc（写し受信者[9](32.08.04)[注釈 3]）とBcc（秘密受信者[9](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に記載されたことで定着したが、他にも諸説ある。
→詳細は「Re:」を参照
Fw、Fwd[注釈 6]（転送）
一部の電子メールクライアントでは、メールを転送する際に、件名の先頭に自動的に Fw: などの記号を付加することがある。この略号は Re と同様単なる便宜的なものであるだけでなく、RFCにすら記述の無い独自仕様である。例えば、Fw: が連続していれば何度も転送されたメールだと考えることもできるが、それはあくまで、一部の電子メールクライアントの仕様に過ぎず、一般的な理解ではない。Fw: の連続はチェーンメールに多いため、チェーンメールかどうかの目安にもなる。そのため、転送時に Fw: を削除するように指示する内容が記述されたチェーンメールもある。

歴史

[編集]

先駆的活動

[編集]

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

歴史的に「（エレクトロニック・メール）」という用語は一般的に電子化された送信文書全般を指して用いられた。例えば、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）のプラグインなどを導入することで安全性を高められる。

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ ここでいう「メールアドレス」は、技術的にはメールボックス・リスト (mailbox-list) という。BCC、CC、Reply-To、Toも同様。
  2. ^ ここでいう「メールアドレス」は、技術的にはメールボックス (mailbox) という。
  3. ^ 英: carbon copy
  4. ^ 英: blind carbon copy
  5. ^ 英: black carbon copy
  6. ^ 英: forward

出典

[編集]
  1. ^ “RFC 5321 - Simple Mail Transfer Protocol”. Network Working Group (October 2008). 2010年2月閲覧。
  2. ^ OCN公式ページ
  3. ^ 会員サポート…基本メールボックスの容量と保管期間
  4. ^ BIGLOBEメールの仕様
  5. ^ 「最大 50 MB のメールを受信できます。[1]」
  6. ^ 「注: 25 MB を超える添付ファイルを送信するには、Google ドライブや他のファイル共有サービスを使用してください。[2]」
  7. ^ a b JUNET利用の手引(第1版)
  8. ^ Using International Characters in Internet Mail[リンク切れ]
  9. ^ a b c d e JISX0032 1999.
  10. ^ The Watsons: IBM's Troubled Legacy
  11. ^ See File:Gestapo anti-gay telex.jpg
  12. ^ Telex and TWX History、ドナルド・E・キンバーリン、1986年
  13. ^ Ron Brown, Fax invades the mail market, New Scientist, Vol. 56, No. 817 (Oct., 26, 1972), pages 218-221.
  14. ^ Herbert P. Luckett, What's News: Electronic-mail delivery gets started, Popular Science, Vol. 202, No. 3 (March 1973); page 85
  15. ^ 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.
  16. ^ "CTSS, Compatible Time-Sharing System" (September 4, 2006), サウスアラバマ大学（英語版）, USA-CTSS.
  17. ^ Tom Van Vleck, "The IBM 7094 and CTSS" (September 10, 2004), Multicians.org (Multics), web: Multicians-7094.
  18. ^ 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日閲覧。 
  19. ^ IBM. System/36O Administrative Terminal System DOS (ATS/DOS) Program Description Manual. IBM. H20-0508 
  20. ^ IBM. System/360 Administrative Terminal System-OS (ATS/OS) Application Description Manual. IBM. H20-0297 
  21. ^ Version 3 Unix mail(1) manual page from 10/25/1972
  22. ^ Version 6 Unix mail(1) manual page from 2/21/1975
  23. ^ APL Quotations and Anecdotes, including Leslie Goldsmith's story of the Mailbox
  24. ^ History of the Internet, including Carter/Mondale use of email
  25. ^ David Wooley, PLATO: The Emergence of an Online Community, 1994.
  26. ^ Stromberg, Joseph (22 February 2012). “A Piece of Email History Comes to the American History Museum”. スミソニアン博物館. 11 June 2012閲覧。
  27. ^ "...PROFS changed the way organizations communicated, collaborated and approached work when it was introduced by IBM’s Data Processing Division in 1981...", IBM.com
  28. ^ "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
  29. ^ Gordon Bell's timeline of Digital Equipment Corporation
  30. ^ Tom Van Vleck (2001年2月1日). “The History of Electronic Mail”. 2008年2月21日閲覧。
  31. ^ Ray Tomlinson. “The First Network Email”. 2008年2月21日閲覧。
  32. ^ 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
  33. ^ "BITNET History", livinginternet.com
  34. ^ rfc976 https://datatracker.ietf.org/doc/html/rfc976 UUCP Mail Interchange Format Standard 5節“Summary”に、( ! でホスト名をつないでメールアドレスを表現する) bang path の説明がある。bang path の例としては hosta!hostb!user などがある。
  35. ^ 木村広, 田井村明博「電子メール・電子ニュースの使い方」『長崎大学教養部紀要 自然科学篇』第33巻第1号、長崎大学教養部、1992年7月、65-109頁、ISSN 02871319、NAID 120000916619。 、の「5.1モデム(デジタル電話)とパソコン間のセットアップ」など]
  36. ^ 勝村幸博 (2007年12月14日). “「メールの95%は『迷惑メール』だった」、2007年のスパム動向”. ITpro. 日経BP社. 2008年2月21日閲覧。
  37. ^ “会員サポート > 大量スパムメールによるメール遅延、ならびに対策について”. @nifty. ニフティ (2004年8月13日). 2008年2月21日閲覧。[リンク切れ]

参考文献

[編集]

関連項目

[編集]

外部リンク

[編集]
「https://ja.wikipedia.org/w/index.php?title=電子メール&oldid=99314500」から取得
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy