|
▼ 電子メール の解説を表示▼
電子メール（でんしメール、electronic mail 略してe-mail、Eメール、メールとも）はエレクトロニクスを用いた通信システムでメッセージを交換する手段であるんや。
おーまかなトコ
インターネットの初期からある通信手段なんやし、Unix to Unix Copy Protocol (UUCP) やSimple Mail Transfer Protocol (SMTP) などのプロトコルを介して、メールを相手サーバに届ける事ができる。電気的な信号で送受信を行うのでかかる時間は数分程度であるんや。
一方で、インターネットの普及よりどエライ昔にコンピュータ通信手段として広く行われとった、なんちうか、ようみなはんいわはるとこの パソコン通信そやけど、加入者同士で文書のやり取りを行うシステムが「電子メール」として提供されとったちうわけや。せやけど 、パソコン通信では、一般的に、通信が1つのパソコン通信システム内にとどまっとったさかい、他のシステムとの間での電子メールの交換機能などの相互通信機能は、一部のケースを除きほとんどへんかったちうわけや。また、各パソコン通信システムごとに独自のシステムが構築されとった事が多かったため、ユーザインタフェース等についても互換がへんかったちうわけや。せやけど その後、インターネットの普及に伴い、大手パソコン通信システムとインターネット間で相互に通信が可能にもなりよったちうわけや。メール友達（メル友）も、流行になりよった時期があったちうわけや。
インターネットが普及し始めた頃（あるいは現在も）はBBSの書き込みやブログのコメントさえも含めて「メール」と呼称しとったライトユーザが多かったちうわけや。
また、携帯電話やPHS間でごく短い文字メッセージ（メール）をやりとりする、ショートメッセージサービス（SMS。iモードなどのサービス開始前より行われておる）も、広義の電子メールに含まれる。
なお、以下では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規格に基づくルールを決めて日本語を扱えるようにした（JUNET利用の手引第一版）。このルールをMIMEの枠組みで再定義したものがISO-2022-JPであるんや。現在の日本語メールでは、このISO-2022-JPが広く用いられておる。
RFC 2277では、出来よるだけ広く知られはった文字コードを選ぶように注意を促しておる。これはUTF-8が普及するまでの暫定的なものであるが、その期間は50年であるかもしれへんので事実上は永遠と考えてよいとも書かれておる。(Using International Characters in Internet Mail)
メール形式
元来は、メールはプレーンテキスト形式の物のみやったが、上記MIMEの規定および普及に伴い、メール本文をHTMLにより記述したHTML形式のメールも、RFCに規定され一般にも使われるようになりよったちうわけや。HTML形式のメールを単にHTMLメールと呼ぶ事も多い。
HTML形式のメールは、メール本文をHTMLで記述できるため、メールにWebページと同様の表現力を持たせられはる利点があるんや。携帯電話・PHSそやけど、cHTML形式のメールが一般向け仕様のサービスとして提供されておるものもあるんや。
その一方で、特に、Microsoft Windowsと、その標準電子メールクライアントであるOutlook Express（メールの作成はHTML形式がデフォルト）の普及に伴い、HTML形式のメールが送受信されることも多くなりよったちうわけや。せやけど ながら、電子メールクライアントにおいては、メール中のHTMLデータを展開し表示するためのレンダリングエンジン（特にInternet Explorerを用おる物）にしばしばセキュリティホールが発見されておるため、メールを見る（プレビューする）だけで、コンピュータウイルスが侵入する被害を受けたり、迷惑メール・架空請求メール等で画像タグを埋め込んやメールを送りつけて表示させ、メールを表示させた情報を収集（ウェブビーコンとぬかす）して悪用するなど、セキュリティ上の問題があるんや。そやから、HTML形式のメールをフィルタリング機能などではねる（人によってはゴミ箱フォルダへ振り分ける）設定をしておることもあるんや。また、全ての電子メールクライアントがHTMLメールの表示に対応しておる訳でもへんため、一般的には、断り無くHTML形式のメールは送信せんようにすることが、なんちうか、ようみなはんいわはるとこの ネチケットの一つとされる。
なお、あるファイルデータをメールに添付して送る場合、添付ファイルとしてMIMEなどによってテキスト化（エンコード）をしてメール本文に埋め込んで送信し、受信側で元のデータファイルに復元（デコード）する方法が取られはる。添付ファイルには、コンピュータウイルスも仕込む事が可能なため、受信時に添付ファイルを自動的に開く設定になっておると、やっぱりコンピュータウイルスが侵入する被害を受けるなどの危険もあるんや。そやから、一部では添付ファイルはせんでメール本文に記載するようにメール受信側から促しておる場合もあるんや。
ヘッダ情報
一通一通それぞれのメールは、本文とは別に、ヘッダフィールドと呼ばれる各種の特殊な情報が記載された領域を持つ。殆どの電子メールクライアントでは、何らかの方法（電子メールクライアント毎に異なる）によちう、このヘッダフィールドの情報を参照可能であるんや。この情報は、脅迫メールやスパムなどのメールが届く場合などに、送信元の特定などに威力を発揮する。せやけど 、偽装も可能でじぇったいしもすべてのヘッダフィールドを付加する必要はへんため、完全に判断することはできへん。
代表的なヘッダフィールド
ヘッダフィールドは フィールド名:フィールド値 ちう形で記載される。
- Return-Path
- SMTP通信で送信元として伝えられはるメールアドレス
- Received
- このメールが届くまでに経由したメール転送エージェント（IPアドレス）および経由した日時
- Message-ID
- メール一通一通に付加された固有の番号
- In-Reply-To
- 返信元メールなどのMessage-IDの値のリスト
- From
- 著者のメールアドレス。単数または複数の名前やアドレスも含めることができる。
- このヘッダの記載は送信者が電子メールクライアントの設定によって自由に変更できる。このような電子メールの仕様から、なんちうか、ようみなはんいわはるとこの 「なりすまし」などの悪用を完全に防ぐことは困難とされる。
- Sender
- 送信者のメールアドレス。名前も含めることができる。著者と送信者が同一、すなわち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機能の違い・それぞれに指定されて送信された相手に見えるオノレ 以外の送信先をよく理解して使わへんと、例としてメールアドレスの個人情報漏洩など、色々な意味で難儀な事になることもあるんや。
- Cc（カーボンコピー、Carbon Copy）
- To:で指定した本来の送信先以外にも、一応コピーを送っておきたい相手などがおる場合に使用する機能であるんや。
- To:で宛先を指定するのと同様に、Cc:にコピーを送りたい相手を指定して使用する。To:に指定された本来の相手には、To:とCc:に指定された宛先が全て見える。また、Cc:に指定された相手にも、To:とCc:に指定された宛先が全て見える。
- 要するに、送信者 (From:)、To:の相手、Cc:の相手、の各3者相互で、各アドレスが各3者全員に知られはることになる。
- Bcc（ブラインドカーボンコピー、Blind Carbon Copy）
- To:で指定した本来の送信先以外にも、一応コピーを送っておきたい相手がおる、せやけど To:とCc:に指定した相手にはこのBcc機能を使ってコピーを送った相手、もしくはその相手がおることを知られはったへん、ちう場合などに使用する機能であるんや。
- 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）」と言われることがあるが、これは間違いであるんや。そう覚えておる人も少なへんさかい、それで通じることもあるが、言葉として利用する際には「ブラインドカーボンコピー」が望ましおまんねん。
ReとFw
- Re
- Re:は返信されたメールのサブジェクトに付加される。この略号は、電子メールクライアントの機能で自動的に付加され、これがあることによって返信されたメールであることがわかる。せやけど 、送信者が送信時にサブジェクトから意図的に削除することもできる。
-
- Fw（フォワード、Forward）
- Fw:は、転送されたメールのサブジェクトに付加される略号であるんや。この略号も電子メールクライアントの機能で自動的に付加されるもさかい、Fw:が連続していれば何度も転送されたメールやゆうことが分かる。これもRe:同様、送信者が送信時にサブジェクトから意図的に削除することもできる。Fw:の連続はチェーンメールに多いため、チェーンメールかどうかを判別する1つの手段にもなる。そやから、転送時にFw:を削除するように指示する内容が記述されたチェーンメールもあるんや。
歴史
電子メールの起源
電子メールはインターネットに先行して開発されたちうわけや。既存の電子メールシステムはインターネットを作るに当たって重要な道具となりよったちうわけや。
最初の電子メールは1965年、メインフレーム上のタイムシェアリングシステムの複数ユーザーが相互に通信する方法として使われ始めたちうわけや。正確なトコ は不明やけど その類の機能を持つ最初のシステムとして、SDC（ランド研究所からのスピンオフでSAGEのソフトウェア開発を行った会社）のQ32システムとMITのCTSSがあるんや。
電子メールは間もなくユーザーが異なるコンピュータ間でメッセージをやり取りするための「ネットワーク電子メール」に拡張されたちうわけや。1966年には異なるコンピュータ間で電子メールを転送しとった（SAGEでの詳細は明らかではおまへんが、もっと早い時期に実現しとったかもしれへん）。
ARPANETは電子メールの発展に多大な影響を与えたちうわけや。その誕生直後の1969年にシステム間電子メール転送の実験を行ったゆうリポートがあるんや。BBN社のレイ・トムリンソンは1971年にARPANET上の電子メールシステムを開発し、初めて@を使ってユーザー名とマシンを指定できるようにしたちうわけや。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など）。
問題
不着や遅延
電子メールの不着及び遅延の主な原因となっておるのはスパムメールであるんや。ある報告によると、2007年中に送信されたメールのうち90%から95%がスパムメールやったゆう。大量に送信されるこれらのスパムメールはメールサーバに過大な負荷を与え、メール配送遅延の大きな原因となっておる。たとえば2004年7月下旬から8月上旬にかけて、大手インターネットプロバイダ@niftyで、アチラ から大量に送信されたスパムメールによりメールサーバに断続的な負担が掛かり、メールの受信に支障が生じる状態が続いたちうわけや。
また近年、トロイの木馬などのマルウェアに感染しゾンビ化したコンピュータ群によって引き起こされるDDoS型のスパム送信の割合が急激に増加しとり、まんねんまんねんメールサーバに多大な負荷を及ぼすものとされておる（→ボットネットを参照）。
また、スパムメール対策としてサーバ上、クライアント上でのフィルタリングが普及してきたが、誤検知により通常のメールがスパムであると判断されてしもて、不着となるトラブルが増えておる（→電子メールフィルタリングを参照）。
スパム以外に配送遅延の大きな原因となるのが、なんちうか、ようみなはんいわはるとこの 「年賀メール」であるんや。新年を迎えるといっぺんに大量のメール送信が発生し、サーバに負荷がかかり遅延が発生することがあるんや。ここ数年はメールサーバの処理能力向上により、かつてに比べると問題となることは減ったものの、特に携帯電話・PHSのメール機能は「即時にコミュニケーションを取りあう手段」としてチャット的に利用される傾向があるために年賀メールの発信も多く、遅延や輻輳の可能性も高い。このため毎年年末の、特に年をまたぐ時間帯には各キャリアが年越時間帯のメール、コールの自粛を呼びかけておる。また、平行して発信制限も行っておる。
かつてパソコン通信が全盛やった時代には、処理の集中を防ぐため、あらかじめ年賀メールをサーバに予約送信しておき元旦に順次配送するといったサービスも提供されとったちうわけや。
コミュニケーション上の問題
パソコン通信やインターネット等における文字だけのコミュニケーションに見られはる問題（炎上、）は電子メールにおいても見られはる。メールの真意、感情が相手に伝わらへんし、度々トラブルに発展するケースが挙げられておる。英語圏では、メールの真意を読み取り間違え、感情に任せて送るメールの呼称（スラング）にFlame Mailちうものがあるんや。
関連項目
- メールサーバ - Domain Name System（DNS）
外部リンク
カテゴリ：電子メール
カテゴリ：パソコン通信
カテゴリ：インターネット
カテゴリ：コンピュータネットワーク
カテゴリ：デジタル革命
出典: フリー百科事典『ウィキペディア（Wikipedia）』
Text is available under GNU Free Documentation License.
page1 page2 page3 page4 page5
|
