Eメール

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

このスクリーンショットは、電子メールクライアントの「受信トレイ」ページを示していますユーザーは、新しい電子メールを表示して、これらのメッセージの読み取り、削除、保存、応答などのアクションを実行できます。
ウィキペディアの「ロボット」が画像ファイルに変更を加えると、アップローダーは行われた変更に関する電子メールを受け取ります。

電子メール電子メールまたは電子メール)は、電子デバイスを使用する人々の間でメッセージ(「メール」)を交換する方法です。したがって、電子メールは、「メール」が物理的なメール(したがって電子メール)のみを意味するときに、メールの電子デジタル)バージョンまたはそれに対応するものとして考えられていました電子メールは後にユビキタスな(非常に広く使用されている)通信媒体になり、現在使用されている電子メールアドレスは、ビジネス、商取引、政府、教育、娯楽、およびほとんどの国の日常生活の他の領域。電子メールは媒体であり、それとともに送信される各メッセージは電子メールと呼ばれます(質量/カウントの区別)。

電子メールの最初の開発は1960年代に始まりましたが、最初は、ユーザーは同じコンピューターの他のユーザーにのみ電子メールを送信できました。一部のシステムは、送信者と受信者が同時にオンラインである必要があるインスタントメッセージングの形式もサポートしていました。現代のインターネット電子メールサービスの歴史は、1973年に公開された電子メールメッセージをエンコードするための標準(RFC 561)を備えた初期のARPANETにまでさかのぼります。1970年代初頭に送信された電子メールメッセージは、今日送信された基本的な電子メールに似ています。 レイ・トムリンソンネットワーク化された電子メールの発明者としてクレジットされています。1971年に、彼はARPANET全体の異なるホスト上のユーザー間でメールを送信できる最初のシステムを開発しました。@記号を使用してユーザー名を宛先サーバーにリンクします。1970年代半ばまでに、これは電子メールとして認識されたフォームでした。ただし、当時、ほとんどのコンピューティングと同様に、電子メールは、エンジニアリングや科学などの特定の環境における「コンピューターオタク」向けのものでした。1980年代から1990年代にかけて、電子メールの使用は、経営管理、政府、大学、防衛/軍事業界の世界で一般的になりましたが、多くの人々はまだそれを使用していませんでした。Webブラウザの出現から始まります1990年代半ばに、電子メールの使用は一般の人々にも広がり始め、特定の職業や業界のオタクだけのものではなくなりました。2010年代までに、Webメール(Web時代の電子メール形式)はユビキタスな地位を獲得しました。

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

元々はASCIIテキストのみの通信媒体でしたが、インターネット電子メールは多目的インターネットメール拡張機能(MIME)によって拡張され、他の文字セットやマルチメディアコンテンツの添付ファイルでテキストを伝送していました。UTF-8を使用して国際化された電子メールアドレスを持つ国際的な電子メールは標準化されていますが、広く採用されていません。[2]

用語

電子メールサービスが普及する前は、ここではフランス語の「émail 」から派生した「 email 」という単語は、主にガラス質のエナメルまたは時にはセラミックの釉薬と呼ばれていました。まれな用語で、主に美術史家や中世主義者によって使用されました。

歴史的に、電子メールという用語は、電子文書の送信を意味します。たとえば、1970年代初頭の数人の作家は、この用語をファックス文書の送信を指すために使用していました。[3] [4]その結果、その最初の使用法を見つけることは、今日の特定の意味では困難です。

電子メールという用語は、少なくとも1975年から現在の意味で使用されており、短い電子メールのバリエーションは、少なくとも1979年から使用されています。[5] [6]

元のプロトコルであるRFC524では、これらの形式はいずれも使用されていませんでした。このサービスは単にメールと呼ばれ、1通の電子メールはメッセージと呼ばれます。

インターネット電子メールは、封筒と内容で構成されています。[21]コンテンツはヘッダーと本文で構成されています。[22]

1960年代初頭のタイムシェアリングコンピュータの出現により、コンピュータベースのメールとメッセージングが可能になり、共有ファイルを使用してメッセージを渡す非公式な方法がすぐに最初のメールシステムに拡張されました。初期のメインフレームとミニコンピューターのほとんどの開発者は、同様の、しかし一般的に互換性のないメールアプリケーションを開発しました。時間の経過とともに、ゲートウェイとルーティングシステムの複雑なWebがそれらの多くをリンクしました。多くの米国の大学は、システム間のソフトウェアの移植性を目的としたARPANET(1960年代後半に作成)の一部でした。1971年に、最初のARPANETネットワーク電子メールが送信され、ユーザーのシステムアドレスを示す「@」記号を使用して、今ではおなじみのアドレス構文が導入されました。[ 23]シンプルメール転送プロトコル(SMTP)プロトコルは1981年に導入されました。

1980年代後半から1990年代初頭にかけて、独自の商用システムか、Government Open Systems Interconnection Profile(GOSIP)の一部であるX.400電子メールシステムのいずれかが主流になる可能性がありました。[nb 1]ただし、インターネットを介した商用トラフィックの伝送に関する最終的な制限が1995年に終了すると、[24] [25]要因の組み合わせにより、SMTP、POP3、およびIMAP電子メールプロトコルの現在のインターネットスイートが標準になりました。

手術

以下は、送信者のアリスが受信者の電子メールアドレスにアドレス指定されたメールユーザーエージェント(MUA)を使用してメッセージを送信するときに発生するイベントの典型的なシーケンスです[26]

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

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

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

多くのMTAは、インターネット上の任意の受信者へのメッセージを受け入れ、それらを配信するために最善を尽くしていました。このようなMTAは、オープンメールリレーと呼ばれます。これは、ネットワーク接続が信頼できないインターネットの初期の頃には非常に重要でした。[28] [29]しかし、このメカニズムは迷惑メール の発信者によって悪用可能であることが証明され、その結果、オープンメールリレーはまれになり[30]、多くのMTAはオープンメールリレーからのメッセージを受け入れません。

