On Tue, 27 Nov 2007 20:21:32 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
Not exactly.
-------
3.5 The DKIM-Signature Header Field
...
[Regarding i= tag]
INFORMATIVE NOTE: 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. In such cases, the signer may wish to assert that although it
is willing to go as far as signing for the domain, it is unable or
unwilling to commit to an individual user name within their domain. It
can do so by including the domain part but not the local-part of the
identity.
INFORMATIVE DISCUSSION: This document does not require the value of the
"i=" tag to match the identity in any message header fields. This is
considered to be a verifier policy issue. Constraints between the value
of the "i=" tag and other identities in other header fields seek to
apply basic authentication into the semantics of trust associated with a
role such as content author. 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 "i=" value and
other identities is not well established, nor is its vulnerability to
subversion by an attacker. Hence reliance on the use of these options
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 "i=" options.
That almost, but not quite, says the right thing.
Essentially, the signature MUST include the From header (others are at the
signer's discretion). So, at a minimum, the signer is asserting that this
message came into bis possession via a route that indicacted that its
origin was within the domain within the From (mailing list signatures
excepted, of course). If the signer is not prepared to vouch for that,
then he has no business signing it.
Likewise, if he goes to the trouble of including an "i=foo(_at_)bar(_dot_)com", then
he is asserting that foo(_at_)bar(_dot_)com had played some part in introducing the
message into his system. Otherwise, he should not have included that tag.
So if the present documents do not make these things clear, then we need a
further (BCP?) document that sets out, in the form of a Code of Practice,
just what obligations are entailed by creating such a signature.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html