メール
Mail sent using electronic means

このスクリーンショットは、電子メール クライアントの「受信トレイ」ページを示しています。ユーザーはここで新しい電子メールを確認し、これらのメッセージを読む、削除する、保存する、返信するなどのアクションを実行できます。
Wikipediaの「ロボット」が画像ファイルに変更を加えると、アップロードした人は変更内容に関するメールを受け取ります。

電子メール（通常はemailと略されるが、ハイフンでつないだe-mailとも表記される）は、コンピュータネットワークを介して電子機器を用いてデジタルメッセージを送受信する方法である。20世紀後半に、メール（e- + mail）のデジタル版、あるいはそれに相当するものとして考案された。電子メールは広く普及しており、広く利用されている通信手段である。現在、電子メールアドレス（通常はローカルパート+ @ +ドメイン名）は、多くの国において、ビジネス、商業、政府、教育、娯楽、その他日常生活のあらゆる場面において、基本的かつ不可欠な要素として扱われている。

電子メールは、主にインターネット、そしてローカルエリアネットワークといったコンピュータネットワークを介して機能します。今日の電子メールシステムは、ストアアンドフォワードモデルに基づいています。電子メールサーバーは、メッセージを受信し、転送し、配信し、保存します。ユーザーとそのコンピュータは、同時にオンラインである必要はありません。通常は、メッセージを送受信したりダウンロードしたりするために、 メールサーバーまたはウェブメールインターフェースに接続する必要があります。

インターネットメールは元々 ASCIIテキストのみの通信媒体でしたが、MIMEによって拡張され、拡張文字セットのテキストや画像などのマルチメディアコンテンツを伝送できるようになりました。UTF -8を使用した国際化メールアドレスを持つ国際メールは標準化されていますが、広く普及していません。[1]

用語

電子メールという用語は、1975年から現代的な意味で使用されており、短縮形のEメールのバリエーションは1979年から使用されています。[2] [3]

  • emailは現在では一般的な形式であり、スタイルガイドでも推奨されています。 [4] [5] [6]これはIETFの Requests for Comments （RFC）とワーキンググループで要求されている形式です。 [7] この綴りはほとんどの辞書にも載っています。 [8] [9] [4] [10]
  • 電子メールはもともと、編集された出版されたアメリカ英語とイギリス英語の文章で好まれていた形式で、以前はいくつかのスタイルガイドでも好まれていました。 [4]
  • 電子メールが使用されることもあります。 [11] 1979年6月に、雑誌「エレクトロニクス」で、1970年代後半に開発され、1980年代初頭に運用された米国郵政公社のE-COMという取り組みについて初めて使用されました。 [2] [3]
  • EMAILは1981年4月からCompuServeによって使用され、この用語が普及しました。 [12] [13]
  • EMail は、RFC で「著者のアドレス」として使用される従来の形式です。

このサービスはしばしば単にメールと呼ばれ、電子メール1通はメッセージと呼ばれます。電子メール内のフィールド（「宛先」、「差出人」、「CC」、「BCC」など）の規則は、1975年のRFC-680で始まりました。[14]

インターネット電子メールはエンベロープとコンテンツで構成されています。[15]コンテンツはヘッダーと本文で構成されています。[16]

歴史

1960年代初頭のタイムシェアリングの登場により、同一システムを利用するユーザー間のコンピュータベースのメッセージングが可能になり、1965年にはMITのCTSSプロジェクトによって注目すべき実装が行われました。[17]初期のメインフレームやミニコンピュータの開発者の多くは、類似した、しかし一般的に互換性のないメールアプリケーションを開発しました。1971年には、最初のARPANETネットワークメールが送信され、ユーザーのシステムアドレスを「 @ 」記号で示す、現在ではおなじみのアドレス構文が導入されました。 [18]一連のRFCを通じて、ファイル転送プロトコル（FTP）を介してメールメッセージを送信するための規約が改良されました。

独自の電子メールシステムがすぐに登場し始めた。IBM 、CompuServe、Xeroxは1970年代に社内メールシステムを使用していた。CompuServeは1978年に商用社内メール製品をIBMに、1981年からはXeroxに販売した。[注 1] [19] [20] [21] DECのALL-IN-1とHewlett-PackardのHPMAIL（後のHP DeskManager）は1982年にリリースされた。前者の開発は1970年代後半に始まり、後者は世界で最も売れた電子メールシステムとなった。[22] [23]

シンプルメール転送プロトコル（SMTP）は1983年にARPANETに実装されました。LAN電子メールシステムは1980年代半ばに登場しました。1980年代後半から1990年代初頭にかけては、商用の独自システムか、政府開放型システム相互接続プロファイル（GOSIP）の一部であるX.400電子メールシステムのいずれかが主流になると思われました。しかし、1995年にインターネットを介した商用トラフィックの伝送に関する最終的な制限が解除されると、[24] [25]様々な要因が重なり、現在のSMTP、POP3、IMAP電子メールプロトコルからなるインターネットスイートが標準となりました（プロトコル戦争を参照）。[26] [27]

手術

以下は、送信者アリスがメールユーザーエージェント（MUA）を使用して受信者の電子メールアドレス宛にメッセージを送信するときに発生する典型的な一連のイベントです。 [28]

メール操作
  1. MUA はメッセージを電子メール形式にフォーマットし、送信プロトコル ( Simple Mail Transfer Protocol (SMTP)のプロファイル) を使用して、メッセージの内容をローカルのメール送信エージェント(MSA) (この場合はsmtp.a.org ) に送信します。
  2. MSAは、SMTPプロトコル（メッセージヘッダーではなく）で提供される宛先アドレス（この場合は[email protected] ）を特定します。これは完全修飾ドメインアドレス（FQDA）です。@記号の前の部分はアドレスのローカル部分（通常は受信者のユーザー名）であり、@記号の後の部分はドメイン名です。MSAはドメイン名を解決し、ドメインネームシステム（DNS）内のメールサーバーの完全修飾ドメイン名を特定します。
  3. ドメインb.org（ns.b.org ）のDNSサーバーは、そのドメインのメール交換サーバー（この場合は受信者のISPによって実行されるメッセージ転送エージェント（MTA）サーバーであるmx.b.org ）をリストするMXレコードで応答します。 [29]
  4. smtp.a.org は SMTP を使用してメッセージを mx.b.org に送信します。このサーバーは、メッセージが最終的なメッセージ配信エージェント(MDA) に到達する前に、他の MTA にメッセージを転送する必要がある場合があります。
  5. MDA はそれをユーザーbobのメールボックスに配信します。
  6. Bob の MUA は、Post Office Protocol (POP3) またはInternet Message Access Protocol (IMAP)のいずれかを使用してメッセージを取得します。

この例に加えて、電子メール システムには代替手段と複雑な問題が存在します。

  • アリスやボブは、 IBM Lotus NotesやMicrosoft Exchangeなどの企業メールシステムに接続されたクライアントを使用する場合があります。これらのシステムは独自の内部メールフォーマットを備えていることが多く、クライアントは通常、ベンダー固有の専用プロトコルを使用してメールサーバーと通信します。サーバーは、製品のインターネットメールゲートウェイを介してインターネット経由でメールを送受信し、必要なフォーマット変換も行います。アリスとボブが同じ会社に勤務している場合、すべてのトランザクションが単一の企業メールシステム内で行われる可能性があります。
  • アリスのコンピューターには MUA がインストールされていない可能性がありますが、代わりにウェブメールサービスに接続している可能性があります。
  • アリスのコンピューターは独自の MTA を実行している可能性があるため、ステップ 1 での転送は回避されます。
  • Bob は、mx.b.org にログインして直接読んだり、Web メール サービスを使用したりなど、さまざまな方法で電子メールを受け取ることができます。
  • ドメインには通常、プライマリが利用できない場合でもメールを引き続き受け入れることができるように、複数のメール交換サーバーがあります。

多くのMTAは、インターネット上のあらゆる受信者宛てのメッセージを受け付け、最善を尽くして配信していました。このようなMTAはオープンメールリレーと呼ばれています。これは、ネットワーク接続が不安定だったインターネット初期の時代には非常に重要でした。[30] [31]しかし、この仕組みは迷惑メール の送信者によって悪用される可能性があることが判明し、その結果、オープンメールリレーは稀になり、[32]多くのMTAはオープンメールリレーからのメッセージを受け付けなくなりました。

電子メールはインスタントメッセージよりも古く、信頼性の低いネットワーク接続や混雑したサーバー（インターネット初期にはより一般的でした）に対応するため、速度よりも信頼性を重視して送信されました。配信速度が遅い理由としては、以下のことが挙げられます。[33]

  • 多数の受信者に送信されるメッセージには、より多くの処理が必要です
  • 大きなメッセージ（大きな添付ファイルなど）は、ネットワーク経由での送信に時間がかかります。
  • メッセージは複数のサーバーを通過する必要がある（場合によっては同じ組織内の複数のサーバー）
  • 1 つ以上のメール サーバーが過負荷状態 (スパムまたはサービス拒否攻撃による可能性あり) になっており、受信メールをキューに入れているか、一時的に受信接続を拒否しています。
  • SMTPは複数回のやり取りを必要とするため、ネットワークの遅延やパケットのドロップの影響が大きくなる可能性がある。
  • 送信者または受信者が一時的にネットワークから切断されている（例：ノートパソコンがWi-Fiの範囲外にある）
  • DNS応答が遅い
  • メンテナンスまたは故障のためサーバーがダウンしています

メールはキューに入れられ、最大5日間再試行された後、送信者に永続的な配信失敗が通知されます。[33]メッセージは各サーバーを通過する際にタイムスタンプが付けられるため、配信遅延の診断が可能ですが、タイムゾーンやコンピュータの時計の不正確な設定によって分析は複雑になります。[33]

スパム フィルターによってスパムとして分類された電子メール メッセージは、受信者が手動で確認する必要がある別のフォルダーに分類されるか、完全に削除される可能性があります。

メッセージ形式

電子メール[34]に使用される基本的なインターネットメッセージフォーマットはRFC 5322で定義されており 、非ASCIIデータとマルチメディアコンテンツの添付ファイルのエンコードはRFC 2045からRFC 2049で定義されており、これらは総称して多目的インターネットメール拡張（MIME）と呼ばれます。国際電子メールにおけるこの拡張は電子メールにのみ適用されます。RFC 5322は2008年にRFC 2822に取って代わりました。それ以前の2001年には、RFC 2822が、数十年にわたりインターネット電子メールの標準であったRFC 822に取って代わりました。1982年に発行されたRFC 822は、ARPANET向けのRFC 733に基づいています。[35]

インターネット電子メールは、「ヘッダー」と「本文」という2つのセクションで構成されています。これらは「コンテンツ」と呼ばれます。[36] [37] ヘッダーは、送信者、宛先、CC、件名、日付などのフィールドや、電子メールに関するその他の情報で構成されています。システム間で電子メールメッセージを転送するプロセスにおいて、SMTPはメッセージヘッダーフィールドを使用して配信パラメータと情報を伝達します。本文には、メッセージが非構造化テキストとして含まれており、末尾に署名ブロックが含まれる場合もあります。ヘッダーと本文は空行で区切られています。

メッセージヘッダー

RFC 5322 は電子メールヘッダーの構文を規定しています。各電子メールメッセージにはヘッダー（仕様ではメッセージの「ヘッダーセクション」）があり、ヘッダーセクションは複数のフィールド（「ヘッダーフィールド」）で構成されています。各フィールドには名前（「フィールド名」または「ヘッダーフィールド名」）があり、その後に区切り文字「:」と値（「フィールド本体」または「ヘッダーフィールド本体」）が続きます。

各フィールド名は、ヘッダーセクションの改行の最初の文字から始まり、空白文字を含まない 印刷可能な文字で始まります。区切り文字 ":" で終わります。区切り文字の後にフィールド値（「フィールド本体」）が続きます。フィールド値は、先頭文字がスペースまたはタブである行以降に継続できます。フィールド名と、SMTPUTF8を使用しない場合はフィールド本体は、7ビットASCII文字に制限されます。一部の非ASCII値は、MIMEエンコードされた単語を使用して表される場合があります。

ヘッダーフィールド

電子メールのヘッダーフィールドは複数行にすることができ、各行は78文字以下が推奨されますが、最大998文字です。[38] RFC 5322で定義されているヘッダーフィールドにはUS-ASCII文字のみが含まれます。他のセットの文字をエンコードするには、RFC 2047で指定された構文を使用できます。[39]いくつかの例では、IETF EAIワーキンググループがいくつかの標準化トラック拡張を定義し、[40] [41]以前の実験的な拡張を置き換えて、UTF-8でエンコードされたUnicode文字をヘッダー内で使用できるようになりました。特に、これによりメールアドレスに非ASCII文字を使用できるようになります。このようなアドレスはGoogleやMicrosoftの製品でサポートされており、一部の政府機関によって推奨されています。[42]

メッセージヘッダーには少なくとも以下のフィールドが含まれている必要があります: [43] [44]

  • 送信元: メールアドレス、およびオプションで著者名。一部のメールクライアントでは、アカウント設定で変更できます。
  • 日付: メッセージが作成された現地の日時。From :フィールドと同様に、多くのメールクライアントは送信前にこのフィールドを自動的に入力します。受信者のクライアントでは、現地のタイムゾーンと形式に従って時刻が表示される場合があります。

RFC 3864は、 IANAにおけるメッセージヘッダーフィールドの登録手順について規定しています。MIME、ネットニュース、HTTP用に定義されたフィールドを含む、恒久的および暫定的なフィールド名を規定し、関連するRFCを参照しています。電子メールの一般的なヘッダーフィールドには、以下のものがあります。[45]

  • 宛先: メッセージの受信者のメールアドレス（複数可）と、オプションで名前。主な受信者（複数可）を示します。二次的な受信者については、以下の「Cc:」と「Bcc:」を参照してください。
  • 件名: メッセージの主題の簡単な要約。件名には「RE:」や「FW:」などの略語がよく使用されます。
  • Cc :カーボンコピー。多くの電子メール クライアントは、電子メールが To: リストに含まれているか、Cc: リストに含まれているかに応じて、受信トレイ内の電子メールに異なるマークを付けます。
  • Bcc :ブラインド カーボン コピー。アドレスは通常、SMTP 配信時にのみ指定され、メッセージ ヘッダーにはリストされません。
  • Content-Type : メッセージの表示方法に関する情報。通常はMIMEタイプです。
  • 優先順位: 通常は「bulk」、「junk」、「list」のいずれかの値を持ちます。このメールに対して自動返信（「休暇」または「不在」）を返さないことを示すために使用されます。例えば、メーリングリストの他のすべての購読者に休暇通知が送信されないようにするなどです。Sendmailはこのフィールドを使用して、キューに入れられたメールの優先順位を制御します。「優先順位: 特別配信」のメッセージはより早く配信されます。現代の高帯域幅ネットワークでは、配信の優先順位は以前ほど重要ではありません。Microsoft Exchangeは、きめ細かな自動返信抑制メカニズムであるX-Auto-Response-Suppressフィールドに従います。[46]
  • Message-ID : 複数回の配信を防ぎ、In-Reply-To: で参照するために自動生成されるフィールドです (以下を参照)。
  • In-Reply-To : 返信先のメッセージのメッセージID。関連するメッセージをリンクするために使用されます。このフィールドは返信メッセージにのみ適用されます。
  • List-Unsubscribe : メーリング リストから登録解除するための HTTP リンク。
  • 参照: この返信の対象となるメッセージのメッセージ ID、前の返信の対象となるメッセージのメッセージ ID など。
  • Reply-To : メッセージに返信するにはこのアドレスを使用します。
  • 送信者: From: フィールドにリストされている著者に代わって行動する送信者のアドレス (秘書、リスト管理者など)。
  • Archived-At : 個々の電子メール メッセージのアーカイブされた形式への直接リンク。

To :フィールドは、メッセージが配信されるアドレスとは無関係である場合があります。配信リストはトランスポートプロトコルSMTPに別途提供され、ヘッダーの内容から抽出される場合があります。「To:」フィールドは、外封筒の住所に基づいて配送される従来の手紙の冒頭にある宛名に似ています。同様に、「From:」フィールドは送信者ではない場合があります。一部のメールサーバーでは、中継されるメッセージに電子メール認証システムを適用しています。サーバーのアクティビティに関するデータも、以下に定義されるようにヘッダーの一部となります。

SMTPは、次の2つのフィールドを使用してヘッダーに保存されるメッセージのトレース情報を定義します。 [47]

  • 受信: SMTP サーバーがメッセージを受け取った後、このトレース レコードをヘッダーの先頭 (最後から最初) に挿入します。
  • Return-Path : 配信 SMTP サーバーがメッセージを最終的に配信した後、このフィールドをヘッダーの先頭に挿入します。

受信側サーバーによってヘッダーの上に追加される他のフィールドはトレースフィールドと呼ばれることがあります。[48]

  • 認証結果: サーバーが認証を検証した後、下流のエージェントが使用するためにこのフィールドに結果を保存することができます。[49]
  • Received-SPF : Authentication-Resultsよりも詳細なSPFチェックの結果を保存します。 [50]
  • DKIM署名：ドメインキー識別メール（DKIM）復号化の結果を保存し、メッセージが送信後に変更されていないことを確認します。[51]
  • 自動送信: 自動生成されたメッセージにマークを付けるために使用されます。[52]
  • VBR-Info：VBRホワイトリストを主張[53]

メッセージ本文

コンテンツのエンコーディング

インターネット電子メールは7ビットASCII用に設計されました。[54]ほとんどの電子メールソフトウェアは8ビットクリーンですが、7ビットサーバーやメールリーダーと通信することを前提としています。MIME標準では、非ASCIIデータの送信を可能にするために、文字セット指定子と2つのコンテンツ転送エンコーディングが導入されました。1つは、主に7ビットのコンテンツで、その範囲外の文字がいくつか含まれる場合はquoted printable 、もう1つは任意のバイナリデータ用のbase64です。8BITMIME拡張とBINARY拡張は、これらのエンコーディングを必要とせずにメールを送信できるようにするために導入されましたが、多くのメールトランスポートエージェントはこれらをサポートしていない可能性があります。一部の国では、電子メールソフトウェアが生の[注2]非ASCIIテキストを送信することでRFC  5322に違反しており、複数のエンコーディングスキームが共存しています。その結果、デフォルトでは、非ラテンアルファベット言語のメッセージは判読不能な形式で表示されます（唯一の例外は、送信者と受信者が同じエンコーディングスキームを使用している場合の偶然です）。そのため、国際文字セットとしては、Unicodeの人気が高まっています。[55]

プレーンテキストとHTML

最新のグラフィックメールクライアントのほとんどは、ユーザーの選択により、メッセージ本文にプレーンテキストまたはHTMLのいずれかを使用できます。HTMLメールメッセージには、互換性のために自動生成されたプレーンテキストのコピーが含まれることがよくあります。

HTMLの利点としては、インラインリンクや画像を挿入できること、ブロック引用符で前のメッセージを区切ることができること、あらゆるディスプレイで自然に折り返せること、下線や斜体などの強調機能を使うことができること、フォントスタイルを変更できることなどが挙げられます。欠点としては、メールのサイズが大きくなること、ウェブバグに関するプライバシーの懸念があること、HTMLメールがフィッシング攻撃の手段として悪用されること、悪意のあるソフトウェアが拡散されることなどが挙げられます。[56] 一部のメールクライアントは、Content-Type: htmlヘッダーフィールドがなくても本文をHTMLとして解釈するため、さまざまな問題が発生する可能性があります。

一部のウェブベースのメーリングリストでは、上記の理由[57] [58]に加え、 Muttなどのテキストベースのメールクライアントを使用している読者が多数いることから、すべての投稿を1行72文字または80文字のプレーンテキストで行うことを推奨しています。メールやUsenetの投稿でプレーンテキストをマークアップするための様々な非公式な慣例が生まれ、後にsetext （1992年頃）などの形式言語の開発につながり、その中で最も普及しているのはmarkdownです。

一部のマイクロソフトの電子メールクライアントでは、独自のリッチテキストフォーマット（RTF）を使用したリッチフォーマットが許可される場合がありますが、受信者が互換性のある電子メールクライアントを持っていることが保証されていない限り、これは避けるべきです。[59]

サーバーとクライアントアプリケーション

メールクライアントThunderbirdのインターフェース

メッセージは、メール転送エージェント（MTA）と呼ばれるソフトウェアプログラムを介して、簡易メール転送プロトコル（Simple Mail Transfer Protocol ）を用いてホスト間で交換され、メール配信エージェント（MDA、ローカル配信エージェント（LDA）と呼ばれるプログラムによってメールストアに配信されます。メッセージを受信すると、MTAはメッセージを配信する義務を負います。[60]メッセージを配信できない場合、MTAは送信者に問題を示すバウンスメッセージを返送する必要があります。

ユーザーは、 POPやIMAPなどの標準プロトコル、あるいは大企業環境ではより一般的であるNovell Groupwise、Lotus Notes、またはMicrosoft Exchange Serversに固有の独自プロトコルを使用して、サーバーからメッセージを取得できます。ユーザーが電子メールを取得、閲覧、管理するために使用するプログラムは、メールユーザーエージェント（MUA） と呼ばれます。

メールを開くと「既読」と表示され、通常、クライアントのユーザーインターフェース上で「未読」のメッセージと区別されます。メールクライアントによっては、ユーザーが未読メールに集中できるよう、受信トレイで既読メールを非表示にする機能を備えている場合があります。[61]

メールはクライアント側、サーバー側、またはその両方に保存できます。メールボックスの標準形式には、 Maildirとmboxがあります。多くの主要なメールクライアントは独自の形式を使用しており、それらの間でメールを転送するには変換ソフトウェアが必要です。サーバー側の保存形式は多くの場合独自形式ですが、アクセスはIMAPなどの標準プロトコルを介して行われるため、プロトコルをサポートする 任意のMUAを使用して、あるサーバーから別のサーバーへのメールの移動が可能です。

現在の多くの電子メールユーザーは、MTA、MDA、またはMUAプログラムを自分で実行するのではなく、GmailやYahoo!メールなどの同じタスクを実行するWebベースの電子メールプラットフォームを使用しています。[62]このようなWebメールインターフェースにより、ユーザーはローカルの電子メールクライアントに頼ることなく、任意のコンピューターから 任意の標準Webブラウザを使用してメールにアクセスできます。

ファイル名拡張子

メールクライアントアプリケーションは、メールを受信すると、ファイルシステム内のオペレーティングシステムファイルにメッセージを保存します。クライアントによっては、個々のメッセージを個別のファイルとして保存するものもありますが、他のクライアントでは、様々なデータベース形式（多くの場合、独自の形式）を使用して一括保存されています。保存の歴史的な標準はmbox形式です。使用される形式は、多くの場合、特別なファイル名拡張子で示されます。

eml
Novell GroupWise、Microsoft Outlook Express、Lotus Notes、Windows Mail、Mozilla Thunderbird 、Postboxなど、多くのメールクライアントで使用されています。ファイルには、メールのヘッダーと本文、そして1つ以上の形式の添付ファイルを含む、MIME形式のプレーンテキストメールの内容が含まれています。
emlx
Apple Mailで使用されます。
msg
Microsoft Office Outlookおよび OfficeLogic Groupwareで使用されます。
mbx
mbox 形式に基づいてOpera Mail、KMail、Apple Mailで使用されます。

一部のアプリケーション（Apple Mailなど）では、添付ファイルを検索用にメッセージにエンコードしたまま、別個のコピーも保存します。一方、添付ファイルをメッセージから分離し、特定のディレクトリに保存するアプリケーションもあります。

URIスキーム mailto

IANAに登録されているURIスキームは、SMTP電子メールアドレスのスキームを定義しています。そのmailto:用途は厳密には定義されていませんが、この形式のURLは、URLがアクティブ化された際に、ユーザーのメールクライアントの新規メッセージウィンドウを開き、To:フィールドにURLで定義されたアドレスを使用することを目的としています。[63] [64]多くのクライアントは、件名やカーボンコピーの受信者など、他の電子メールフィールドに対するクエリ文字列パラメータもサポートしています。[65]

種類

ウェブベースの電子メール

多くのメールプロバイダーはウェブベースのメールクライアントを提供しています。これにより、ユーザーは互換性のあるウェブブラウザを使用してメールアカウントにログインし、メールを送受信できます。メールは通常、ウェブクライアントにダウンロードされないため、インターネットに接続していないと読むことができません。

POP3メールサーバー

ポストオフィスプロトコル3（POP3）は、クライアントアプリケーションがメールサーバーからメッセージを読み取るために使用するメールアクセスプロトコルです。受信メッセージは多くの場合サーバーから削除されます。POPは、リモートメールボックス（POP RFCではメールドロップと呼ばれます）へのアクセスにおいて、シンプルなダウンロードと削除の要件をサポートしています。[66] POP3では、メッセージをローカルコンピュータにダウンロードし、オフラインでも読むことができます。[67] [68]

