サイトマップ | 連絡先 | IAjapan TOP
IAjapan 財団法人インターネット協会
有害情報対策ポータルサイト 迷惑メール対策編
  • 一般利用者の皆様へ
  • メール管理者の皆様へ
  • 関連情報
  • サイト紹介

Page 10

12.  RFC 4871, Section 3.9, Relationship between SDID and AUID

Original Text:  

(None.  New section.  Additional text.)

12.  RFC 4871、3.9節、SDIDとAUIDの関係



Corrected Text:

DKIM’s primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity.  DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID).



Hence, DKIM’s mandatory output to a receive-side Identity Assessor is a single domain name.  Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. That is, within its role as a DKIM identifier, additional semantics cannot be assumed by an Identity Assessor.


A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.


To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM’s specification and semantics.  Hence, it is relegated to a higher-level service, such as a delivery handling filter that integrates a variety of inputs and performs heuristic analysis of them.


INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identifier in any other message header field.  This requirement is, instead, an assessor policy issue.  The purpose of such a linkage would be to authenticate the value in that other header field.  This, in turn, is the basis for applying a trust assessment based on the identifier value.  Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks.  The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker.  Hence, reliance on the use of such bindings should be strictly limited.  In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.


 [Page 10]

1 4 5 6 7 9 10 11 12 13 14
リンク・転載・引用・ロゴ使用について | プライバシーポリシー | IAjapanについて | 連絡先