On Mon, Nov 14, 2016 at 4:40 AM, Steven M Jones <s...@crash.com> wrote:
> So per Section 5, this form of DKIM signature will fail to verify at a > receiver who doesn't implement the new feature, period. And in fact any > forwarding - whether it alters the RFC5322 message or not - would > produce a DKIM verification failure at the next/final recipient. > Correct. > The language in Section 5 paragraph 3 seems to cover envelope splitting. > Should this be expanded to address origin ADMD infrastructure such as > split signer/MTA, analogous to the note about split MTA/verifier at the > receiving ADMD in paragraph 4? > Do you have a use case in mind that's not addressed by the text that's there? It seems to me the text that's there specifically covers any kind of split regardless of where in the handling chain the split occurs. Are there any usage guidelines or recommendations about how and when to > use the new signing feature that I missed? For example is there another > draft, or a thread in a different forum/list, that speaks to this? If it > doesn't exist, do we need to create one? (Ulp - did I just volunteer?) > I think this work is small enough that any such guidance can just be included here, probably in Section 5. Essentially, you use this if you want to defend against this particular type of attack and are also prepared to take on the additional cost (second signature, potential misunderstanding by verifiers and receivers). I'd be curious to get feedback from folks who aren't enamored of ARC, > but understand the motivating abuse... > I don't think there's any plan with this work to supplant or augment ARC, in case that's what you're implying. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
