On Wednesday, February 08, 2012 11:38:58 PM Scott Kitterman wrote: > On Tuesday, February 07, 2012 10:42:46 PM Murray S. Kucherawy wrote: > ... > > > Still in WGLC until Friday. Have at it. > > ... > > In paragraph 11.2 (forgeries), the last section of it: > > Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM. On the other hand, if there is a problem with the DKIM > infrastructure at the Verifier, signing DKIM failure reports may > produce reports that aren't trusted or even accepted by their > intended recipients. > > I think it would useful to mention both SPF and DKIM here as one may offset > failures in the other (along the lines of what DMARC is doing). Proposed > text: > > Perhaps the simplest means of mitigating this threat is to assert > that these reports should themselves be signed with something like > DKIM or authorized with SPF. On the other hand, if there is a problem > with the DKIM infrastructure at the Verifier, signing DKIM failure reports > may produce reports that aren't trusted or even accepted by their > intended recipients. There may be similar issues with SPF evaluation. > Use of both technologies can mitigate this risk to a degree.
I should have mentioned that this is consistent with combining the input from both the DKIM and SPF drafts into the AS draft. The SPF draft currently says: Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves pass SPF checks and/or use other email authentication technologies such as DKIM. I'm currently working on an update to the SPF draft and am assuming you'll do something along these lines. If not, I think I need to put the forgeries consideration back into the SPF draft. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