メッセージ形式

電子メール[31]に使用される基本的なインターネットメッセージ形式はRFC5322で定義されており、非ASCIIデータとマルチメディアコンテンツの添付ファイルはRFC2045からRFC2049で定義されており、まとめて多目的インターネットメール拡張機能またはMIMEと呼ばれます。国際メールの拡張機能は、メールにのみ適用されます。RFC5322は2008年に以前のRFC2822に取って代わり、2001年のRFC2822はRFC822に取って代わりました。これは数十年にわたるインターネット電子メールの標準です。1982年に公開されたRFC822は、ARPANET用の以前のRFC733に基づいていました。[32]

インターネット電子メールメッセージは、「ヘッダー」と「本文」の2つのセクションで構成されています。これらは「コンテンツ」として知られています。[33] [34] ヘッダーは、From、To、CC、Subject、Date、および電子メールに関するその他の情報などのフィールドで構成されています。システム間で電子メールメッセージを転送するプロセスでは、SMTPはメッセージヘッダーフィールドを使用して配信パラメータと情報を伝達します。本文には、構造化されていないテキストとしてメッセージが含まれ、最後に署名ブロックが含まれることもあります。ヘッダーは本文から空白行で区切られます。

メッセージヘッダー

RFC 5322は、電子メールヘッダーの構文を指定しています。各電子メールメッセージには、いくつかのフィールド(「ヘッダーフィールド」)で構成されるヘッダー(仕様によると、メッセージの「ヘッダーセクション」)があります。各フィールドには、名前(「フィールド名」または「ヘッダーフィールド名」)、区切り文字「:」、および値(「フィールド本体」または「ヘッダーフィールド本体」)が続きます。

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

ヘッダーフィールド

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

メッセージヘッダーには、少なくとも次のフィールドが含まれている必要があります。[40] [41]

  • 差出人:電子メールアドレス、およびオプションで作成者の名前。一部の電子メールクライアントは、アカウント設定を通じて変更できます。
  • 日付:メッセージが書き込まれた現地の日時。From:フィールドと同様に、多くの電子メールクライアントは送信前にこれを自動的に入力します。受信者のクライアントは、ローカルの形式とタイムゾーンで時間を表示できます。

RFC 3864は、 IANAでのメッセージヘッダーフィールドの登録手順について説明していますMIME、netnews、およびHTTP用に定義されたフィールドを含む、永続的および暫定的なフィールド名を提供し、関連するRFCを参照します。電子メールの一般的なヘッダーフィールドは次のとおりです。[42]

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

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

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

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

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

  • 認証-結果:サーバーが認証を確認した後、ダウンストリームエージェントが使用できるように、このフィールドに結果を保存できます。[46]
  • Received-SPF : SPFチェックの結果をAuthentication-Resultsよりも詳細に保存します。[47]
  • DKIM-Signature : DomainKeys Identified Mail(DKIM)復号化の結果を保存して、メッセージが送信された後に変更されていないことを確認します。[48]
  • 自動送信:自動生成されたメッセージをマークするために使用されます。[49]
  • VBR-情報VBRホワイトリストの主張[50]

メッセージ本文

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

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

プレーンテキストとHTML

最新のグラフィック電子メールクライアントのほとんどは、ユーザーのオプションでメッセージ本文にプレーンテキストまたはHTMLのいずれかを使用できます。HTML電子メールメッセージには、互換性のために自動生成されたプレーンテキストのコピーが含まれていることがよくあります。HTMLの利点には、インラインリンクと画像を含める、前のメッセージをブロック引用符で区切る、任意のディスプレイで自然に折り返す、下線斜体などの強調を使用する、フォントスタイルを変更する機能があります。欠点には、電子メールのサイズの増加、 Webバグに関するプライバシーの懸念、フィッシングのベクトルとしてのHTML電子メールの悪用などがあります。攻撃と悪意のあるソフトウェアの拡散。[53]

Content-Type: html一部の電子メールクライアントは、ヘッダーフィールドがない場合でも本文をHTMLとして解釈します。これにより、さまざまな問題が発生する可能性があります。

一部のWebベースのメーリングリストでは、上記のすべての理由[54] [55]と、テキストベースの電子メールクライアントを使用するかなりのの読者がいるため、すべての投稿をプレーンテキストで作成することを推奨しています。 Muttなど一部のMicrosoft電子メールクライアントは、独自のリッチテキスト形式(RTF)を使用したリッチフォーマットを許可する場合がありますが、受信者が互換性のある電子メールクライアントを持っていることが保証されない限り、これは避ける必要があります。[56]

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

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

メッセージは、メール転送エージェント(MTA)と呼ばれるソフトウェアプログラムを備えたシンプルメール転送プロトコルを使用してホスト間で交換されます。メール配信エージェント(MDA、ローカル配信エージェント、LDAとも呼ばれる)と呼ばれるプログラムによってメールストアに配信されます。メッセージを受け入れると、MTAはメッセージを配信する必要があり[57]、メッセージを配信できない場合、そのMTAは問題を示すバウンスメッセージを送信者に返送する必要があります。

ユーザーは、 POPIMAPなどの標準プロトコルを使用して、または大企業環境でより可能性が高いように、Novell GroupwiseLotus Notes、またはMicrosoft ExchangeServerに固有の独自のプロトコルを使用してサーバーからメッセージを取得できますユーザーが電子メールの取得、読み取り、および管理に使用するプログラムは、メールユーザーエージェント(MUA)と呼ばれます。

電子メールを開くと、「既読」としてマークされます。これは通常、クライアントのユーザーインターフェイス上の「未読」メッセージと視覚的に区別されます。電子メールクライアントは、ユーザーが未読に集中できるように、受信トレイから既読の電子メールを非表示にすることを許可する場合があります。[58]

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

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