IMAPメールサーバー

インターネットメッセージ アクセス プロトコル(IMAP) は、複数のデバイスからメールボックスを管理する機能を提供します。スマートフォンなどの小型の携帯デバイスは、移動中にメールをチェックしたり、簡単な返信をしたりするためにますます利用されるようになり、キーボード操作性に優れた大型デバイスは、より長い返信をするために利用されています。IMAP では、メッセージのヘッダー、送信者、件名が表示され、デバイスは特定のメッセージをダウンロードするように要求する必要があります。通常、メールはメールサーバーのフォルダに保存されます。

MAPIメールサーバー

メッセージング アプリケーション プログラミング インターフェイス(MAPI) は、 Microsoft OutlookによってMicrosoft Exchange Serverと通信するために使用されます。また、ベンダーが MAPI サポートを追加して Outlook から直接製品にアクセスできるようにしているAxigen Mail Server、Kerio Connect、Scalix、Zimbra、HP OpenMail、IBM Lotus Notes、Zarafa、Bynariなどのさまざまな他の電子メール サーバー製品とも通信するために使用されます。

用途

ビジネスおよび組織での使用

電子メールは先進国の企業、政府、非政府組織に広く普及しており、職場コミュニケーションにおける「e革命」の重要な要素の一つとなっています（もう一つの重要な柱は高速インターネットの普及です）。2010年に実施された職場コミュニケーションに関するスポンサー調査によると、米国の知識労働者の83%が、電子メールは仕事における成功と生産性に不可欠だと感じています。[69]

企業やその他の組織にとって、次のような重要なメリットがあります。

物流の促進
ビジネスの世界では、物理的に同じ建物、地域、あるいは国にいない人々とのコミュニケーションが大きな役割を果たしています。対面での会議、電話、あるいは電話会議の設定や参加は、面倒で時間がかかり、費用もかかる場合があります。メールは、設定費用をかけずに2人以上の者間で情報を交換できる手段であり、一般的に物理的な会議や電話よりもはるかに安価です。
同期の支援
会議や電話によるリアルタイムコミュニケーションでは、参加者は同じスケジュールで作業する必要があり、各参加者が会議や電話に同じ時間を費やす必要があります。一方、メールは非同期処理を可能にします。各参加者は個別にスケジュールを管理できます。受信メールを一括処理することで、通話を中断するよりもワークフローを改善できます。
コスト削減
電子メールの送信は、郵便、長距離電話、テレックス、電報を送信するよりもはるかに安価です。
速度を上げる
他のほとんどの方法よりもはるかに高速です。
「書面」記録の作成
電話や対面での会話とは異なり、電子メールはその性質上、通信内容、送信者と受信者の身元、そしてメッセージの送信日時に関する詳細な記録を文書で作成します。契約や法的紛争が発生した場合、各電子メールには送信日時が記録されているため、保存された電子メールは、特定の問題について個人が通知を受けたことを証明するために使用できます。
自動処理と配送の改善の可能性
顧客の注文の前処理や担当者への対応も自動化された手順で実現できます。

メールマーケティング

「オプトイン」による電子メールマーケティングは、特別な販売オファーや新製品情報を送信するためによく使用されています。[70]受信者の文化によっては、[71]許可なく送信された電子メール（「オプトイン」など）は、歓迎されない「電子メールスパム」と見なされる可能性があります。

個人使用

パソコン

多くのユーザーは、自宅やアパートの パソコンを使用して、友人や家族からの個人メールにアクセスします。

携帯

電子メールはスマートフォンやあらゆる種類のコンピューターで利用されるようになりました。モバイル「アプリ」は、外出先でも電子メールへのアクセス性を高めています。電子メールが登場した初期の頃は、デスクトップコンピューターでしかアクセスできませんでしたが、2010年代には、街の反対側や世界中を旅する場合でも、外出先からでも電子メールをチェックできるようになりました。また、スマートフォンなどのデバイスに新着メッセージを即座に通知するアラートを送信することもできます。これにより、電子メールはユーザー間のコミュニケーションをより頻繁に行うために利用されるようになり、一日中いつでも電子メールをチェックしたり、メッセージを書いたりできるようになりました。2011年時点で[update]、世界中の電子メール利用者は約14億人で、1日に500億通の非スパムメールが送信されています。[64]

個人は、個人的なメッセージでも仕事関連のメッセージでも、スマートフォンでメールを確認することが多い。米国の成人は、ウェブの閲覧やFacebookアカウントのチェックよりもメールを確認することが多く、スマートフォンでユーザーが行う最も一般的なアクティビティはメールであることが判明した。調査回答者の78%が、スマートフォンでメールを確認していると回答した。[72]また、消費者の30%はメールの確認にスマートフォンのみを使用し、91%は少なくとも1日に1回はスマートフォンでメールを確認する可能性が高いことが判明した。しかし、スマートフォンでメールを使用する消費者の割合は国によって大きく異なり、例えば、米国では75%の消費者がスマートフォンを使用しているのに対し、インドではわずか17%であった。[73]

若者の間での使用減少

2010年時点で[update]、電子メールウェブサイトを訪問するアメリカ人の数は、2009年11月にピークを迎えた後、6%減少しました。12歳から17歳では、その数は18%減少しました。若者はインスタントメッセージ、テキストメッセージ、ソーシャルメディアを好んで利用していました。テクノロジーライターのマット・リッチテルはニューヨーク・タイムズ紙で、電子メールはビデオデッキ、レコード、フィルムカメラのように、もはやクールではなく、年配の人々が行うものだと述べています。[74] [75]

2015年にAndroidユーザーを対象に行われた調査では、13歳から24歳の人は45歳以上の人に比べてメッセージアプリを3.5倍使用しており、電子メールを使用する可能性ははるかに低いことが示されました。[76]

問題

添付ファイルのサイズ制限

電子メールには、1つ以上の添付ファイル（電子メールに追加されるファイル）が含まれる場合があります。一般的な添付ファイルには、Microsoft Word文書、PDF文書、紙文書のスキャン画像などがあります。原則として、添付ファイルのサイズや数に技術的な制限はありません。しかし実際には、電子メールクライアント、サーバー、インターネットサービスプロバイダーが、ファイルサイズ、あるいは電子メール全体のサイズにさまざまな制限を設けており、通常は25MB以下となっています。[77] [78] [79]さらに、技術的な理由により、これらのトランスポートシステムで表示される添付ファイルのサイズは、ユーザーが確認するサイズと異なる場合があり、[80]送信者がファイルを安全に電子メールで送信できるかどうかを判断する際に混乱を招く可能性があります。より大きなファイルを共有する必要がある場合は、さまざまなファイルホスティングサービスが利用可能であり、一般的に使用されています。[81] [82]

情報過多

知識労働者やホワイトカラー労働者にとって電子メールが広く普及したことにより、受信者は増加する電子メール量に対応することで「情報過多」に陥るのではないかという懸念が生じています。 [83] [84]モバイルデバイスの普及に伴い、従業員は勤務時間外にも仕事関連のメールを受信することが当たり前になっています。これはストレスの増加や仕事への満足度の低下につながる可能性があります。一部の観察者は、大量のメールを読むことで生産性が低下する可能性があるため、経済に重大な悪影響を与える可能性があると主張しています。 [85]

スパム

電子メール「スパム」とは、迷惑メールのことです。このようなメールの送信コストが低いため、2003年までにメール全体のトラフィックの最大30%がスパムとなり、[86] [87] [88]、実用的なツールとしての電子メールの有用性を脅かしていました。2003年の米国CAN-SPAM法やその他諸外国の同様の法律[89]は一定の効果を発揮し、現在では多くの効果的なスパム対策技術によって、ほとんどのユーザーに対してスパムをフィルタリングまたは拒否することで、その影響を大幅に軽減しています。[90]しかし、送信されるメールの量は依然として非常に多く、製品の広告ではなく、悪意のあるコンテンツやリンクで構成されるケースが増えています。[91]例えば、2017年9月には、正規のメールに対するスパムの割合が59.56%に上昇しました。[92] 2021年のスパムメールの割合は85%と推定されています。[93] [より適切な情報源が必要]

マルウェア

電子メールはマルウェア配布の主要な媒体です。[94]これは多くの場合、悪意のあるプログラムをメッセージに添付し、潜在的な被害者にファイルを開くように仕向けることによって行われます。[95]電子メールを介して配布されるマルウェアの種類には、コンピューターワーム[96]やランサムウェア[97]などがあります。

