電子メールのしくみ

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

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

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

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

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

その後、Post Office Protocol (POP3) を使用してサーバーからメールがダウンロードされます。接続、メッセージの取得、クライアントのコンピューターへの保存、サーバーでの削除または保持が可能です。

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

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

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

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

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

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

これに対応して、私たちは集団でいくつかの手段を実装して、人々が他人のメッセージを読むのを防ぎ (暗号化)、メッセージが実際に偽装された送信者から送信されたことを検証する (認証) ことを試みました。

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

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

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

SPF (送信者ポリシー フレームワーク)

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

これはどのように機能しますか?

このレコードは、許可され、次のオプションのいずれかで終わることができるデバイスを (通常は IP ごとに) リストします:

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

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

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

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

<オール>

SPF はメール サーバーにメッセージの処理方法を指示しません。つまり、メッセージが SPF チェックに失敗しても配信される可能性があります。

SPF レコードは、ユーザーに表示される「送信元」アドレスではなく、「リターン パス」を見ています。これは基本的に、手紙に書く差出人住所に相当します。メッセージを返す場所を手紙を処理するメールサーバーに伝えます（そして、メールヘッダーに保存されます-本質的にサーバーがメールを処理するために使用する技術情報です）。
つまり、from:アドレスには何でも好きなものを入れることができ、SPF チェックには影響しません。実際、これらの電子メール アドレスは両方とも、ハッカーによって比較的なりすましの可能性があります。暗号化が含まれていないため、SPF ヘッダーを完全に信頼することはできません。

SPF レコードは常に最新の状態に保つ必要がありますが、変化し続ける大規模な組織では困難な場合があります。

転送すると SPF が壊れます。これは、たとえば google.com からの電子メールが bob@bobsburgers.com によって転送された場合、エンベロープ送信者が変更されないためです (送信者アドレスは google.com のままです)。受信メール サーバーは、それが google.com からのものであると主張しているが、bobsburgers.com からのものであると認識しているため、SPF チェックに失敗します (メールが実際には google.com からのものであっても)。

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

DKIM (ドメインキー識別メール)

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

これはどのように機能しますか?

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

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

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

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

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

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

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 レコードが構成されているかどうかを確認できます。

まとめ

これらのセキュリティ対策はどれも完璧ではありませんが、これらを組み合わせることで、世界中の電子メール システムのセキュリティを向上させるのに役立ちます。

これらの手段を採用する組織が増えるほど (オープンソースの実装を使用するか、製品に料金を支払うかのいずれか)、すべての人にとってより良い結果が得られます。プロトコルまたは製品の開発後に追加されるセキュリティは、通常、製品に組み込まれたセキュリティよりも費用がかかり、効果が低く、実装が困難です。

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

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