電子メールはどのように機能しますか?

まず、メールユーザーエージェントまたはMUAを使用して、デバイス(Gmail、Appleデバイスのメールアプリなど)から電子メールを読み取って送信します。これらのプログラムは、使用している場合にのみアクティブになります。

通常、メール転送エージェント、またはMTA(メールサーバー、MXホスト、メールエクスチェンジャーとも呼ばれます)と通信します。MTAは、メールの受信と保存を行います。

メールをチェックするためにMUAを開くまで、メールはリモートに保存されます。電子メールは、通常MTAにパッケージ化されているメール配信エージェント(MDA)によって配信されます。

メールは、SMTPまたはSimple Mail TransferProtocolを使用してメールサーバーに送信されていました。SMTPは、電子メールの通信プロトコルです。

現在でも、Microsoft Exchangeなどの多くの独自のシステムやGmailなどのウェブメールプログラムは内部で独自のプロトコルを使用していますが、SMTPを使用してシステム外にメッセージを転送しています(たとえば、GmailユーザーがOutlookクライアントにメールを送信したい場合)。

次に、Post Office Protocol(POP3)を使用してサーバーからメールがダウンロードされます。POP3は、ユーザーアプリケーションがメールサーバー上のメールボックスに接続するためのインターネットプロトコル(IP)ネットワーク経由のアクセスを提供するアプリケーション層プロトコルです。接続、メッセージの取得、クライアントのコンピューターへの保存、サーバーでの削除または保持が可能です。

ダイヤルアップなどの一時的なインターネット接続を管理できるように設計されています(接続すると接続して電子メールを取得するだけで、オフラインのときにメッセージを表示できます)。これは、ダイヤルアップアクセスが普及したときに人気がありました。

現在、インターネットメッセージアクセスプロトコルであるIMAPは、ほとんどPOP3に取って代わりました。IMAPを使用すると、複数のクライアントが同じメールボックスを管理できます(したがって、デスクトップ、ラップトップ、電話などから電子メールを読み取ることができ、すべてのメッセージが同じ方法で整理されてそこに表示されます)。

最終的に、ウェブメールが両方に取って代わりました。ウェブメールを使用すると、ウェブサイトにログインして、どこからでも、どのデバイスからでもメッセージを受信できます(イェーイ!)。ただし、使用中はインターネットに接続する必要があります。ウェブサイト(Gmailなど)がMUAの場合、SMTPまたはIMAPサーバーの設定を知る必要はありません。

メールはどのように保護されていますか?

残念ながら、セキュリティは最初からメールプロトコルに実際には組み込まれていませんでした(ほとんどの最初のインターネットプロトコルのように)。サーバーは、誰かからのメッセージを受け取り、それを他のサーバーに渡すことを期待していました。これは、メッセージを最終的な宛先(to:フィールドの受信者)にルーティングするのに役立ちます。

当然のことながら、これは、インターネットがいくつかの政府や研究グループから、世界のほとんどが本質的にすべてを行うために使用するものに拡大したときに問題になりました。すぐにスパムメールとフィッシングメールが誰にとっても大きな問題になりました(そして今も残っています)。

これに応えて、他の人のメッセージを読まないようにする(暗号化)、メッセージが実際に送信者とされるものからのものであることを検証する(認証)いくつかの対策をまとめて実装しようとしました。  

ほとんどの場所では、転送中に暗号化を提供する暗号化プロトコルであるTLS(トランスポート層セキュリティ、SSLの代替、セキュアソケット層)を使用しています。メッセージが送信されているときは保護されますが、データが保存されているとき(たとえば、コンピューターに保存されているとき)は保護されません。

これにより、MTAからMTAに移動しているときに、メッセージが変更されたり、スヌープされたりすることがなくなります。ただし、これは、旅行中にメッセージが変更されなかったことを確認するものではありません。

たとえば、電子メールが最終的な宛先に到達する前に複数のメールサーバーを通過する場合、TLSを使用すると、サーバー間で確実に暗号化されますが、各サーバーがメッセージの内容を変更する可能性があります。これに対処するために、SPF、DKIM、DMARCを作成しました。

SPF(Sender Policy Framework)

SPFを使用すると、ドメイン(google.comなど)の所有者は、DNSにTXTレコードを設定して、そのドメインからメールを送信できるサーバーを指定できます(さまざまなホスティングプロバイダーでこれを行う方法については、こちらをご覧ください)地点)。

これはどのように作動しますか?

このレコードには、許可され、次のいずれかのオプションで終了できるデバイス(通常はIP別)が一覧表示されます。

-all =チェックが失敗した場合(電子メールの送信元がリストされたデバイスの1つではない場合)、結果はHardFailになります。ほとんどのメールシステムは、これらのメッセージをスパムとしてマークします。

?all = =チェックが失敗した場合(電子メールの送信元がリストされたデバイスの1つではない場合)、結果は中立です。これは通常、本番ドメインではなく、テストに使用されます。

〜all =チェックが失敗した場合(電子メールの送信元がリストされたデバイスの1つではない場合)、結果はSoftFailになります。これは、このメッセージが疑わしいことを意味しますが、必ずしも既知の悪いメッセージではありません。一部のメールシステムはこれらのメッセージをスパムとしてマークしますが、ほとんどはマークしません。

SPFヘッダーは、サーバーがメッセージを処理しているため、サーバー自体に役立ちます。たとえば、サーバーがネットワークのエッジにある場合、サーバーは、受信するメッセージが送信者のSPFレコード内のサーバーから送信される必要があることを認識しています。これにより、サーバーはスパムをより早く取り除くことができます。これは素晴らしいことのように聞こえますが、残念ながら、SPFにはいくつかの大きな問題があります。

  1. SPFは、メールサーバーにメッセージの処理方法を指示しません。つまり、メッセージはSPFチェックに失敗しても、配信される可能性があります。
  2. SPFレコードは、ユーザーに表示される「from」アドレスではなく、「return-path」を参照しています。これは基本的に、手紙に書いた差出人住所に相当します。レターを処理するメールサーバーにメッセージの返送先を通知します(メッセージは電子メールヘッダーに保存されます。基本的に、サーバーが電子メールの処理に使用する技術情報です)。

    つまり、from:アドレスに好きなものを入れることができ、SPFチェックに影響を与えません。実際、これらの電子メールアドレスは両方ともハッカーによって比較的なりすまされている可能性があります。暗号化が含まれていないため、SPFヘッダーを完全に信頼することはできません。

  3. SPFレコードは常に最新の状態に保つ必要がありますが、これは大規模で変化し続ける組織では困難な場合があります。
  4. 転送はSPFを壊します。これは、たとえばgoogle.comからのメールが[email protected]によって転送された場合、エンベロープの送信者は変更されないままであるためです(差出人アドレスは引き続きgoogle.comと表示されます)。受信メールサーバーは、それがgoogle.comからのものであると主張しているが、bobsburgers.comからのものであると考えているため、SPFチェックに失敗します(メールが実際にはgoogle.comからのものであっても)。

SPFの詳細については、これらの記事を確認してください。ここで、特定のドメインにSPFレコードとDMARCレコードが構成されているかどうかを確認できます。

DKIM(DomainKeys Identified Mail)

DKIMはSPFに似ています。送信ドメインのDNSでもTXTレコードを使用し、メッセージ自体の認証を提供します。メッセージが転送中に変更されていないことの検証を提供しようとします。

これはどのように作動しますか?

送信ドメインは公開鍵と秘密鍵のペアを生成し、公開鍵をドメインのDNS TXTレコードに配置します(公開鍵と秘密鍵のペアが何であるかわからない場合は、暗号化に関するこの記事を確認してください)。

次に、ドメインのメールサーバー(外側の境界-ドメインの外部(例:gmail.comからoutlook.com)にメールを送信しているサーバー)は、秘密鍵を使用して、メッセージ本文全体の署名を生成します。ヘッダー。