メールのなりすまし

メールのなりすましは、メールのヘッダーが、既知または信頼できる送信元から送信されたように見せかけるように設計されている場合に発生します。メールスパムやフィッシングの手法では、通常、なりすましを利用して受信者にメッセージの真の送信元を誤解させます。メールのなりすましは、いたずらとして行われる場合もあれば、個人または組織を欺く犯罪行為の一環として行われる場合もあります。詐欺的なメールのなりすましの例として、個人が大企業からの請求書を装ったメールを作成し、1人または複数の受信者に送信することが挙げられます。場合によっては、これらの詐欺メールに、偽装した組織のロゴが組み込まれ、メールアドレス自体が本物のように見せかけられることもあります。

メール爆撃

メールボムとは、標的のメールアドレスに大量のメッセージを意図的に送信することです。標的のメールアドレスに過負荷をかけると、そのアドレスが使用不能になり、メールサーバーがクラッシュする可能性もあります。

プライバシーに関する懸念

今日では、インターネットメールシステムと社内メールシステムを区別することが重要になる場合があります。インターネットメールは、送信者や受信者の管理下にないネットワークやコンピュータ上を移動し、保存される可能性があります。転送中に第三者が内容を読み取ったり、改ざんしたりする可能性があります。情報が組織ネットワークの外に出ることのない社内メールシステムはより安全ですが、情報技術担当者や監視・管理業務に携わる担当者が他の従業員のメールにアクセスする可能性があります。

何らかのセキュリティ対策を講じないと、電子メールのプライバシーが侵害される可能性があります。その理由は次のとおりです。

  • 電子メールメッセージは通常暗号化されません。
  • 電子メールメッセージは宛先に到達する前に中間コンピュータを通過する必要があるため、他人がメッセージを傍受して読むのは比較的簡単です。
  • 多くのインターネットサービスプロバイダー（ISP）は、メールを配信する前に、そのコピーをメールサーバーに保存します。これらのバックアップは、メールボックスから削除された後でも、サーバー上に最大数か月間残ることがあります。
  • 電子メール内の「受信日時:」フィールドやその他の情報によって送信者を特定できる場合が多く、匿名での通信を防止できます。
  • HTMLコンテンツに目に見えない形で埋め込まれたウェブバグは、メールがHTMLとしてレンダリングされるたびに（一部のメールクライアントはユーザーがメールを読んだり再読したりする際にこの処理を行います）、送信者にどのIPアドレスから送信されたかを知らせることができます。また、ユーザーエージェント文字列を介して、メールがスマートフォン、PC、あるいはApple Macデバイスで読まれたかを明らかにすることもできます。

上記の問題の1つ、あるいは複数の問題に対する解決策として役立つ暗号化アプリケーションが存在します。例えば、仮想プライベートネットワーク（ VPN）やTorネットワークは、ユーザーマシンからより安全なネットワークへのトラフィックを暗号化するために使用できます。また、 GPG、PGP、SMEmail、[98]、S/MIMEはエンドツーエンドのメッセージ暗号化に使用できます。また、SMTP STARTTLSまたはSMTP over Transport Layer Security /Secure Sockets Layerは、SMTPクライアントとSMTPサーバー間の単一メールホップの通信を暗号化するために使用できます。

さらに、多くのメールユーザーエージェントはログイン情報とパスワードを保護していないため、攻撃者に簡単に傍受されてしまいます。SASLなどの暗号化認証方式はこれを防ぎます。最後に、添付ファイルには、ピアツーピアファイル共有で見られるのと同じ危険性が数多く存在します。添付ファイルには、トロイの木馬やウイルスが含まれている可能性があります。

電子メールの交換は拘束力のある契約を形成する可能性があるため、ユーザーは電子メールのやり取りで送信する内容に注意する必要があります。[99] [100]電子メールの署名欄は、契約の署名要件を満たしていると解釈される場合があります。[101]

炎上

フレーミングとは、怒りや敵意を込めた内容のメッセージ（または複数のメッセージ）を送信することです。この用語は、特に白熱した電子メールでの議論を表す「炎上する」という表現に由来しています。電子メールでのコミュニケーションは容易で非人間的であるため、対面や電話での礼儀正しさを奨励する社会規範が存在せず、礼儀正しさが忘れ去られてしまう可能性があります。[102]

メール破産

「メール疲れ」としても知られるメール破産とは、ユーザーが大量のメールを読んで返信する時間が取れず、無視してしまう状態です。メールが読まなくなる原因は、多くの場合、情報過多と、情報量が多すぎて全て読むことができないという一般的な感覚にあります。解決策として、人々は時折、メールの受信トレイがいっぱいで、すべてのメールを整理中であることを説明する「定型文」メッセージを送信します。この用語の創始者はハーバード大学法学教授ローレンス・レッシグとされていますが、彼が広めただけかもしれません。[103]

国際化

もともとインターネットメールは完全にASCIIテキストベースでした。MIMEは現在、本文テキストと一部のヘッダーテキストを国際文字セットで使用できますが、その他のヘッダーとメールアドレスはUTF-8で標準化されていますが[104] 、まだ広く普及していません。[1] [105]

送信メールの追跡

オリジナルのSMTPメールサービスは、送信されたメッセージを追跡するためのメカニズムが限られており、メッセージが配信されたか、あるいは読まれたかを検証するメカニズムは提供されていません。各メールサーバーは、メッセージを転送するか、失敗通知（バウンスメッセージ）を返す必要がありますが、ソフトウェアのバグやシステム障害によってメッセージが失われる可能性があります。この問題を解決するために、IETFは配信状態通知（配信確認）とメッセージ処理通知（返信確認）を導入しましたが、これらは実運用環境で広く導入されているわけではありません。[注 3]

現在、多くの ISP は、スパマーの活動により、配信不能レポート (NDR) と配信確認を意図的に無効にしています。

  • 配信レポートを使用すると、アドレスが存在するかどうかを確認することができ、存在する場合は、そのアドレスがスパム送信者にスパムの送信対象であることを示します。
  • スパマーが偽造した送信元メールアドレス（メールスプーフィング）を使用した場合、使用された無実のメールアドレスは、スパマーが送信を試みた多数の無効なメールアドレスからのNDRで溢れかえってしまう可能性があります。これらのNDRは、ISPから無実のユーザーへのスパム（バックスキャッター）とみなされます。

標準的な手法が存在しない状況下で、ウェブバグを利用した様々なシステムが開発されてきました。しかし、これらはしばしば不正行為とみなされ、プライバシーに関する懸念を引き起こします。[108] [109]また、HTMLレンダリングをサポートするメールクライアントでのみ機能します。多くのメールクライアントは現在、デフォルトで「ウェブコンテンツ」を表示しない設定になっています。[110] ウェブメールプロバイダは、画像を事前にキャッシュすることでウェブバグを阻止することもできます。[111]

参照

注記

  1. ^ IBM のシステムは、正式リリース前に顧客のリクエストに応じて利用可能でした。
  2. ^ 国際化電子メールまたはMIMEを使用していない
  3. ^ 完全なメッセージ追跡メカニズムも定義されたが、普及することはなかった。RFC 3885 [106]から 3888 [107]を参照。