ファイル名拡張子

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

eml
Novell GroupWiseMicrosoft Outlook ExpressLotus notesWindows MailMozilla Thunderbird 、Postboxなどの多くの電子メールクライアントで使用されますファイルには、MIME形式のプレーンテキストとして電子メールの内容が含まれ、いくつかの形式の1つ以上の添付ファイルを含む電子メールのヘッダーと本文が含まれます。
emlx
AppleMailによって使用されます。
msg
Microsoft OfficeOutlookおよびOfficeLogicグループウェアで使用されます
mbx
mbox形式に基づいてOperaMailKMail、およびAppleMailで使用されます。

一部のアプリケーション(Apple Mailなど)は、添付ファイルの個別のコピーを保存しながら、検索用にメッセージにエンコードされた添付ファイルを残します。他の人は添付ファイルをメッセージから分離し、それらを特定のディレクトリに保存します。

URIスキームmailto

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

タイプ

Webベースの電子メール

多くの電子メールプロバイダーには、Webベースの電子メールクライアントがあります(AOL MailGmailOutlook.comYahoo!Mailなど)。これにより、ユーザーは互換性のあるWebブラウザーを使用して電子メールアカウントにログインし、電子メールを送受信できます。通常、メールはWebクライアントにダウンロードされないため、現在のインターネット接続がないと読み取ることができません。

POP3メールサーバー

Post Office Protocol 3(POP3)は、クライアントアプリケーションがメールサーバーからのメッセージを読み取るために使用するメールアクセスプロトコルです。受信したメッセージはサーバーから削除されることがよくありますPOPは、リモートメールボックス(POP RFCではメールドロップと呼ばれます)にアクセスするための単純なダウンロードと削除の要件をサポートしています。[63] POP3を使用すると、ローカルコンピュータに電子メールメッセージをダウンロードして、オフラインのときでも読むことができます。[64] [65]

IMAPメールサーバー

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

MAPIメールサーバー

メッセージングアプリケーションプログラミングインターフェイス(MAPI)は、MicrosoftOutlookがMicrosoftExchange Serverと通信するために使用します。また、 Axigen Mail ServerKerio ConnectScalixZimbraHP OpenMailIBM Lotus NotesZarafaなどの他のさまざまな電子メールサーバー製品とも通信しますBynariではベンダーがMAPIサポートを追加して、Outlookを介して自社の製品に直接アクセスできるようにしています。

用途

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

電子メールは、先進国の企業、政府、および非政府組織によって広く受け入れられており、職場のコミュニケーションにおける「e-革命」の重要な部分の1つです(他の重要な計画は高速インターネットの普及です) 。職場のコミュニケーションに関する2010年のスポンサー付き調査では、米国の知識労働者の83%が、仕事での成功と生産性にとって電子メールが重要であると感じていることがわかりました。[66]

これには、ビジネスやその他の組織にとって、次のようないくつかの重要な利点があります。

ロジスティクスの促進
ビジネスの世界の多くは、物理的に同じ建物、地域、さらには国にいない人々の間のコミュニケーションに依存しています。対面式の会議、電話、または電話会議の設定と参加は、不便で、時間と費用がかかる可能性があります。電子メールは、セットアップ費用なしで2人以上の人々の間で情報を交換する方法を提供し、それは一般に、物理的な会議や電話よりもはるかに安価です。
同期の支援
会議または電話によるリアルタイムのコミュニケーションでは、参加者は同じスケジュールで作業する必要があり、各参加者は会議または電話で同じ時間を費やす必要があります電子メールは非同期を許可します:各参加者は独立してスケジュールを制御できます。受信メールのバッチ処理は、通話の中断と比較してワークフローを改善できます。
コスト削減
電子メールの送信は、郵便、長距離電話テレックス電報の送信よりもはるかに安価です
速度を上げる
ほとんどの選択肢よりもはるかに高速です。
「書き込まれた」レコードの作成
電話や対面での会話とは異なり、電子メールはその性質上、通信、送信者と受信者のID、およびメッセージが送信された日時の詳細な書面による記録を作成します。契約や法的な紛争が発生した場合、保存された電子メールは、各電子メールに日付と時刻が記録されているため、個人が特定の問題について知らされたことを証明するために使用できます。
自動処理と配布の改善の可能性
同様に、顧客の注文の前処理および/または担当者への対応は、自動化された手順によって実現できます。

メールマーケティング

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

個人使用

パソコン

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

モバイル

電子メールは、スマートフォンやあらゆる種類のコンピューターで使用されるようになりました。メール用のモバイル「アプリ」は、家の外にいるユーザーのメディアへのアクセシビリティを向上させます。電子メールの初期の頃は、ユーザーはデスクトップコンピューターでしか電子メールにアクセスできませんでしたが、2010年代には、ユーザーは、町の外にいても世界中にいても、家から離れているときに電子メールを確認できます。アラートをスマートフォンやその他のデバイスに送信して、新しいメッセージをすぐに通知することもできます。これにより、電子メールはユーザー間のより頻繁なコミュニケーションに使用できるようになり、ユーザーは1日を通して電子メールをチェックしてメッセージを書くことができるようになりました。2011年の時点で、世界中で約14億の電子メールユーザーがおり、毎日500億の非スパム電子メールが送信されています。[61]

個人は、スマートフォンで個人的なメッセージと仕事関連のメッセージの両方についてメールをチェックすることがよくあります。米国の成人は、ウェブを閲覧したりFacebookアカウントをチェックしたりするよりもメールをチェックすることが多く、ユーザーがスマートフォンで行う最も人気のあるアクティビティはメールです。調査の回答者の78%は、電話でメールをチェックしていることを明らかにしました。[69]また、消費者の30%がスマートフォンのみを使用してメールをチェックし、91%がスマートフォンで少なくとも1日1回メールをチェックする可能性が高いことがわかりました。ただし、スマートフォンでメールを使用する消費者の割合はさまざまであり、国によって大きく異なります。たとえば、それを使用した米国の消費者の75%と比較して、インドでは17%しか使用していません。[70]

