Loading article…
電子メール認証、または検証とは、電子メールメッセージの転送および場合によっては変更に関与したメッセージ転送エージェント（MTA）のドメイン所有権を検証することにより、電子メールメッセージの発信元に関する検証可能な情報を提供することを目的とした一連の技術です。
インターネットメールの基盤であるシンプルメール転送プロトコル（SMTP）にはそのような機能がないため、メールの送信者アドレスを偽装する（メールスプーフィングと呼ばれる手法）がフィッシング、スパムメール、およびさまざまな種類の詐欺で広く利用されてきました。これに対抗するため、多くの競合するメール認証の提案が開発されてきました。2018年までにSPF、DKIM、DMARCの3つが広く採用されている。[ 1 ] [ 2 ]このような検証の結果は、自動メールフィルタリングに使用したり、受信者が適切なアクションを選択する際に役立てたりすることができる。
この記事では、メールの送信および受信におけるユーザー認証については扱いません。
1980年代初頭にシンプルメール転送プロトコル（SMTP）が設計された当時、送信者やシステムの真の検証機能は備えられていませんでした。これは、電子メールシステムが信頼できる企業や大学によって運用されていた時代には問題になりませんでしたが、1990年代初頭のインターネットの商用化以降、スパム、フィッシング、その他の犯罪に電子メールがますます多く利用されるようになりました。
メール認証は、メッセージの発信元を特定し、それによって政策や法律の執行力を高めるための、必要不可欠な第一歩である。
ドメイン所有権に依存するという立場は、2000年代初頭に現れた。[ 3 ] [ 4 ]これは、ドメインが電子メールアドレスの「 @」記号の 後の右側に表示されるため、粗粒度の認証を意味する。ユーザーレベルでのきめ細かい認証は、 Pretty Good PrivacyやS/MIMEなどの他の手段で実現できる。現在、各個人は最終的に自身のデジタルアイデンティティを管理しなければならない。
An outstanding rationale for email authentication is the ability to automate email filtering at receiving servers. That way, spoofed messages can be rejected before they arrive to a user's inbox. While protocols strive to devise ways to reliably block distrusted mail, security indicators can tag unauthenticated messages that still reach the inbox. A 2018 study shows that security indicators can lower the click-through ratio by more than ten points: 48.9% to 37.2% of the users who open spoofed messages.[5]
SMTP defines message transport, not the message content. Thus, it defines the mail envelope and its parameters, such as the envelope sender, but not the header (except trace information) nor the body of the message itself. STD 10 and RFC 5321 define SMTP (the envelope), while STD 11 and RFC 5322 define the message (header and body), formally referred to as the Internet Message Format.
SMTP defines the trace information of a message, which is saved in the header using the following two fields:[6]
A mail user agent (MUA) knows the outgoing mail SMTP server from its configuration. An MTA (or a relay server) typically determines which server to connect to by looking up the MX (Mail eXchange) DNS resource record for each recipient's domain name.
The path depicted below can be reconstructed on the ground of the trace header fields that each host adds to the top of the header when it receives the message:[6]
Return-Path: <author@example.com> Received: from D.example.org by E.example.org with SMTP ; Tue, 05 Feb 2013 11:45:02 -0500 Received: from C.example.net by D.example.org with SMTP ; Tue, 05 Feb 2013 11:45:02 -0500 Received: from B.example.com ( b.example.com [ 192.0.2.1 ]) by C.example.net (which is me) with ESMTP id 936ADB8838C for <different-recipient@example.net> ; Tue, 05 Feb 2013 08:44:50 -0800 (PST) Received: from A.example.com by B.example.com with SMTP ; 2013年2月5日(火) 17:44:47 +0100受信: [ 192.0.2.27 ]からA.example.comへSMTPで受信; 2013年2月5日(火) 17:44:42 +0100ヘッダーの先頭数行は通常、受信者によって信頼されます。これらの行は、受信者の管理ドメイン ( ADMD ) 内のマシンによって、明示的な指示に基づいて書き込まれます。対照的に、 AとBの関与、および送信者とされるMUAの関与を証明する行は、Cによって作成された偽造である可能性があります。Received:上に示したフィールドは、ヘッダーの画期的な部分です。これは、メッセージエンベロープに基づいて、メール配信エージェント(MDA) であるEReturn-Path:によって書き込まれます。電子メール認証用に設計された追加のトレースフィールドが、ヘッダーの先頭に表示されることがあります。
通常、発信者のADMDから送信されたメッセージは、宛先のMXレコードに直接送信されます（図ではB→D）。送信者のADMDは、メッセージがそのボックスを経由する場合にのみ認証トークンを追加できます。最も一般的なケースは、次のように図式化できます。
アクセスプロバイダは、SUBMISSIONポート587を使用して外部インターネットにアクセスするユーザーをブロックしてはなりません。
SPF を使用すると、受信者は、特定のドメインから送信されたと主張する電子メールが、そのドメインの管理者によって承認された IP アドレスから送信されたものかどうかを確認できます。通常、ドメイン管理者は、プロキシやスマートホストを含む、自身の送信 MTA で使用される IP アドレスを承認します。[ 7 ] [ 8 ]
送信側の MTA の IP アドレスは、リモート ホストに到達可能であることを確認することで接続を確立するTransmission Control Protocolによって有効であることが保証されます。 [ 9 ] 受信側のメール サーバーは、接続が確立された直後にHELOSMTPMail from:コマンドと各メッセージの先頭にある を受信します。どちらにもドメイン名を含めることができます。SPF 検証ツールは、一致する SPF レコードをDomain Name System (DNS) に問い合わせます。一致する SPF レコードが存在する場合、そのドメインの管理者によって承認された IP アドレスが指定されます。結果は「合格」、「不合格」、または中間の結果のいずれかになります。システムは通常、スパム対策フィルタリングでこれを考慮に入れます。[ 10 ]
DKIMはメッセージの内容をチェックし、デジタル署名を展開します。デジタル証明書を使用する代わりに、署名検証用の鍵はDNS経由で配布されます。このようにして、メッセージはドメイン名に関連付けられます。[ 11 ]
DKIM 準拠のドメイン管理者は、1 組以上の非対称鍵を生成し、秘密鍵を署名 MTA に渡し、公開鍵を DNS に公開します。DNS ラベルは の構造でselector._domainkey.example.com、セレクタは鍵ペアを識別し、_domainkeyは固定キーワードで、署名ドメインの名前が後に続くため、公開はそのドメインの ADMD の権限で行われます。SMTP トランスポート システムにメッセージを挿入する直前に、署名 MTA は、ヘッダーと本文の選択されたフィールド (またはその先頭のみ) をカバーするデジタル署名を作成します。署名はFrom:、To:、Date:、 、などの実質的なヘッダー フィールドをカバーする必要がありSubject:、その後、トレース フィールドとしてメッセージ ヘッダー自体に追加されます。任意の数のリレーがメッセージを受信して転送でき、各ホップで、DNS から公開鍵を取得して署名を検証できます。[ 12 ]中間リレーがメッセージの署名部分を変更しない限り、DKIM 署名は有効です。
DMARCは、認証済みメッセージに対するポリシーを指定できる技術です。これは、既存の2つのメカニズム、Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）を基盤として構築されています。
これにより、ドメインの管理者は、DNSレコードにポリシーを公開して、そのドメインからメールを送信する際にどのメカニズム（DKIM、SPF、またはその両方）を使用するか、From:エンドユーザーに表示されるフィールドをどのようにチェックするか、受信者がエラーをどのように処理するか、そしてこれらのポリシーに基づいて実行されたアクションを報告するメカニズムを指定できます。
他にも様々な方法が提案されてきましたが、現在では非推奨となっているか、まだ広く支持を得ていません。これらには、Sender ID、Certified Server Validation、DomainKeys、および以下のものが含まれます。
ADSPは、作成者のドメインによって署名されたメッセージに対するポリシーの指定を可能にした。メッセージはまずDKIM認証を経る必要があり、その後、ヘッダーFrom:フィールドに従ってメッセージが作成者のドメインによって署名されていない場合、ADSPは罰則的な処理を要求することができた。[ 13 ]
ADSPは2013年11月に歴史的資料に格下げされた。[ 14 ]
VBRは、既に認証済みのIDに保証を追加する方式です。この方式では、ドメインの評判を証明する、世界的に認められた機関が必要となります。
送信者は、保証機関に参照を申請できます。参照が承認されると、その機関が管理する DNS ブランチに公開されます。保証された送信者は、送信するメッセージにヘッダー フィールドを追加する必要があります。また、DKIM 署名を追加するか、SPF などの他の認証方法を使用する必要があります。受信者は、送信者の身元を検証した後、参照を検索することで、VBR-Info:主張された保証を検証できます。 [ 15 ]VBR-Info:
アプリケーションはこの方法を認証手段として使用することを避けるべきです。[ 16 ]それにもかかわらず、この方法はしばしば実行され、その結果があれば、Received:SMTP仕様で要求されるTCP情報に加えてヘッダーフィールドに書き込まれます。
先ほど見つかった名前の IP アドレスを調べることで確認される IP 逆引きは、IP が DNS で正しく設定されていることを示すだけです。IPアドレス範囲の逆引き解決は、それらを使用する ADMD に委任することも、 [ 17 ]ネットワークプロバイダが管理し続けることもできます。後者の場合、メッセージに関連する有用な ID を取得することはできません。
DNSWL （DNSベースのホワイトリスト）を調べると、送信者の評価、場合によっては送信者の識別情報が得られる可能性があります。
Authentication-Results:RFC 8601では、受信者が実行した電子メール認証チェックの結果を記録できるトレース ヘッダー フィールドが定義されています。 [ 16 ]複数の方法に対する複数の結果を同じフィールドに報告することができ、セミコロンで区切って適切に折り返します。
例えば、以下のフィールドは、SPFおよびDKIMのreceiver.example.org結果を書き込んで報告するものとされています。
認証結果: receiver.example.org ; spf=pass smtp.mailfrom = example.com ; dkim=pass header.i=@example.comフィールド名に続く最初のトークンはreceiver.example.org、認証サーバーのIDであり、authserv-idと呼ばれるトークンです。RFC 8601 をサポートする受信側は、下流のフィルタが混乱しないように、自身のドメインに属すると主張する偽のヘッダーを削除（または名前変更）する責任があります。ただし、フィルタはドメインが使用できる ID を把握する必要があるため、設定が必要です。
メールユーザーエージェント（MUA）にとって、どのIDを信頼できるかを判断するのはやや困難です。ユーザーは複数のドメインからメールを受信できるため（たとえば、複数のメールアドレスを持っている場合）、それらのドメインのいずれかが、Authentication-Results:中立に見えるフィールドを通過させてしまう可能性があります。このようにして、悪意のある送信者は、メッセージが別のドメインから届いた場合にユーザーが信頼してしまうような認証サーバーIDを偽造することができます。正当な認証サーバーIDは通常、メッセージが中継されたドメインと同じドメインのフィールドのAuthentication-Results:すぐ上に表示されます。メッセージが同じ信頼できるADMDに属するサーバー間で内部的に転送されたため、そのフィールドとヘッダーの上部の間に追加のフィールドが表示される場合があります。Received:Received:
インターネット割り当て番号局（IANA）は、電子メール認証パラメータのレジストリを管理しています。ただし、すべてのパラメータを登録する必要はありません。たとえば、サイトの内部使用のみを目的としたローカルな「ポリシー」値があり、これらはローカル構成に対応するため、登録は不要です。
しかし、同報告書は、ドメインレベル認証を有望な技術開発として特定した。
{{cite book}}:|work=無視されました (ヘルプ)の先頭にトレース レコード (「タイム スタンプ行」または「受信」行とも呼ばれる) を挿入します。このトレース レコードは、メッセージを送信したホストの識別情報、メッセージを受信したホスト (このタイム スタンプを挿入しているホスト) の識別情報、およびメッセージが受信された日時を示します。リレー メッセージには、複数のタイム スタンプ行が含まれます。
使用できる場所は 3 つあります。
非SRSフォワーダーのホワイトリスト登録メカニズムを提供している限り、概ね問題ないと思います。
主張することを可能にします。