参考文献

  1. ^ ab 「DataMail：世界初の無料言語メールサービスがインドの8言語に対応」The Economic Times . 2016年10月22日時点のオリジナルよりアーカイブ。
  2. ^ ab "email noun earlier than 1979". Oxford English Dictionary . 2012年10月25日. 2023年4月6日時点のオリジナルよりアーカイブ。 2020年5月14日閲覧。
  3. ^ ab Ohlheiser, Abby (2015年7月28日). 「なぜ『電子メール』という単語の最初の使用は永遠に失われる可能性があるのか​​」ワシントン・ポスト. 2023年4月7日時点のオリジナルよりアーカイブ。 2020年5月14日閲覧。
  4. ^ abc 「電子メールから電子メールへ：空が落ちてくるのか？」CMOS Shop Talk。シカゴ・マニュアル・オブ・スタイル。2017年10月11日。 2024年9月18日閲覧。
  5. ^ “Yahooスタイルガイド”. Styleguide.yahoo.com. 2013年5月9日時点のオリジナルよりアーカイブ。 2014年1月9日閲覧。
  6. ^ 「AP通信、スタイルガイドの『Eメール』からハイフンを削除」ハフィントン・ポスト、ニューヨーク市、2011年3月18日。2015年5月12日時点のオリジナルよりアーカイブ。
  7. ^ 「RFC Editor Terms List」. IETF. 2013年12月28日時点のオリジナルよりアーカイブ。これは、RFCドキュメントスタイルガイド（2015年4月24日アーカイブ、Wayback Machine）で提案されています。
  8. ^ AskOxford Language Queryチーム。「『email』、『ecommerce』、『egovernment』などの『e』で始まる単語の正しい綴りは何ですか？」FAQ。オックスフォード大学出版局。2008年7月1日時点のオリジナルよりアーカイブ。 2009年9月4日閲覧。一般的な綴りである「email」の使用を推奨します。
  9. ^ “Reference.com”. Dictionary.reference.com. 2013年12月16日時点のオリジナルよりアーカイブ。2014年1月9日閲覧。
  10. ^ 「RFCスタイルガイド」、RFCにおける一貫した使用に関する決定事項の表。2013年12月28日時点のオリジナルよりアーカイブ。2014年1月9日閲覧。
  11. ^ イスラエル、マーク. 「「e-mail」の綴りは？」Alt-usage-english.org. 2012年4月3日時点のオリジナルよりアーカイブ。 2014年1月9日閲覧。
  12. ^ タイ (2015). 「VA シヴァ・アヤドゥライは電子メールを発明しましたか?」シグシス。 2022年4月17日のオリジナルからアーカイブ。2020 年9 月 5 日に取得。
  13. ^ Masnick, Mike (2019年5月22日). 「証拠をすべて明らかに：シヴァ・アヤドゥライは電子メールを発明しなかった」Techdirt . 2022年1月27日時点のオリジナルよりアーカイブ。 2020年9月5日閲覧。
  14. ^ Pexton, Patrick B. (2012年3月1日). 「電子メールの起源：私の過ち」 .ワシントン・ポスト. 2022年5月19日時点のオリジナルよりアーカイブ。 2022年4月18日閲覧。
  15. ^ 「メールオブジェクト」。Simple Mail Transfer Protocol。IETF。sec . 2.3.1。doi : 10.17487/RFC5321。RFC 5321。SMTPはメールオブジェクトを転送します。メールオブジェクトには、エンベロープとコンテンツが含まれます。
  16. ^ 「メールオブジェクト」。シンプルメール転送プロトコル。IETF。sec . 2.3.1。doi : 10.17487 /RFC5321。RFC 5321。SMTPコンテンツはSMTP DATAプロトコルユニットで送信され、ヘッダーセクションと本体の2つの部分で構成されます。コンテンツが他の最新の標準に準拠している場合、ヘッダーセクションはヘッダーフィールドの集合であり、各フィールドはヘッダー名、コロン、およびデータで構成され、メッセージフォーマット仕様に従って構造化されます。
  17. ^ Tom Van Vleck. 「電子メールの歴史」. 2017年12月2日時点のオリジナルよりアーカイブ。2005年3月23日閲覧。
  18. ^ レイ・トムリンソン. 「最初のネットワークメール」. Openmap.bbn.com. 2006年5月6日時点のオリジナルよりアーカイブ。 2019年10月5日閲覧。
  19. ^ ガードナー, PC (1981). 「自動化されたオフィス環境のためのシステム」. IBM Systems Journal . 20 (3): 321– 345. doi :10.1147/sj.203.0321. ISSN  0018-8670; 「IBM100 - ネットワーク化されたビジネスプレイス」IBM 2020年8月2日。2020年8月2日時点のオリジナルよりアーカイブ。2020年9月7日閲覧。
  20. ^ コニー・ウィンクラー（1979年10月22日）「CompuServe、MicroNETとInfoPlexに期待」『Computerworld』第13巻第42号、69ページディラン・トゥエニー（1979年9月24日）「1979年9月24日：消費者向け初のオンラインサービスがスタート」Wired誌
  21. ^ Ollig, Mark (2011年10月31日). 「彼らはコンピュータ業界を所有できたかもしれない」. Herald Journal . 2021年2月27日時点のオリジナルよりアーカイブ。 2021年2月26日閲覧。「時代を先取りしたテクノロジー：ゼロックス社のシューティングスターコンピューター」ニューサイエンティスト誌、2012年2月15日。2022年4月18日時点のオリジナルよりアーカイブ。 2022年4月18日閲覧。; 「ゼロックス・スター」. toastytech.com . 2011年7月18日時点のオリジナルよりアーカイブ。2022年4月18日閲覧。
  22. ^ 「ALL-IN-1」. DIGITAL Computing Timeline . 1998年1月30日. 2017年1月3日時点のオリジナルよりアーカイブ。 2022年4月20日閲覧。
  23. ^ “HP Computer Museum”. 2016年9月9日時点のオリジナルよりアーカイブ。2016年11月10日閲覧。
  24. ^ 「NSFNETバックボーンサー​​ビスの廃止：時代の終焉の記録」2016年1月1日アーカイブ、Wayback Machine、スーザン・R・ハリス博士、エリーゼ・ゲリッチ、ConneXions、第10巻、第4号、1996年4月
  25. ^ Leiner, Barry M.; Cerf, Vinton G.; Clark, David D.; Kahn, Robert E.; Kleinrock, Leonard; Lynch, Daniel C.; Postel, Jon; Roberts, Larry G.; Wolf, Stephen (1999). 「インターネットの簡潔な歴史」. arXiv : cs/9901011 . Bibcode :1999cs......1011L. 2015年8月11日時点のオリジナルよりアーカイブ。
  26. ^ Rutter, Dorian (2005). 「多様性から収束へ：英国のコンピュータネットワークとインターネット、1970-1995年」(PDF) (コンピュータサイエンス論文). ウォーリック大学. 2022年10月10日時点のオリジナルよりアーカイブ(PDF) . 2022年12月23日閲覧。
  27. ^キャンベル＝ケリー 、マーティン；ガルシア＝シュワルツ、ダニエル・D（2013年）「インターネットの歴史：失われた物語」ジャーナル・オブ・インフォメーション・テクノロジー 、28 （ 1）：18–33。doi：10.1057/ jit.2013.4。ISSN 0268-3962。S2CID  41013。SSRN 867087  。
  28. ^ How E-mail Works. howstuffworks.com. 2008年。2017年6月11日時点のオリジナルよりアーカイブ。
  29. ^ 「MXレコードの説明」Wayback Machineで2015年1月17日にアーカイブ、it.cornell.edu
  30. ^ 「オープンリレーとは何か？」WhatIs.comインディアナ大学2004年7月19日. 2007年8月24日時点のオリジナルよりアーカイブ。2008年4月7日閲覧。
  31. ^ Ch Seetha Ram (2010). 経営のための情報技術. Deep & Deep Publications. p. 164. ISBN 978-81-8450-267-1。
  32. ^ Hoffman, Paul (2002年8月20日). 「SMTPにおけるリレーの許可：一連の調査」. IMCレポート. Internet Mail Consortium . 2007年1月18日時点のオリジナルよりアーカイブ。 2008年4月13日閲覧。
  33. ^ abc 「電子メールが瞬時に届かない理由、そしてそうあるべきではない理由」2013年10月15日。
  34. ^ インターネットメッセージ形式はネットワークニュースにも使用される
  35. ^ Simpson, Ken (2008年10月3日). 「電子メール標準のアップデート」MailChannelsブログ記事。2008年10月6日時点のオリジナルよりアーカイブ。
  36. ^ J. Klensin (2008年10月)、「メールオブジェクト」、Simple Mail Transfer Protocol、2.3.1節、doi : 10.17487/RFC5321、RFC 5321、SMTPはメールオブジェクトを転送します。メールオブジェクトには、エンベロープとコンテンツが含まれます。…SMTPコンテンツはSMTP DATAプロトコルユニットで送信され、ヘッダーセクションと本体の2つの部分で構成されます。
  37. ^ D. Crocker (2009年7月)、「メッセージデータ」、インターネットメールアーキテクチャ、第4.1節、doi : 10.17487/RFC5598、RFC 5598、メッセージは、トランジットハンドリングエンベロープとメッセージコンテンツで構成されます。エンベロープには、MHSで使用される情報が含まれています。コンテンツは、構造化されたヘッダーと本文に分かれています。
  38. ^ P. Resnick編 (2008年10月). インターネットメッセージフォーマット. IETFネットワークワーキンググループ. doi : 10.17487/RFC5322 . RFC 5322. ドラフト標準。RFC 2822 を廃止。RFC 4021 を更新。RFC 6854により更新。
  39. ^ K. Moore (1996年11月). MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. Network Working Group. doi : 10.17487/RFC2047 . RFC 2047. ドラフト標準。RFC 2184 および 2231 により更新。RFC 1590、1522、および 1521 は廃止。
  40. ^ A. Yang; S. Steele; N. Freed (2012年2月). 国際化された電子メールヘッダー.インターネット技術タスクフォース. doi : 10.17487/RFC6532 . ISSN  2070-1721. RFC 6532. 提案された標準。RFC 5335 を廃止します。RFC 2045 を更新します。
  41. ^ J. Yao; W. Mao (2012年2月). 国際化電子メールのためのSMTP拡張.インターネット技術タスクフォース. doi : 10.17487/RFC6531 . ISSN  2070-1721. RFC 6531. 提案された標準。RFC 5336 を廃止します。
  42. ^ 「今すぐヒンディー語でメールアドレスを取得しましょう - The Economic Times」The Economic Times . 2016年8月28日時点のオリジナルよりアーカイブ。 2016年10月17日閲覧。
  43. ^ Resnick, P. 編 (2008年10月). 「フィールド定義」. インターネットメッセージフォーマット. 3.6節. doi : 10.17487/RFC5322 . RFC 5322. 2014年1月9日閲覧.
  44. ^ Resnick, P. 編 (2008年10月). 「識別フィールド」. インターネットメッセージフォーマット. sec. 3.6.4. doi : 10.17487/RFC5322 . RFC 5322. 2014年1月9日閲覧.
  45. ^ M. Duerst (2007年12月). Archived-At メッセージヘッダーフィールド. ネットワークワーキンググループ. doi : 10.17487/RFC5064 . RFC 5064. 提案された標準。
  46. ^ Microsoft、Auto Response Suppress、2010年、Microsoftリファレンス、2011年4月7日アーカイブ、Wayback Machine、2010年9月22日
  47. ^ John Klensin (2008年10月). 「トレース情報」. Simple Mail Transfer Protocol. IETF . sec. 4.4. doi : 10.17487/RFC5321 . RFC 5321.
  48. ^ John Levine (2012年1月14日). 「トレースヘッダー」.電子メールメッセージ. IETF . 2012年8月11日時点のオリジナルよりアーカイブ. 2012年1月16日閲覧.これら2つのフィールド以外にも、多くのトレースフィールドが存在します。
  49. ^ この拡張フィールドはRFC  7001 で定義されており、電子メール認証パラメータのIANAレジストリも定義されています。
  50. ^ RFC  7208。
  51. ^ D. Crocker、T. Hansen、M. Kucherawy編（2011年9月）。DomainKeys Identified Mail（DKIM）署名。インターネット技術特別調査委員会。doi : 10.17487 / RFC6376。ISSN 2070-1721。RFC 6376  。 インターネット標準。RFC 8301、8463、8553、8616 により更新。RFC 4871 および 5672 は廃止。
  52. ^ RFC 3834で定義され 、RFC  5436 で更新されました。
  53. ^ RFC  5518。
  54. ^ Craig Hunt (2002). TCP/IPネットワーク管理. O'Reilly Media . p. 70. ISBN 978-0-596-00297-8。
  55. ^ “What is Unicode?”. Konfinity . 2022年1月31日時点のオリジナルよりアーカイブ。2022年1月31日閲覧。
  56. ^ 「ウイルスを防ぐ電子メールポリシー」Advosys Consulting . 2007年5月12日時点のオリジナルよりアーカイブ。
  57. ^ 「問題解決：プレーンテキストでメッセージを送信する」。RootsWebヘルプデスク。2014年2月19日時点のオリジナルからアーカイブ。2014年1月9日閲覧。RootsWebメーリングリストに投稿する際は、メッセージを「プレーンテキスト」で送信してください。
  58. ^ “OpenBSD メーリングリスト”. OpenBSD. 2014年2月8日時点のオリジナルよりアーカイブ。2014年1月9日閲覧。プレーンテキスト、1行72文字
  59. ^ “Verhindern, dass die Datei "Winmail.dat" an Internetbenutzer gesendet wird" [Winmail.dat ファイルがインターネット ユーザーに送信されるのを防ぐ方法]。マイクロソフトのサポート。 2010 年 7 月 2 日。2014 年 1 月 9 日のオリジナルからアーカイブ。2014 年1 月 9 日に取得。
  60. ^ 実際には、今日では受け入れられたメッセージの一部は受信者の受信箱に配信されず、特に企業環境では受信者がアクセスできないスパムまたは迷惑メールフォルダに配信される可能性があります。
  61. ^ 「未読メッセージのみを表示する」. support.microsoft.com . 2021年11月13日時点のオリジナルよりアーカイブ。 2021年11月13日閲覧。
  62. ^ 「Yahoo!ディレクトリの無料メールプロバイダー」dir.yahoo.com。2014年7月4日時点のオリジナルよりアーカイブ。
  63. ^ RFC 2368 セクション 3: 1998 年に Paul Hoffman によって、「mailto」URL の動作について説明されています。
  64. ^ ab ハンセン, デレク; スミス, マーク A.;ヒーア, ジェフリー(2011). 「Eメール」. バーネット, ジョージ A. (編). 『ソーシャルネットワーク百科事典』 . サウザンドオークス, カリフォルニア州: セージ, p. 245. ISBN 9781412994170. OCLC  959670912.
  65. ^ 「ハイパーリンクの作成 § 電子メールリンク」MDN Web Docs . 2019年8月18日時点のオリジナルよりアーカイブ。 2019年9月30日閲覧。
  66. ^ アレン、デイビッド (2004). Windows to Linux. プレンティス・ホール. p. 192. ISBN 978-1423902454. 2016年12月26日時点のオリジナルよりアーカイブ。
  67. ^ 「実装と運用」。IMAP4における分散型電子メールモデル。第4.5節。doi : 10.17487 / RFC1733。RFC 1733 。
  68. ^ 「メッセージストア（MS）」。インターネットメールアーキテクチャ。4.2.2節。doi : 10.17487 / RFC5598。RFC 5598。
  69. ^ Om Malik著、GigaOm。「電子メールは呪いなのか、恩恵なのか？ 」 Wayback Machineで2010年12月4日にアーカイブ。2010年10月11日閲覧。
  70. ^ Martin, Brett AS; Van Durme, Joel; Raulas, Mika; Merisavo, Marko (2003). 「Eメールマーケティング：フィンランドからの探究的洞察」（PDF） . Journal of Advertising Research . 43 (3): 293– 300. doi :10.1017/s0021849903030265. ISSN 0021-8499. 2012年10月21日時点のオリジナルより アーカイブ（PDF） .
  71. ^ Lev, Amir (2009年10月2日). 「スパム文化 パート1：中国」. 2016年11月10日時点のオリジナルよりアーカイブ。
  72. ^ “スマートフォンでの利用頻度はメールがトップ、ウェブブラウジングやFacebookを上回る [調査]”. 2013年3月28日. オリジナルより2014年4月29日時点のアーカイブ。
  73. ^ 「究極のモバイルメール統計概要」。2014年7月11日時点のオリジナルよりアーカイブ。
  74. ^ マット・リッチテル（2010年12月20日）「Eメールが瞬時に生まれ変わる」ニューヨーク・タイムズ。2018年4月5日時点のオリジナルよりアーカイブ。 2018年4月4日閲覧。
  75. ^ Gustini, Ray (2010年12月21日). 「なぜ若者はメールを放棄するのか？」 .アトランティック誌. 2018年4月5日時点のオリジナルよりアーカイブ。2018年4月4日閲覧。
  76. ^ Perez, Sarah (2016年3月24日). 「モバイル最年少ユーザーの間でメールが衰退」TechCrunch . 2018年4月5日時点のオリジナルよりアーカイブ。2018年4月4日閲覧。
  77. ^ Suneja, Bharat (2007年9月10日). 「Exchange 2010およびExchange 2007でメッセージサイズ制限を設定する」. Exchangepedia . 2013年2月12日時点のオリジナルよりアーカイブ。
  78. ^ Humphries, Matthew (2009年6月29日). 「Google、GmailとYouTubeのファイルサイズ制限を更新」Geek.com . 2011年12月19日時点のオリジナルよりアーカイブ。
  79. ^ 「添付ファイルの最大サイズ」、Gmailヘルプ。2011年10月15日アーカイブ、Wayback Machineにて。
  80. ^ Walther, Henrik (2009年1月). 「添付ファイルサイズの謎の増加、パブリックフォルダーの複製など」. TechNet Magazine . 2021年11月7日閲覧– Microsoft Docs経由.交換キュー＆A。
  81. ^ 「大きなファイルを他の人に送信する」2016年8月7日アーカイブ、Wayback Machine、Microsoft.com
  82. ^ 「大きな添付ファイルをメールで送信する8つの方法」2016年7月2日アーカイブ、Wayback Machine、Chris Hoffman、2012年12月21日、makeuseof.com
  83. ^ Radicati, Sara. 「Email Statistics Report, 2010」（PDF） . 2011年9月1日時点のオリジナルよりアーカイブ（PDF） 。
  84. ^ Gross, Doug (2010年10月20日). 「Happy Information Overload Day!」. CNN . 2015年10月23日時点のオリジナルよりアーカイブ。 2019年3月24日閲覧。
  85. ^ Stross, Randall (2008年4月20日). 「メール津波からの脱出に奮闘」.ニューヨーク・タイムズ. 2009年4月17日時点のオリジナルよりアーカイブ。 2010年5月1日閲覧。
  86. ^ 「スパムメールを見かけた？Googleアナリティクスのデータを管理する方法」sitepronews.com 2015年5月4日。2017年11月7日時点のオリジナルよりアーカイブ。2017年9月5日閲覧。
  87. ^ リッチ・カワナグ著「2005年スパムメールトップ10」ITVibeニュース、2006年1月2日、ITvibe.com 2008年7月20日アーカイブ、Wayback Machineより
  88. ^ マイクロソフトがスパムとの戦いに負けている理由 Salon.com 2008年6月29日アーカイブWayback Machine
  89. ^ 2003年スパム法案（PDF、2006年9月11日Wayback Machineにアーカイブ）
  90. ^ 「GoogleはAIがGmailのスパムメールの99.9%を検知している」Wayback Machineに2016年9月16日にアーカイブ、Cade Metz、2015年7月9日、wired.com
  91. ^ 「2016年第1四半期のスパムとフィッシング」Wayback Machineで2016年8月9日にアーカイブ、2016年5月12日、securelist.com
  92. ^ 「Kaspersky Lab スパムおよびフィッシングに関するレポート」2021年5月26日。2018年7月17日時点のオリジナルよりアーカイブ。2018年7月17日閲覧。
  93. ^ “2021 Email Usage Statistics”. 2021年10月5日. 2021年10月5日時点のオリジナルよりアーカイブ。2021年10月5日閲覧。
  94. ^ Waichulis, Arin (2024年4月5日). 「セキュリティ情報：iCloudメール、Gmail、その他、マルウェア検出能力が驚くほど低い、調査で判明」9to5Mac . 2024年5月27日閲覧。
  95. ^ 「メールの添付ファイルを開いても安全なのはいつですか？」Cloudflare . 2024年5月27日閲覧。
  96. ^ グリフィス、ジェームズ（2020年5月2日）「悪質なコードが書かれたコンピューターウイルスが数十億ドル規模の損害を引き起こした経緯｜CNN Business」CNN 2024年5月27日閲覧。
  97. ^ French, Laura (2024年5月14日). 「LockBitランサムウェア、Phorpiexボットネット経由で数百万通のメールで拡散」SC Media . 2024年5月27日閲覧。
  98. ^ SMEmail – モバイル環境での安全な電子メールのための新しいプロトコル、オーストラリア電気通信ネットワークおよびアプリケーション会議 (ATNAC'08) の議事録、pp. 39–44、オーストラリア、アデレード、2008 年 12 月。
  99. ^ 「電子メールのやり取りが拘束力のある契約となる場合」law.com . 2019年6月19日時点のオリジナルよりアーカイブ。 2019年12月6日閲覧。
  100. ^ カタリーナ・ジェシカ、フェイテル・ジェシー（2019年）「ニューヨーク州法における電子メールによる不注意による契約成立：最新情報」（PDF）シラキュース・ロー・レビュー、69ページ。
  101. ^ Corfield, Gareth (2019年9月30日). 「英国裁判所の判決、電子メール署名ブロックで拘束力のある契約に署名できると主張」The Register . 2019年10月17日時点のオリジナルよりアーカイブ。 2019年12月6日閲覧。
  102. ^ S. キースラー、D. ズブロウ、AM モーゼス、V. ゲラー (1985). 「コンピュータを介したコミュニケーションにおける感情：端末間同期ディスカッションの実験」『ヒューマン・コンピュータ・インタラクション』1 : 77–104 . doi :10.1207/s15327051hci0101_3.
  103. ^ バレット、グラント（2007年12月23日）「All We Are Saying」ニューヨーク・タイムズ。2009年4月17日時点のオリジナルよりアーカイブ。 2007年12月24日閲覧。
  104. ^ “Internationalized Domain Names (IDNs) | Registry.In”. registry.in . 2016年5月13日時点のオリジナルよりアーカイブ。 2016年10月17日閲覧。
  105. ^ “Made In India 'Datamail' Empowers Russia With Email Address In Russian Language - Digital Conqueror”. 2016年12月7日. 2017年3月5日時点のオリジナルよりアーカイブ。
  106. ^ RFC 3885、メッセージ追跡のためのSMTPサービス拡張
  107. ^ RFC 3888、メッセージ追跡モデルと要件
  108. ^ エイミー・ハーモン（2000年11月22日）「電子メールを追跡するソフトウェアがプライバシーへの懸念を高める」ニューヨーク・タイムズ。 2012年1月13日閲覧。
  109. ^ “About.com”. Email.about.com. 2013年12月19日. 2016年8月27日時点のオリジナルよりアーカイブ。 2014年1月9日閲覧。
  110. ^ 「Outlook: Web Bugs & Blocked HTML Images」 Wayback Machine 2015年2月18日アーカイブ、slipstick.com
  111. ^ 「Gmailがメールマーケティングを爆発させる…」2017年6月7日アーカイブ、 Ron Amadeo、2013年12月13日、Ars Technica

さらに読む

  • ジェミル・ベタノフ『X.400入門』、アーテックハウス、ISBN 0-89006-597-7。
  • マーシャ・イーガン、「受信箱のデトックスとメールの優秀さの習慣」、2016年5月20日アーカイブ、Wayback Machineにて、アカンサス出版ISBN 978-0-9815589-8-1
  • ローレンス・ヒューズ著『インターネット電子メールプロトコル、標準、実装』、アーテック・ハウス出版社、ISBN 0-89006-939-5。
  • ケビン・ジョンソン著『インターネット電子メールプロトコル：開発者ガイド』、Addison-Wesley Professional、ISBN 0-201-43288-9。
  • ピート・ロシン著『Email Standards: RFCとプロトコルの実用化』、John Wiley & Sons、ISBN 0-471-34597-0。
  • パートリッジ、クレイグ (2008年4～6月). 「インターネット電子メールの技術開発」(PDF) . IEEE Annals of the History of Computing . 30 (2): 3– 29. Bibcode :2008IAHC...30b...3P. doi :10.1109/mahc.2008.32. ISSN  1934-1547. S2CID  206442868. 2016年6月2日時点のオリジナル(PDF)からのアーカイブ。
  • サラ・ラディカティ著『電子メール：X.400メッセージ処理標準入門』 McGraw-Hill、ISBN 0-07-051104-7。
  • John Rhoton著『Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP』Elsevier、ISBN 1-55558-212-5。
  • John Rhoton著『X.400とSMTP：電子メールプロトコルの戦い』Elsevier、ISBN 1-55558-165-X。
  • デビッド・ウッド著『プログラミング・インターネット・メール』 O'Reilly、ISBN 1-56592-479-7。
無料辞書の Wiktionary で電子メール または送信トレイを調べます。
Wikiversityにはメールチェックリストに関する学習リソースがあります
  • IANAの標準ヘッダーフィールドのリスト
  • 「電子メールの歴史」は、電子メールの進化における一連の「重要な」出来事を記録しようとする Dave Crocker の試みであり、このページも引用されている共同作業です。
  • 電子メールの歴史は、初期の電子メールシステムの実装者による個人的な回想録です。
  • ネットワークメールの起源を探るは、重要な歴史的事実を簡潔かつ鮮明にまとめたものです。
  • ビジネスメール詐欺 - 新たな世界的脅威、FBI
  • 100以上のRFCを要約しようとした2021年の記事で、原理から説明されている。
Retrieved from "https://en.wikipedia.org/w/index.php?title=Email&oldid=1322711758"