若者の間での使用の減少

2010年の時点で、電子メールWebサイトにアクセスするアメリカ人の数は2009年11月にピークに達した後6%減少しました。12〜17人の場合、その数は18%減少しました。若い人たちは、インスタントメッセージングテキストメッセージソーシャルメディアを好みました。テクニカルライターのマット・リッチテル氏は、ニューヨークタイムズ紙で、電子メールはVCRビニールレコードフィルムカメラのようなものであり、もはやクールではなく、高齢者が行うことだと述べています。[71] [72]

2015年のAndroidユーザーの調査によると、13〜24人がメッセージングアプリを45歳以上の3.5倍使用しており、メールを使用する可能性ははるかに低いことがわかりました。[73]

問題

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

電子メールメッセージには、電子メールに追加される追加ファイルである1つ以上の添付ファイルが含まれる場合があります。一般的な添付ファイルには、Microsoft Wordドキュメント、PDFドキュメント、紙のドキュメントのスキャン画像が含まれます。原則として、添付ファイルのサイズや数に技術的な制限はありません。ただし、実際には、電子メールクライアント、サーバー、およびインターネットサービスプロバイダーは、ファイルまたは完全な電子メールのサイズにさまざまな制限を実装します(通常は25MB以下)。[74] [75] [76]さらに、技術的な理由により、これらの輸送システムから見たアタッチメントのサイズは、ユーザーが見たものとは異なる場合があります[77]。これは、送信者がファイルを電子メールで安全に送信できるかどうかを評価しようとすると、送信者を混乱させる可能性があります。より大きなファイルを共有する必要がある場合は、さまざまなファイルホスティングサービスが利用可能であり、一般的に使用されています。[78] [79]

情報過多

知識労働者と「ホワイトカラー」の従業員のための電子メールの遍在性は、受信者が電子メールの量の増加に対処する際に「情報過多」に直面するという懸念につながっています。[80] [81]モバイルデバイスの成長に伴い、デフォルトでは、従業員は勤務時間外に仕事関連の電子メールを受信する場合があります。これはストレスの増加と仕事への満足度の低下につながる可能性があります。多くの電子メールを読む努力は生産性を低下させる可能性があるため、一部のオブザーバーは、それが重大な経済的悪影響をもたらす可能性があるとさえ主張しています[82]

スパム

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

マルウェア

さまざまな種類の悪意のある電子メールが存在します。これらは、前払い詐欺「ナイジェリアの手紙」などの「ソーシャルエンジニアリング」詐欺を含むさまざまな種類の電子メール詐欺から、フィッシング電子メール爆撃電子メールワームにまで及びます。

メールのなりすまし

電子メールのなりすましは、メッセージが既知または信頼できる送信元から送信されたように見えるように電子メールメッセージヘッダーが設計されている場合に発生します。電子メールスパムおよびフィッシング方法は通常、なりすましを使用して、実際のメッセージの発信元について受信者を誤解させます。電子メールのなりすましは、いたずらとして、または個人や組織を欺くための犯罪行為の一部として行われる可能性があります。詐欺の可能性のある電子メールのなりすましの例は、ある個人が大手企業からの請求書のように見える電子メールを作成し、それを1人以上の受信者に送信する場合です。場合によっては、これらの不正な電子メールには、組織と称されるロゴが組み込まれており、電子メールアドレスでさえ正当に見える場合があります。

メールボム

電子メール爆撃は、ターゲットアドレスに大量のメッセージを意図的に送信することです。ターゲットの電子メールアドレスが過負荷になると、使用できなくなり、メールサーバーがクラッシュする可能性もあります。

プライバシーの問題

今日では、インターネットと内部の電子メールシステムを区別することが重要になる可能性があります。インターネット電子メールは、送信者または受信者の制御なしに、ネットワークやコンピュータに移動して保存される場合があります。通過時間中に、第三者がコンテンツを読んだり、変更したりする可能性があります。情報が組織のネットワークを離れることがない内部メールシステムは、より安全である可能性がありますが、監視または管理を伴う機能を持つ 情報技術担当者やその他の人は、他の従業員の電子メールにアクセスする可能性があります。

いくつかのセキュリティ対策なしで、電子メールのプライバシーは、次の理由で危険にさらされる可能性があります。

  • 電子メールメッセージは通常暗号化されていません。
  • 電子メールメッセージは、宛先に到達する前に中間コンピュータを通過する必要があります。つまり、他の人がメッセージを傍受して読むのは比較的簡単です。
  • 多くのインターネットサービスプロバイダー(ISP)は、電子メールメッセージのコピーを配信前にメールサーバーに保存しています。これらのバックアップは、メールボックスから削除されても、サーバー上に最大数か月間残る可能性があります。
  • 「Received:」-電子メールのフィールドやその他の情報は、多くの場合、送信者を識別し、匿名の通信を妨げる可能性があります。
  • HTMLコンテンツに目に見えない形で埋め込まれたWebバグは、電子メールがHTMLとしてレンダリングされるたびに(一部の電子メールクライアントは、ユーザーが電子メールを読んだり、再読したりするときにこれを行います)、どのIPアドレスからの電子メールの送信者に警告することができます。また、ユーザーエージェント文字列を介して、電子メールがスマートフォン、PC、またはAppleMacデバイスで読み取られたかどうかを明らかにすることもできます

上記の1つまたは複数の解決策として役立つ暗号化アプリケーションがあります。たとえば、仮想プライベートネットワークまたはTorネットワークを使用して、ユーザーマシンからより安全なネットワークへのトラフィックを暗号化できます。一方、GPGPGP、SMEmail、[91]、またはS / MIMEを使用して、エンドツーエンドのメッセージ暗号化を行うことができます。 SMTPSTARTTLSまたはSMTPover Transport Layer Security / Secure Sockets Layerを使用して、SMTPクライアントとSMTPサーバー間の単一のメールホップの通信を暗号化できます。

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

法的契約

電子メールの交換によって拘束力のある契約が結ばれる可能性があるため、ユーザーは電子メールの通信を通じて送信する内容に注意する必要があります。[92] [93]電子メールの署名ブロックは、契約の署名要件を満たしていると解釈される場合があります。[94]

炎上

炎上は、人が怒りや敵対的な内容のメッセージ(または多くのメッセージ)を送信したときに発生します。この用語は、特に熱狂的な電子メールの議論を説明するために焼夷という言葉を使用することに由来しています。電子メール通信の容易さと非人格性は、直接または電話で礼儀正しさを奨励する社会的規範が存在せず、礼儀正しさが忘れられる可能性があることを意味します。[95]

メールの破産

「電子メールの疲労」とも呼ばれる電子メールの破損とは、ユーザーが大量の電子メールメッセージを読んだり、返信したりするのに遅れをとった後、それらを無視することです。遅れる理由は、情報過多が原因であることが多く、一般的には情報が多すぎてすべてを読むことができないためです。解決策として、メールの受信トレイがいっぱいで、すべてのメッセージを消去していることを説明する「定型文」メッセージを送信することがあります。ハーバード大学のローレンス・レッシグ教授は、この用語の造語でクレジットされていますが、彼はそれを普及させただけかもしれません。[96]

国際化

もともとインターネットの電子メールは完全にASCIIテキストベースでした。MIMEでは、本文コンテンツテキストと一部のヘッダーコンテンツテキストを国際文字セットで使用できるようになりましたが、UTF-8を使用する他のヘッダーと電子メールアドレスは、標準化された[97]まだ広く採用されていません。[2] [98]

送信されたメールの追跡

元のSMTPメールサービスは、送信されたメッセージを追跡するための限定されたメカニズムを提供し、メッセージが配信または読み取られたことを確認するためのメカニズムは提供しません。各メールサーバーはそれを先に配信するか、障害通知(バウンスメッセージ)を返す必要がありますが、ソフトウェアのバグとシステム障害の両方が原因でメッセージが失われる可能性があります。これを改善するために、IETF配信ステータス通知(配信レシート)とメッセージ処理通知(返品レシート)を導入しました。ただし、これらは本番環境で普遍的に展開されているわけではありません。[nb 3]

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

  • 配信レポートを使用して、アドレスが存在するかどうかを確認できます。存在する場合は、スパム送信可能であることをスパマーに示します。
  • スパマーが偽造された送信者の電子メールアドレス(電子メールスプーフィング)を使用する場合、使用された無実の電子メールアドレスは、スパマーがメールを送信しようとした可能性のある多くの無効な電子メールアドレスからのNDRで溢れる可能性があります。これらのNDRは、ISPから無実のユーザーへのスパムを構成します。

標準的な方法がないため、 Webバグの使用に基づいたさまざまなシステムが開発されています。ただし、これらはしばしば手に負えない、またはプライバシーの懸念を引き起こしていると見なされ[101] [102]、HTMLのレンダリングをサポートする電子メールクライアントでのみ機能します。現在、多くのメールクライアントはデフォルトで「Webコンテンツ」を表示していません。[103] Webメールプロバイダーは、画像を事前にキャッシュすることでWebバグを混乱させることもできます。[104]

も参照してください

ノート

  1. ^ プロトコル戦争を参照してください
  2. ^ 国際化された電子メールまたはMIMEを使用しない
  3. ^ 完全なメッセージ追跡メカニズムも定義されましたが、それは決して牽引力を獲得しませんでした。RFC 3885 [99]から3888を参照してください。[100]

