At 10:29 03-02-2009, Tony Hansen wrote:
Its utility is outside of DKIM. The DKIM base spec says the value is
opaque. Other specs can expose its structure.
According to informative note in RFC 4871, the Local-part of the "i="
tag is optional
because in some cases a signer may not be able to establish a
verified individual identity. That means that it's the Local-part
which is opaque and not the
domain part of the address.
At 11:47 03-02-2009, Dave CROCKER wrote:
ps. FWIW, my intent in included SDID was that the particular naming scheme is
outside of DKIM semantics. So marketing.example.com and
hq.example.com, versus
newsletter.example.org and invoices.example.org are significantly different
naming schemes, but the semantics behind them is opaque to DKIM
semantics and,
therefore, to the Identity Assessor.
That makes the domain part opaque too. The corrected text in the
Errata changes the introduction to "permitting a person, role or
organization that owns the signing domain to claim
responsibility". I don't see how anyone can claim responsibility
when we cannot identify the signing domain.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html