ARC について

メールヘッダ上の送信者情報 (From:) を認証する DMARC では、これまで普通に利用されてきたいくつかのメール利用方法で、正しくメールが認証されない、という課題がありました。その多くは、再配送するようなメール (indirect mailflow) ですが、これらに対応するための仕組みが ARC (Authenticated Received Chain)*1 です。ARC の仕様については、まだ検討中の段階ですがその概要について説明します。

これまで、メールが何らかの事情で再配送された場合、経由したメールサーバ度に Received:メールヘッダが追加されます。これら Received:ヘッダを参照すればメールの送信経路を把握することができますが、付けられている Received:ヘッダが正しいのかを検証する仕組みがありませんので、勝手に追加等されても判断することができません。
ARC は、電子署名の技術を利用し、メールが再配送された場合でも認証結果を示す Authentication-Results:ヘッダを辿れるようにすることで、認証の連鎖を帰納的に確認できるようにする技術です。

ARC では、追加された順番を示す番号 (i=) を含んだ3つの新しいメールヘッダが追加されます。

つまり ARC では、再配送時に単純に DKIM で再署名するのではなく、ARC 独自に再署名をすることで、際配送先で認証の連鎖を検証し、ARC としての検証結果を得ることになります。検証結果は、ARC-Seal:ヘッダに cv= (chain validation status) として残されますし、これまで通り Authentication-Results:ヘッダにも arc= として結果が示されるようになります。検証結果として定義されている値を以下に示します。

Authentication-Results:ヘッダの内容を ARC-Authentication-Results:ヘッダに保存する目的は、メール受信時に既存の Authentication-Results:ヘッダを削除する場合があるためです。これを保存することで、再配送の度にこれまでの検証結果をたどることができるようになります。
図は、taro@example.jp がメーリングリスト members@ml.example.org にメールを投稿し、そのメーリングリストのメンバである jiro@example.com 宛てにメールが届いた場合のヘッダの追加部分を示したものです。メーリングリストサーバがメンバに配送する際に、ARC 関連の3つのヘッダが追加されます。最終受信先である example.com のメールサーバでは、受信したメーリングリストのメールを認証した場合、投稿者 example.jp の DKIM 署名が付いていますが、メーリングリスト機能が Subject: に文字列を追加しましたので、通常は DKIM 署名の検証が失敗します (dkim=fail となる)。しかしながら、メーリングリストサーバが投稿メールを受信した際に正しく DKIM 認証が pass し、その結果を ARC-Authentication-Results:ヘッダに保存し、ARC として再署名して再配送すれば、ARC としては pass となります。これによって、最初のメール投稿者から送られてきた経路の検証ができ、少なくとも直近のメーリングリストサーバが信頼できる送信者であるならば、受信したメールは正しいものと判断することができます。

また例えば、メーリングリストメンバの jiro@example.com がさらに別のメールアドレスに自動転送されたメールには、i=2 がついた3つの ARC ヘッダがさらに追加されて送信されることになります。この場合も同様に、転送先で ARC ヘッダを検証することにより、ARC としての認証結果が得られることになります。
ARC でも DKIM と同様に電子署名技術を利用します。そのため、秘密鍵と公開鍵の鍵ペアが必要となりますが、これらは DKIM と同じ仕組みを利用します。つまり、ARC-Seal:ヘッダで指定するドメイン() とセレクタ() 情報を組み合わせた、. domainkey. に公開鍵の情報が保存されることになります。