署名を生成するには、通常、テキストをハッシュして暗号化する必要があります(このプロセスの詳細については、この記事を確認してください)。

受信メールサーバーは、DNS TXTレコードの公開キーを使用して署名を復号化し、メッセージと関連するヘッダー(メールが送信者のインフラストラクチャ内にある間に作成されたヘッダー-たとえば、複数のGmailサーバーがメールを処理する前にメールを処理した場合)をハッシュしますoutlook.comに外部から送信されました)。

次に、サーバーは2つのハッシュが一致することを確認します。その場合、メッセージは変更されていない可能性が高く(誰かが送信者の秘密鍵を侵害し​​ていない限り)、送信者と称されるものから正当に送信されます。ハッシュが一致しない場合、メッセージは送信者とされるものからのものではないか、転送中の他のサーバーによって変更されたか、またはその両方です。

DKIMは、1つの非常に具体的なタスクで非常に優れた仕事をします。「この電子メールは送信中に変更されたのか、送信者とされるものから変更されたのか」という質問に答えます。ただし、それだけです。このテストに失敗した電子メールの処理方法、メッセージを変更した可能性のあるサーバー、または行われた変更については説明していません。  

DKIMは、一部のISPまたはインターネットサービスプロバイダーでも、ドメインのレピュテーションを決定するために使用されます(大量のスパムを送信していますか?エンゲージメントが低いですか?電子メールはどのくらいの頻度で返送されますか?)。

DKIMの詳細については、この記事をご覧ください。ここでDKIMレコードを検証できます。

DMARC(ドメインベースのメッセージ認証、レポート、および準拠)

DMARCは基本的に、SPFおよびDKIMレコードの処理方法に関するメールサーバー向けの指示です。独自のテストは実行しませんが、SPFとDKIMが実行するチェックの処理方法をメールサーバーに指示します。

参加しているISPは、公開されているDMARCレコードを確認し、それらを使用してDKIMまたはSPFの失敗に対処する方法を決定します。したがって、たとえば、一般的になりすましのブランドは、DKIMまたはSPFが失敗した場合、メッセージをドロップすることを示すDMARCレコードを公開する可能性があります。

多くの場合、ISPは、ドメインのアクティビティに関するレポートを、電子メールの送信元と、DKIM / SPFに合格/不合格であるかどうかとともに送信します。これは、他のユーザーがドメインをスプーフィング(送信しようとしている)したり、メッセージを変更したりしていることを確認できることを意味します。

DMARCを実装するには、ニーズに基づいてDMARCレコードを作成する必要があります(電子メールトラフィックを監視してすべての電子メールソースを把握することから、DKIMまたはSPFに失敗した電子メールを拒否するなどのアクションを要求することまで)。あなたはこことここでそれをすることについてもっと学ぶことができます。

DMARCの詳細については、この記事をご覧ください。ここで、特定のドメインにSPFレコードとDMARCレコードが構成されているかどうかを確認できます。

要約

これらのセキュリティ対策はどれも完璧ではありませんが、一緒になって、世界中の電子メールシステムのセキュリティを向上させるのに役立つ適切な仕事をしています。

これらの手段を採用する組織が多ければ多いほど(オープンソースの実装を使用するか、製品にお金を払う)、誰もがより良くなるでしょう。プロトコルまたは製品の開発後に追加されるセキュリティは、通常、製品に組み込まれているセキュリティよりも高価で、効果が低く、実装が困難です。

ただし、現在のインターネットが依存しているプロトコルのほとんどは、建物、スマートデバイス、公共交通機関、原子力発電所を運営する世界的なネットワークではなく、初期のインターネット(愛好家、科学者、政府関係者の小グループ向け)向けに設計されています。 (!)、 等々。

したがって、インターネットが拡大し続けるにつれて、私たちは依存するシステムを保護するための新しい方法を適応させ、開発し続ける必要があります。