On Sun, 1 Feb 2009, Byung-Hee HWANG wrote:
Authentication-Results: mx.google.com; (...)
smtp(_dot_)mail=smith(_at_)cs(_dot_)dkim(_dot_)edu; dkim=pass (test mode)
header(_dot_)i=smith(_at_)dkim(_dot_)edu
(...)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dkim.edu;
h=message-id:date:from:mime-version:to:subject:content-type:
content-transfer-encoding; s=student.cs;
i=smith(_at_)cs(_dot_)dkim(_dot_)edu;
(...)
Did you invent this example or actually try it? If it's real, the i= part
of "Authentication-Results" Google is reporting is wrong, since that's not
the i= value in the signature.
RFC4871 does not force "i=" tag's implementation in signature. However
Several company (eg., port25.com) try to match headers each 2822-From
and "i=" tag. That's somewhat dangerous (at least to me using subdomains
often). At reflector of port25.com, the result is *not* "pass" whenever
i send email with subdomains. So to Jason i suggested to make a way
protecting subdomains. And now, i see "DKIM Result: pass" at refelector
of port25.com. Let's go with dkimproxy. Now it's safe with
subdomains..;;
I'm not sure I agree that adding a feature which tricks the local policy
of a verifier, or a broken verifier, is something that can be described as
"safe". RFC4871 doesn't make a connection between the i= or d= values and
From:, so this is a local policy choice they've made (or perhaps a
hold-over from DomainKeys which did try to make that connection).
At any rate, there are other signing agents which provide this service, so
it's a common option.
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops