On Wednesday 30 September 2009 05:10:50 Dave CROCKER wrote:
wow. more than 16 hours and no one has posted anything.
post standardisation stress disorder?
Daniel Black wrote:
2. The author's email infrastructure DKIM signs the email message and
publishes a ADSP dkim record saying 'I sign all messages for this domain'
3. The message is received by the email list
I'm going to respond without getting into any of the ADSP emotional debate.
ADSP is what it is. DKIM is what it is. You are asking a legitimate
question about a potential scenario that seems likely to occur.
thank you - I was hoping I was.
If someone registers an ADSP record that says that any failed or absent
signatures .....
The scenario you are exploring demonstrates a case in which they were
wrong.
I think it a mistake to ask intermediaries to fix the effects of their own
legitimate actions,
probably, but what choices do I have?
1. propose intermediary changes that are hopefully acceptable
2. propose receiver based whitelists for DKIM validation software
3. ask list operators to reject subscription and posts from ADSP=DISCARD|ALL
domains because receivers will reject/drop them
4. try to develop a third party domain signing practices RFC (when ADSP took
2+ years) without developing standards stress disorder or a self inflicted bio
termination complication.
another? please suggest the one I should pursue?
really caused by inappropriate policy choices of an
organization earlier in the handling sequence.
ok, so the consensus so far is you can only deploy ADSP=DISCARDS|ALL if all
users from your domain never intend to participate in email lists (or any
other intermediary) that will invalidate your Author Domain signature?
Is consensus for validation to be strict and blame the author domain policy if
you drop content because of it?
Will any domain ever deploy a ADSP with awareness of these constraints?
So quoting from the IETF DKIM charter:
"Taken together[policy and signatures], these will assist receiving domains in
detecting (or ruling out) certain forms of spoofing as it pertains to the
signing domain."
Intermediary verifiers are lucky that there shouldn't be too many signature
invalidating processes before them. But as a end verifier I'm stuck. There is
no policy deployed to "take together" so the only class of spoofing I can rule
out is a spoofer who (thoughtfully) puts a invalid signature on an email when
I deploy this on a domain that doesn't receive broken email list signatures.
This really doesn't map to section 2 of rfc4686.
Am I missing something? or should I just use RFC3514 for antispoofing
protection?
ps. There are cases of SPF -a being set incorrectly, and it didn't even
take a mailing list to create undelivered mail. The solution is to change
the -a setting, rather than try to hack around it.
Which I assume is why SPF appears dominantly in DNS records and few mail
servers use it for validation. Is DKIM going to suffer the same fate? I really
hope not. Signatures are a good foundation but policy enforcement is required.
--
Daniel Black
Infrastructure Administrator
CAcert
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev