On Sat, 12 Jan 2008, Alin N?~Cstac wrote:
- verify-subdomain.patch correct dkim_policy()
It will return DKIM_PRESULT_VALIDOSIG state if sender domain address is
a subdomain of the signer domain and used key TXT entry don't have "t=s"
in it. I didn't take into account the SSP's "t" tag (IMO there is no
need to do it) and I was forced to use dkim_param_get(..,"i") because
dkim->dkim_signer is not set when dkim-filter verifies a signature. A
proper way of doing that would be to populate dkim_signer with "i" value
before dkim_policy() is called.
It seems to me that this change within dkim_policy() causes it to deviate
from the most recent published draft for SSP, which does not take into
account the "t" flag on the key itself. The extent of "t=s" in the key
record in particular is to consider the signature invalid if the message
signed for a subdomain when the published key record explicitly prohibits
such. This is part of RFC4871 and thus that decision process is complete
before dkim_policy() is ever called. dkim_policy() is meant only to
implement SSP, so making this change inside dkim_policy() isn't quite the
right place to do it as the libdkim API is currently designed.
The question now becomes one of how DKIM and SSP interact on this point.
One could argue that SSP's definition of "Originator Signature" should
take this into account. One could also argue that a site which wants to
sign for subdomains with a "strict" policy should be publishing keys for
each subdomain and not relying on this inheritance to be implicit.
Perhaps if Jim is still monitoring this list he could comment?
-MSK
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
dkim-milter-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss