Loading article…
電子メール クライアント、電子メール リーダー、または正式にはメッセージ ユーザー エージェント(MUA) またはメール ユーザー エージェントは、ユーザーの電子メールにアクセスして管理するために使用されるコンピュータ プログラムです。
メッセージの管理、作成、受信機能を提供する Web アプリケーションは、 Web 電子メール クライアント として機能する場合があり、電子メールクライアントとして機能することが主な役割または最も目立った役割であるコンピューター ハードウェアまたはソフトウェアも、この用語を使用する場合があります。
メールボックスからメッセージを取得する
ほとんどのクライアント プログラムと同様に、電子メール クライアントはユーザーが実行したときにのみアクティブになります。一般的な取り決めは、電子メール ユーザー (クライアント) がリモートのメール転送エージェント (MTA) サーバーと取り決めを行い、クライアントの電子メールの受信と保存を行います。MTA は、適切なメール配信エージェント(MDA) を使用して、電子メール メッセージが到着するとクライアントのストレージに追加します。リモート メール ストレージは、ユーザーのメールボックスと呼ばれます。多くの Unix システムのデフォルト設定では、メール サーバーは、ユーザーのホーム ディレクトリ内のmboxにフォーマットされたメッセージを保存します。もちろん、システムのユーザーは、メールボックスをホストしている同じコンピューターにログインしてメール クライアントを実行することができます。その場合、サーバーは、一般的な意味を除いて、 実際にはリモートではありません。
電子メールは、ユーザーの電子メール クライアントがユーザーのコンピュータにダウンロードするように要求するか、リモート サーバー上のユーザーのメールボックスにアクセスするまで、リモート サーバー上のユーザーのメールボックスに保存されます。電子メール クライアントは、複数のメールボックスに同時に接続して、事前に設定された間隔などで自動的に電子メールのダウンロードを要求するように設定することも、ユーザーが手動で要求するように設定することもできます。
ユーザーのメールボックスには、2 つの専用の方法でアクセスできます。Post Office Protocol (POP) を使用すると、ユーザーはメッセージを 1 つずつダウンロードでき、ローカル ストレージに正常に保存された後にのみサーバーからメッセージが削除されます。サーバーにメッセージを残して、別のクライアントがアクセスできるようにすることも可能です。ただし、特定のメッセージに既読、返信、転送などのフラグを付ける機能はないため、異なるマシンから同じメールにアクセスするユーザーにとって POP は便利ではありません。
あるいは、インターネット メッセージ アクセス プロトコル(IMAP) を使用すると、ユーザーはメッセージをサーバー上に保持し、適切なフラグを付けることができます。IMAP にはフォルダーとサブフォルダーが用意されており、異なるアクセス権を持つさまざまなユーザー間で共有できます。通常、送信済み、下書き、ごみ箱のフォルダーがデフォルトで作成されます。IMAP には、リアルタイム更新用のアイドル拡張機能があり、長時間の接続が可能な場合にポーリングよりも高速な通知を提供します。以下のリモート メッセージのセクションも参照してください。
JSON Meta Application Protocol (JMAP) は、HTTP 経由の JSON API を使用して実装され、IMAP/SMTP の代替として開発されました。
さらに、メールボックス ストレージには、サーバー上で実行されているプログラムから直接アクセスすることも、共有ディスク経由でアクセスすることもできます。直接アクセスはより効率的ですが、メールボックスの形式に依存するため移植性が低くなります。一部の Web メール アプリケーションを含む一部の電子メール クライアントで使用されます。
メッセージの構成
電子メール クライアントには通常、テキストを表示および編集するためのユーザー インターフェイスが含まれています。一部のアプリケーションでは、プログラム外部のエディターを使用できます。
電子メール クライアントは、ヘッダーと本文についてはRFC 5322に従ってフォーマットを実行し、非テキスト コンテンツと添付ファイルについてはMIMEに従ってフォーマットを実行します。ヘッダーには、宛先フィールド、 To、Cc ( Carbon copyの略)、およびBcc ( Blind carbon copy )、および発信者フィールド、メッセージの作成者 (複数可)、作成者が複数いる場合はSender 、および応答を別のメールボックスに宛てて送信する必要がある場合はReply-To が含まれます。宛先フィールドに関してユーザーをよりよくサポートするために、多くのクライアントは 1 つ以上のアドレス帳を保持し、LDAPディレクトリ サーバーに接続できます。発信者フィールドについては、クライアントはさまざまな ID をサポートする場合があります。
クライアント設定では、各ユーザーの ID としてユーザーの実名と電子メール アドレス、および場合によっては LDAP サーバーのリストが必要になります。
サーバーにメッセージを送信する
ユーザーが電子メールを作成して送信する場合、電子メール クライアントがそのタスクを処理します。電子メール クライアントは通常、ユーザーのメール サーバーに接続するように自動的に設定されます。ユーザーのメール サーバーは通常、SMTPプロトコルの 2 つのバリエーションであるMSAまたはMTAのいずれかです。SMTP プロトコルを使用する電子メール クライアントは、メール サーバーが送信者を認証するために使用する認証拡張機能を作成します。この方法により、モジュール性とノマディック コンピューティングが容易になります。以前の方法では、メール サーバーがクライアントの IP アドレスを認識していました。たとえば、クライアントが同じマシン上にあり、内部アドレス 127.0.0.1 を使用しているか、クライアントの IP アドレスがインターネット アクセスとメール サービスの両方を提供する同じインターネット サービス プロバイダーによって制御されているかのどちらかです。
クライアント設定には、優先送信メール サーバーの名前または IP アドレス、ポート番号(MTA の場合は 25、MSA の場合は 587)、および認証用のユーザー名とパスワード(ある場合) が必要です。SSL 暗号化 SMTP セッションには非標準ポート 465 があり、多くのクライアントとサーバーは下位互換性のためにこれをサポートしています。
暗号化
暗号化がなければ、はがきの場合と同様、電子メールのアクティビティは、たまに盗聴する人によって明らかに見えてしまいます。電子メールの暗号化により、メール セッション、メッセージ本文、またはその両方を暗号化してプライバシーを保護できます。暗号化がなければ、ネットワーク アクセスと適切なツールを持つ人なら誰でも電子メールを監視し、ログイン パスワードを入手できます。懸念される例としては、政府の検閲と監視、インターネット カフェなどのワイヤレス ネットワーク ユーザーなどが挙げられます。
関連するすべての電子メールプロトコルには、ユーザー名とパスワードが盗聴されるのを防ぐために、セッション全体を暗号化するオプションがあります。ノマドユーザーやインターネットアクセスプロバイダーが信頼できない場合は、このオプションを強くお勧めします。 [1]メールを送信する際、ユーザーはクライアントから設定された送信メールサーバーへの最初のホップでのみ暗号化を制御できます。それ以降のホップでは、送信サーバーの一般的な構成と受信サーバーの機能に応じて、暗号化ありまたは暗号化なしでメッセージが送信されます。
暗号化されたメール セッションでは、メッセージを元の形式 (プレーン テキストまたは暗号化された本文) で、ユーザーのローカル メールボックスと宛先サーバーのメールボックスに配信します。後者のサーバーは、電子メール ホスティング サービスプロバイダーによって運営されており、現在使用しているインターネットアクセスプロバイダーとは異なる組織である可能性があります。
SSLなどで電子メールの取得セッションを暗号化すると、セッションの両方の部分（認証とメッセージ転送）を保護できます。[2] [3]
あるいは、ユーザーがメールサーバーにSSHアクセスできる場合は、SSHポート転送を使用して暗号化されたトンネルを作成し、そのトンネルを介してメールを取得できます。[4]
メッセージ本文の暗号化
暗号鍵の管理には、主に 2 つのモデルがあります。S /MIME は、ユーザーの公開鍵に署名する信頼できる証明機関(CA)に基づくモデルを採用しています。OpenPGPは、ユーザーが互いの公開鍵に署名できる、やや柔軟な信頼の輪のメカニズムを採用しています。OpenPGP は、メッセージの形式に関してもより柔軟で、MIME標準化以前に機能していたプレーン メッセージの暗号化と署名を引き続きサポートしています。
どちらの場合も、メッセージ本文のみが暗号化されます。発信者、受信者、件名などのヘッダー フィールドはプレーン テキストのままです。
ウェブメール
デスクトップ コンピューターで実行される電子メール クライアントに加えて、telnetでアクセス可能なリモート UNIX インストール(つまり、シェル アカウント) の一部として、またはWeb上でホストされているリモートでホストされる電子メール クライアントもあります。これらのアプローチには、 Web ブラウザーまたは telnet クライアントを使用して、ユーザーの通常の拠点から離れて電子メールを送受信できるという共通点があり、そのため、ユーザーのデバイスに専用の電子メール クライアントをインストールする必要がありません。
一部の Web サイトは電子メール サービスの提供に特化しており、多くのインターネット サービス プロバイダーは、インターネット サービス パッケージの一部として Web メール サービスを提供しています。Web メールの主な制限は、ユーザー操作が Web サイトのオペレーティング システムによって左右されることと、電子メール メッセージをダウンロードしてオフラインで作成または操作することが一般的にできないことです。ただし、Web メール機能の一部を OS に統合できるソフトウェア パッケージもあります (たとえば、MAPI経由でサードパーティ アプリケーションから直接メッセージを作成するなど)。
IMAP や MAPI と同様に、Web メールでは電子メール メッセージをメール サーバーに残すことができます。次のセクションを参照してください。
リモートメッセージ
POP3にはサーバー上にメッセージを残すオプションがあります。対照的に、IMAPとウェブメールはどちらもサーバー上にメッセージを残すという動作方法ですが、ユーザーは好きなようにローカルコピーを作成できます。サーバー上にメッセージを残すことには利点と欠点があります。[5]
利点
- メッセージには、さまざまな場所にあるさまざまなコンピューターやモバイル デバイスから、さまざまなクライアントを使用してアクセスできます。
- 通常、サーバーによって何らかのバックアップが提供されます。
デメリット
- 帯域幅が限られている場合、電子メール クライアントがローカル コピーをキャッシュしない限り、長いメッセージへのアクセスには時間がかかることがあります。
- エンドツーエンドの暗号化を使用しない限り、サーバー上に常に保存されているメッセージは IT 担当者が偶発的にアクセスする可能性が高くなるため、プライバシーに関する懸念が生じる可能性があります。
プロトコル
メールを取得するための一般的なプロトコルには、POP3とIMAP4があります。メールの送信は通常、 SMTPプロトコルを使用して行われます。
ほとんどの電子メール クライアントでサポートされているもう 1 つの重要な標準はMIMEです。これは、電子メールのバイナリファイルを 添付ファイルとして送信するために使用されます。添付ファイルは、電子メール本体の一部ではないが、電子メールとともに送信されるファイルです。
ほとんどの電子メールクライアントは、メッセージの送信に使用されたソフトウェアを識別するためにUser-Agent [6] ヘッダーフィールドを使用します。このヘッダーフィールドはNetnews用に定義されていますが、電子メール用には定義されていないため、電子メールヘッダーでは 非標準[7]となっています。
RFC 6409 「メールのメッセージ送信」では、メール送信エージェントの役割について詳しく説明しています。
RFC 5068 「電子メール送信操作: アクセスとアカウンタビリティの要件」では、MTA、MSA、MDA、および MUA の概念の概要が説明されています。この中には、「アクセス プロバイダーは、ユーザーが送信ポート 587 を使用して外部インターネットにアクセスすることをブロックしてはならない」、および「 MUA はメッセージの送信に送信ポートを使用する必要がある」 と記載されています。
RFC 5965「電子メール フィードバック レポートの拡張可能な形式」では、「メール オペレータが受信した電子メールに関するフィードバックを他の当事者に報告するために使用できる拡張可能な形式と MIME タイプ」が規定されています。
ポート番号
電子メールサーバーとクライアントは、慣例により、次の表のTCPポート番号を使用します。MSA、IMAP、POP3の場合、この表には、クライアントがSRVレコードを照会して、対応するサービスのホスト名とポート番号の両方を検出するために使用できるラベルも記載されています。 [8]
ウェブメールは、暗号化セッションとプレーン テキスト セッションに別々のポートを持つという以前の HTTP の規定に従いますが、メール プロトコルはSTARTTLS技術を使用して、すでに確立されている TCP 接続で暗号化を開始できるようにします。RFC 2595 では、以前に確立されたポート 995 と 993 の使用は推奨されていませんでしたが、RFC 8314では、利用可能な場合は暗黙的なTLS の使用が推奨されています。
独自のクライアントプロトコル
Microsoftメール システムは、 Microsoft Outlookなどのクライアント アプリケーションで独自の メッセージング アプリケーション プログラミング インターフェイス(MAPI) を使用して、Microsoft Exchange電子メール サーバーにアクセスします。
参照
無料辞書の Wiktionary で電子メール クライアントを調べてください。
- メールクライアントの比較
- メッセージ送信エージェント(MSA)
- メール
- メッセージ配信エージェント(MDA)
- メッセージ転送エージェント(MTA)
- 簡易メール転送プロトコル
- テキストベースの電子メールクライアント
参考文献
- ^ C. Hutzler、D. Crocker、P. Resnick、E. Allman、T. Finch (2007 年 11 月)。「メッセージ送信の認証/承認テクノロジ」。電子メール送信操作: アクセスと説明責任の要件。IETF。sec . 5。doi : 10.17487 /RFC5068。BCP 134。RFC 5068。2011年8 月 24 日に取得。このドキュメントは、特定のセキュリティ実装に関する推奨事項を提供するものではありません。これは、攻撃者がこのトラフィックをリッスンしてアカウント データを
盗む可能性があるため、安全でないネットワークを介してユーザーの資格情報をクリア テキストで送信することは、すべてのシナリオで回避する必要があるという警告のみを示しています。このような場合は、適切なセキュリティ テクノロジを使用することを強くお勧めします。
- ^ シル 2003、p. 353: 「SMTP と同様に、POP3 は暗号化されていません。ただし、SMTP とは異なり、認証が必要です。ユーザーは、自分自身を識別し、自分が主張する人物であることを証明する必要があります。残念ながら、認証は通常、ユーザーと POP3 サーバーのみが知っているユーザー名とパスワードを提示することで行われます。POP3 ダイアログは暗号化されていないため、盗聴者はユーザーのユーザー名とパスワードを入手し、それらを再利用してユーザーのメールボックスにアクセスできます。したがって、プレーン POP3 では、ユーザーが取得するメール メッセージの内容が公開され、ユーザー名とパスワードが公開され、他のユーザーがそれらを再利用できます。POP3
ダイアログを SSL などのトランスポート層セキュリティでラップすると、これらの両方の問題が解決されます。SSL でラップされた POP3 セッションは最初から最後まで暗号化されるため、メッセージ、ユーザー名、またはパスワードがクリアテキストで公開されることはありません。
オプションの POP3 コマンドは、APOP標準のUSER/PASS認証をチャレンジ レスポンス認証メカニズムに置き換えます。これにより、再利用可能なパスワードの漏洩の問題は解決されますが、ユーザーのメール メッセージが取得される際に盗聴者がそれを読むことを防ぐためです。」 - ^ 電子メール関連プロトコル用のトランスポート層セキュリティ (TLS) サーバー ID チェック手順の更新。doi : 10.17487 / RFC7817。RFC 7817 。
- ^ Flickenger, Rob (2003). Linux Server Hacks: 100 Industrial-Strength Tips & Tools . O'Reilly Media . p. 146. ISBN 978-0596004613
リモート シェル アクセスとコマンド実行に加えて、OpenSSH は任意の TCP ポートを接続のもう一方の端に転送できます。これは、電子メール、Web、またはプライベートにしておく必要のあるその他のトラフィック (少なくともトンネルのもう一方の端まで) を保護するのに非常に便利です。ssh
は、ローカル ポートにバインドし、暗号化を実行し、暗号化されたデータを
ssh
接続のリモート エンドに送信し
、次にそれを復号化して、指定したリモート ホストとポートに送信することで、ローカル転送を実現します。
-L
スイッチ (Local の省略形)
を使用して
ssh
トンネルを開始します。当然、
user は
ユーザー名に、
mailhost は
メール サーバーの名前または IP アドレスに置き換えます。この例では、特権ポート (110、POP ポート) にバインドするため、ラップトップで root になる必要があることに注意してください。また、ローカルで実行されている POP デーモン (
/etc/inetd.conf
を参照) を無効にしないと、邪魔になります。
すべての POP トラフィックを暗号化するには、メール クライアントを localhost ポート 110 に接続するように設定します。会話全体が暗号化されることを除けば、メール クライアントは直接接続されているかのようにメールホストと通信します。
root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost - ^ 「Is IMAP Right for Me?」。IT サービス。スタンフォード大学。2010 年 3 月 4 日。2013 年4 月 14 日閲覧。
- ^ 「User-Agent」。Netnews Article Format。IETF 。 2009年11月。sec. 3.2.13。doi : 10.17487/RFC5536。RFC 5536。この情報の一部は、以前はX-Newsreader、X-Mailer 、
X-Posting-Agent、X-Http-User-Agentなどの非標準化ヘッダーフィールドで送信されていました
。 - ^ J. Palme (1997 年2 月)。「ゲートウェイ ヘッダーの使用」。共通インターネット メッセージ ヘッダー。sec. 2。doi : 10.17487 /RFC2076。RFC 2076。2015年5月 11 日取得。RFC
1036 でのみ定義されている Usenet ニュースでの使用に関するヘッダーは、メッセージが Usenet ニュースから電子メールにゲートウェイされたか、同じクライアントで電子メールと Usenet ニュースの両方をサポートする複合クライアントでメッセージが作成されたために、メール メッセージに表示されることがあります。これらのヘッダーは、インターネット電子メールでの使用が標準化されていないため、電子メール エージェントでは注意して処理する必要があります。
- ^ Cyrus Daboo (2011 年 3 月) 。電子メール送信/アクセス サービスの検索に SRV レコードを使用する。IETF。doi : 10.17487 /RFC6186。RFC 6186。2013年4月 17日閲覧。
- ^ Keith Moore、Chris Newman ( 2018 年 1 月)。「クリアテキストは時代遅れと考えられる: 電子メールの送信とアクセスにおけるトランスポート層セキュリティ (TLS) の使用」。IETF。doi : 10.17487 /RFC8314。RFC 8314。2018年2月12 日閲覧。
文献
- シル、デイブ(2003) 。qmailハンドブック。Apress。ISBN 9781430211341。
- Partridge, Craig (2008 年 4 月～6 月)。「インターネット電子メールの技術的発展」(PDF)。IEEE Annals of the History of Computing。30 ( 2): 3–29。doi : 10.1109 /mahc.2008.32。ISSN 1934-1547。S2CID 206442868。2011 年5 月 12 日に オリジナル (PDF) からアーカイブ。