On 15/Oct/11 02:01, Murray S. Kucherawy wrote: > > I have to say I agree that the idea of sending one report for every > DKIM/SPF failure on a message is un-pretty, but it's less un-pretty > than the two syntactical alternatives that have been put forward in > this thread.
I'm not clear on what two syntactical alternatives you mean, since I proposed two myself http://www.ietf.org/mail-archive/web/marf/current/msg01403.html http://www.ietf.org/mail-archive/web/marf/current/msg01418.html My concept of un-pretty is having redundant data, as it brings uncertainty on how to process it. Thus, my first proposal was to drop A-R from the second part. John then proposed to have exactly one A-R in the second part. You then proposed to store the other data in repeating groups of fields. My second proposal then was to have exactly one A-R field that includes one "resinfo" stanza for each failed check, dropping the three method-specific multiple fields defined in Section 3.2.2, since the values that they convey can be stuffed in the relevant resinfo. For example: Authentication-Results: authserv-id.example; dkim=fail header.d=DKIM-Domain-0.example [email protected] header.s=DKIM-Selector-0.example; dkim=fail header.d=DKIM-Domain-1.example [email protected] header.s=DKIM-Selector-1.example header.b=MAynEEdThis/asWeLL==; (...) Except header.s, all that is already specified, especially the grouping. DKIM-Canonicalized-Header/Body don't need to be repeated, and any DNS entry can be recognized by its query part. What's wrong with this? Rather than specifying those fields (DKIM-Domain, DKIM-Identity, and DKIM-Selector) Section 3.2.2 can define header.s and recall the other required tags for DKIM resinfos, while Section 3.1 can further constrain how the second part's A-R should be composed, for example The "authserv-id" token of the Authentication-Results field in the second part SHOULD match the corresponding token of any Authentication-Results field in the third part that was added by the reporting verifier, and MUST NOT match the corresponding token of any Authentication-Results fields in the third part that had been added by some other verifiers. (Ouch, this text is /really/ un-pretty...) _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