参考文献

  1. ^ 「RFC5321– Simple MailTransferProtocol」ネットワークワーキンググループ2015年1月16日にオリジナルからアーカイブされました2015年1月19日取得
  2. ^ a b "DataMail:世界初の無料の言語メールサービスは8つのインド言語をサポートしています"2016年10月22日にオリジナルからアーカイブされました。
  3. ^ ブラウン、ロン(1972年10月26日)。「ファックスはメール市場に侵入します」ニューサイエンティスト56、いいえ。817.イギリス、ロンドン:New Scientist Ltd. pp。218–221。2016年5月9日にオリジナルからアーカイブされました。
  4. ^ ラケット、ハーバートP.(1973年3月)。「ニュース:電子メール配信開始」ポピュラーサイエンス202、いいえ。3.アイオワ州ハーラン:ボニアコーポレーションp。85. 2016年4月30日のオリジナルからアーカイブ。
  5. ^ 「1979年より前の電子メール名詞」オックスフォード英語辞典2012年10月25日2020年5月14日取得
  6. ^ Ohlheiser、Abby(2015年7月28日)。「なぜ「電子メール」という単語の最初の使用が永久に失われる可能性があるのか​​」ワシントンポスト2020年5月14日取得
  7. ^ 「Yahooスタイルガイド」Styleguide.yahoo.com。2013年5月9日にオリジナルからアーカイブされました2014年1月9日取得
  8. ^ a b "APはスタイルガイドの「Eメール」からハイフンを削除します"ハフィントンポストニューヨーク市。2011年3月18日。2015年5月12日のオリジナルからアーカイブ。
  9. ^ 「RFCエディタ用語リスト」IETF。2013年12月28日にオリジナルからアーカイブされました。これは、WaybackMachineで2015年4月24日にアーカイブされたRFCドキュメントスタイルガイドによって提案されています。
  10. ^ AskOxford言語クエリチーム。「「email」、「ecommerce」、「egovernment」などの「e」の単語を綴る正しい方法は何ですか?」FAQオックスフォード大学出版局2008年7月1日にオリジナルからアーカイブされました2009年9月4日取得メールをお勧めします。これは一般的なフォームです
  11. ^ 「Reference.com」Dictionary.reference.com。2013年12月16日にオリジナルからアーカイブされました2014年1月9日取得
  12. ^ Random House Unabridged Dictionary、2006
  13. ^ 英語のアメリカヘリテッジ辞書、第4版
  14. ^ プリンストン大学WordNet3.0
  15. ^ アメリカの遺産科学辞書、2002年
  16. ^ 「メリアム-ウェブスター辞書」メリアム・ウェブスター2014年5月12日にオリジナルからアーカイブされました2014年5月9日取得
  17. ^ "「Eメール」または「Eメール」"英語と使用法– StackExchange。2010年8月25日。2010年8月31日のオリジナルからアーカイブ。20109月26日取得
  18. ^ Gerri Berendzen ; ダニエルハント。「APは電子メールを電子メールに変更します」アメリカコピー編集者協会の第15回全国会議(2011年、フェニックス)ACES。2011年3月22日にオリジナルからアーカイブされました2011年3月23日取得
  19. ^ 「RFCスタイルガイド」、RFCでの一貫した使用に関する決定の表」2013年12月28日にオリジナルからアーカイブされました2014年1月9日取得
  20. ^ 「Usenetニュースグループalt.usage.englishのFAQリストからの抜粋」Alt-usage-english.org。2012年4月3日にオリジナルからアーカイブされました2014年1月9日取得
  21. ^ 「メールオブジェクト」Simple Mail TransferProtocolIETF2.3.1。土井10.17487 / RFC5321RFC5321_ SMTPはメールオブジェクトを転送します。メールオブジェクトには、エンベロープとコンテンツが含まれています。
  22. ^ 「メールオブジェクト」Simple Mail TransferProtocolIETF2.3.1。土井10.17487 / RFC5321RFC5321_ SMTPコンテンツはSMTPDATAプロトコルユニットで送信され、ヘッダーセクションと本文の2つの部分で構成されます。コンテンツが他の最新の標準に準拠している場合、ヘッダーセクションはヘッダーフィールドのコレクションであり、各ヘッダーフィールドは、メッセージ形式の仕様のように構造化された、ヘッダー名、コロン、およびデータで構成されます。
  23. ^ レイ・トムリンソン。「最初のネットワークメール」Openmap.bbn.com。2006年5月6日にオリジナルからアーカイブされました2019年10月5日取得
  24. ^ 「NSFNETバックボーンサー​​ビスの廃止:時代の終わりを記録する」 2016年1月1日 Wayback Machine、Susan R. Harris、Ph.D。、およびElise Gerich、 ConneXions、Vol。10、No。4、1996年4月
  25. ^ Leiner、Barry M。; サーフ、ヴィントンG。; クラーク、デビッドD。; カーン、ロバートE。; クラインロック、レナード; リンチ、ダニエルC。; ポステル、ジョン; ロバーツ、ラリーG。; ウルフ、スティーブン(1999)。「インターネットの簡単な歴史」arXivcs / 9901011Bibcode1999cs ........ 1011L2015年8月11日にオリジナルからアーカイブされました。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  26. ^ 電子メールのしくみhowstuffworks.com。2008年。2017年6月11日のオリジナルからアーカイブ。
  27. ^ 「MXレコードの説明」 は2015年1月17日にウェイバックマシンでアーカイブされました、it.cornell.edu
  28. ^ 「オープンリレーとは何ですか?」WhatIs.comインディアナ大学2004年7月19日。2007年8月24日のオリジナルからアーカイブ2008年4月7日取得
  29. ^ Ch Seetha Ram(2010)。管理のための情報技術ディープ&ディープパブリケーション。p。164. ISBN 978-81-8450-267-1
  30. ^ ホフマン、ポール(2002年8月20日)。「SMTPでの中継の許可:一連の調査」IMCレポートインターネットメールコンソーシアム2007年1月18日にオリジナルからアーカイブされました2008年4月13日取得
  31. ^ インターネットメッセージ形式はネットワークニュースにも使用されます
  32. ^ シンプソン、ケン(2008年10月3日)。「電子メール標準の更新」MailChannelsブログエントリ。2008年10月6日にオリジナルからアーカイブされました。
  33. ^ J. Klensin(2008年10月)、「メールオブジェクト」Simple Mail Transfer Protocol、秒。2.3.1。、doi10.17487 / RFC5321RFC 5321SMTPはメールオブジェクトを転送します。メールオブジェクトには、エンベロープとコンテンツが含まれています。... SMTPコンテンツはSMTPDATAプロトコルユニットで送信され、ヘッダーセクションと本文の2つの部分で構成されます。
  34. ^ D. Crocker(2009年7月)、「メッセージデータ」インターネットメールアーキテクチャ、秒。4.1。、doi10.17487 / RFC5598RFC 5598メッセージは、トランジット処理エンベロープとメッセージコンテンツで構成されます。封筒には、MHSが使用する情報が含まれています。コンテンツは、構造化されたヘッダーと本文に分けられます。
  35. ^ P. Resnick、Ed。(2008年10月)。「RFC5322、インターネットメッセージフォーマット」IETF。2015年2月22日にオリジナルからアーカイブされました。
  36. ^ Moore、K(1996年11月)。「MIME(多目的インターネットメール拡張機能)パート3:非ASCIIテキストのメッセージヘッダー拡張機能」IETF2012年1月14日にオリジナルからアーカイブされました2012年1月21日取得
  37. ^ ヤン、エド。(2012年2月)。「RFC6532、国際化された電子メールヘッダー」Ietf Request for Comments(RFC)ページ-テストIETF。ISSN2070-1721_ 2015年2月18日にオリジナルからアーカイブされました。 
  38. ^ J. Yao、Ed。、W。Mao、Ed。(2012年2月)。「RFC6531、国際化された電子メールアドレスのためのSMTP拡張」Ietf Request for Comments(RFC)ページ-テストIETF。ISSN2070-1721_ 2015年2月18日にオリジナルからアーカイブされました。 {{cite journal}}:CS1 maint:複数の名前:著者リスト(リンク
  39. ^ 「さあ、ヒンディー語であなたのメールアドレスを取得してください-TheEconomicTimes」エコノミックタイムズ2016年8月28日にオリジナルからアーカイブされました2016年10月17日取得
  40. ^ Resnick、Pete(2008年10月)。「RFC5322、3.6。フィールド定義」Tools.ietf.org。2013年12月30日にオリジナルからアーカイブされました2014年1月9日取得
  41. ^ Resnick、Pete(2008年10月)。「RFC5322、3.6.4。識別フィールド」Tools.ietf.org。2013年12月30日にオリジナルからアーカイブされました2014年1月9日取得
  42. ^ Dürst、Martin J.(2007年12月)。「RFC5064」Tools.ietf.org。2014年7月25日にオリジナルからアーカイブされました2014年1月9日取得
  43. ^ Microsoft、Auto Response Suppress、2010、 Microsoftリファレンス アーカイブ2011-04-07、 Wayback Machine、2010年9月22日
  44. ^ ジョンクレンシン(2008年10月)。「トレース情報」Simple Mail TransferProtocolIETF4.4。土井10.17487 / RFC5321RFC5321_
  45. ^ John Levine(2012年1月14日)。「トレースヘッダー」メールメッセージIETF2012年8月11日にオリジナルからアーカイブされました2012年1月16日取得これらの2つよりもはるかに多くのトレースフィールドがあります
  46. ^ この拡張可能なフィールドはRFC7001で定義されており、 Eメール認証パラメータのIANAレジストリ
  47. ^ RFC7208。
  48. ^ 「RFC6376」2020年1月28日取得
  49. ^ RFC 3834で定義され、RFC5436によって更新されました。
  50. ^ RFC5518。
  51. ^ クレイグハント(2002)。TCP / IPネットワーク管理オライリーメディアp。70. ISBN 978-0-596-00297-8
  52. ^ 「ユニコードとは何ですか?| Konfinity」www.konfinity.com 2022年1月31日取得
  53. ^ 「ウイルスを防ぐ電子メールの方針」2007年5月12日にオリジナルからアーカイブされました。{{cite web}}:CS1 maint:bot:元のURLステータスが不明(リンク
  54. ^ 「RootsWebメーリングリストに投稿するとき...」 Helpdesk.rootsweb.com。2014年2月19日にオリジナルからアーカイブされました2014年1月9日取得
  55. ^ 「...プレーンテキスト、1行あたり72文字...」 Openbsd.org。2014年2月8日にオリジナルからアーカイブされました2014年1月9日取得
  56. ^ 「Winmail.datファイルがインターネットユーザーに送信されないようにする方法」Support.microsoft.com。2010年7月2日。2014年1月9日のオリジナルからアーカイブ2014年1月9日取得
  57. ^ 実際には、受け入れられたメッセージの一部は、現在、受信者のInBoxに配信されず、代わりに、特に企業環境では受信者がアクセスできないスパムまたはジャンクフォルダに配信される場合があります。
  58. ^ 「未読メッセージのみを表示する」support.microsoft.com
  59. ^ 「Yahoo!ディレクトリの無料の電子メールプロバイダー」dir.yahoo.com2014年7月4日にオリジナルからアーカイブされました。
  60. ^ RFC 2368セクション3:1998年のPaul Hoffmanによる、「mailto」URLの操作について説明しています。
  61. ^ a b ハンセン、デレク; スミス、マークA。; ヘール、ジェフリー(2011)。「Eメール」バーネットでは、ジョージA(編)。ソーシャルネットワークの百科事典サウザンドオークス、カリフォルニア州:セージ。p。245. ISBN 9781412994170OCLC959670912 _
  62. ^ 「ハイパーリンクの作成§電子メールリンク」MDN WebDocs 2019年9月30日取得
  63. ^ アレン、デビッド(2004)。WindowsからLinuxへプレンティスホール。p。192. ISBN 978-14239024542016年12月26日にオリジナルからアーカイブされました。
  64. ^ 「実装と操作」IMAP4の分散型電子メールモデル4.5。土井10.17487 / RFC1733RFC1733_
  65. ^ 「メッセージストア(MS)」インターネットメールアーキテクチャ4.2.2。土井10.17487 / RFC5598RFC5598_
  66. ^ Om Malik、GigaOmによる。電子メールは呪いですか、それとも恩恵ですか? ウェイバックマシンで2010年12月4日にアーカイブされました」2010年9月22日。2010年10月11日取得。
  67. ^ マーティン、ブレットAS; Van Durme、Joel; ラウラス、ミカ; メリサボ、マルコ(2003)。「Eメールマーケティング:フィンランドからの探索的洞察」(PDF)広告調査ジャーナル43(3):293–300。土井10.1017 / s00218499030302652012年10月21日のオリジナルからアーカイブ(PDF) 。
  68. ^ Lev、Amir(2009年10月2日)。「スパム文化、パート1:中国」2016年11月10日にオリジナルからアーカイブされました。
  69. ^ 「電子メールはスマートフォンのトップアクティビティであり、WebブラウジングとFacebook [調査]に先んじています」2013年3月28日。2014年4月29日のオリジナルからアーカイブ。
  70. ^ 「究極のモバイルメール統計の概要」2014年7月11日にオリジナルからアーカイブされました。
  71. ^ リッチテル、マット(2010年12月20日)。「電子メールは即座に変身します」ニューヨークタイムズ2018年4月4日取得
  72. ^ Gustini、Ray(2010年12月21日)。「なぜ若者は電子メールを放棄するのですか?」大西洋2018年4月4日取得
  73. ^ ペレス、サラ(2016年3月24日)。「電子メールはモバイルの最年少ユーザーの間で死にかけている」techcrunch.com 2018年4月4日取得
  74. ^ 「Exchange2010およびExchange2007でのメッセージサイズ制限の設定」 WaybackMachineで2013-02-12にアーカイブされました。
  75. ^ 「GoogleはGmailとYouTubeのファイルサイズ制限を更新します」、geek.comはWaybackMachineで 2011年12月19日にアーカイブされました。
  76. ^ 「最大添付ファイルサイズ」、mail.google.com
  77. ^ Walther、Henrik(2009年1月)。「不思議な添付ファイルのサイズの増加、パブリックフォルダの複製など」ExchangeキューとA。TechNetマガジン2021年11月7日取得– MicrosoftDocs経由 {{cite magazine}}:(ヘルプ外部リンク|department=
  78. ^ 「他の人に大きなファイルを送信する」 2016年8月7日、Microsoft.comのWaybackMachineにアーカイブ
  79. ^ 「大きな添付ファイルを電子メールで送信する8つの方法」 WaybackMachine2016年7月2日にアーカイブ、Chris Hoffman、2012年12月21日、makeuseof.com
  80. ^ ラディカティ、サラ。「Eメール統計レポート、2010年」(PDF)2011年9月1日のオリジナルからアーカイブ(PDF) 。
  81. ^ グロス、ダグ(2010年10月20日)。「ハッピー情報過多の日!」CNN2015年10月23日にオリジナルからアーカイブされました2019年3月24日取得
  82. ^ Stross、Randall(2008年4月20日)。「電子メール津波を回避するのに苦労している」ニューヨークタイムズ2009年4月17日にオリジナルからアーカイブされました2010年5月1日取得
  83. ^ 「スパムを見る?あなたのGoogleAnalyticsデータの世話をする方法」sitepronews.com2015年5月4日。2017年11月7日のオリジナルからアーカイブ2017年9月5日取得
  84. ^ リッチカワナ。2005年のトップ10の電子メールスパムリスト。ITVibeニュース、2006年1月2日、 ITvibe.comは WaybackMachineで2008年7月20日にアーカイブされました
  85. ^ マイクロソフトがスパムSalon.com で戦争に負けている方法2008年6月29日ウェイバックマシンでアーカイブ
  86. ^ Spam Bill 2003( PDFは Wayback Machineで2006-09-11に
  87. ^ 「GoogleはAIがGmailスパムの99.9%をキャッチすると言っています」 2016年9月16日、 Wayback Machine、Cade Metz、2015年7月9日、wired.comでアーカイブ
  88. ^ 「2016年第1四半期のスパムとフィッシング」2016年 8月9日、 Wayback Machineでアーカイブ、2016年5月12日、securelist.com
  89. ^ 「カスペルスキーのスパムおよびフィッシングレポート」2021年5月26日。
  90. ^ 「2021電子メール使用統計」2021年10月5日。
  91. ^ SMEmail –モバイル環境での安全な電子メールの新しいプロトコル、オーストラリア電気通信ネットワークおよびアプリケーション会議(ATNAC'08)の議事録、39〜44ページ、オーストラリア、アデレード、2008年12月。
  92. ^ 「電子メール交換が拘束力のある契約になるとき」law.com
  93. ^ カタリーナ、ジェシカ; フェイテル、ジェシー(2019)。「ニューヨーク法の下での電子メールによる不注意な契約形成:最新情報」。シラキュース法のレビュー69
  94. ^ コーフィールド、ガレス。「英国の裁判所の判決は、電子メールの署名ブロックが拘束力のある契約に署名できると述べています」レジスター2019年12月6日取得
  95. ^ S。キースラー; D.ズブロウ; AMモーセ; V.ゲラー(1985)。「コンピュータを介したコミュニケーションへの影響:端末間の同期ディスカッションの実験」。人間とコンピュータの相互作用1:77〜104。土井10.1207 / s15327051hci0101_3
  96. ^ バレット、グラント(2007年12月23日)。「私たちが言っていることすべて」ニューヨークタイムズ2009年4月17日にオリジナルからアーカイブされました2007年12月24日取得
  97. ^ 「国際化ドメイン名(IDN)| Registry.In」Registry.in2016年5月13日にオリジナルからアーカイブされました2016年10月17日取得
  98. ^ 「MadeInIndia'Datamail 'は、ロシア語の電子メールアドレスでロシアに力を与える-デジタル征服者」2016年12月7日。2017年3月5日のオリジナルからアーカイブ。
  99. ^ RFC 3885、メッセージ追跡のためのSMTPサービス拡張
  100. ^ RFC 3888、メッセージ追跡モデルと要件
  101. ^ エイミーハーモン(2000年11月22日)。「電子メールを追跡するソフトウェアはプライバシーの懸念を引き起こしています」ニューヨークタイムズ2012年1月13日取得
  102. ^ 「About.com」Email.about.com。2013年12月19日。2016年8月27日のオリジナルからアーカイブ2014年1月9日取得
  103. ^ 「Outlook:WebバグとブロックされたHTML画像」 2015年2月18日、 Wayback Machine、slipstick.comにアーカイブ
  104. ^ 「Gmailは電子メールマーケティングを爆破します...」 WaybackMachineで2017年6月7日にアーカイブされました。RonAmadeo、2013年12月13日、Ars Technica

参考文献

外部リンク