> -----Original Message----- > From: Alessandro Vesely [mailto:[email protected]] > Sent: Saturday, October 15, 2011 5:46 AM > To: Murray S. Kucherawy > Cc: [email protected] > Subject: Re: [marf] New Version Notification - > draft-ietf-marf-authfailure-report-03.txt > > 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
Maybe I'm just not understanding it, but this one doesn't seem to address the question we're discussing. > http://www.ietf.org/mail-archive/web/marf/current/msg01418.html This one does, but it doesn't take into consideration the canonicalized DKIM content fields, which might need to be repeated. > 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. You're right, we'd have to register "header.s" as something Authentication-Results can report. But you're also right that this would be enough to indicate results for multiple signatures, since that's what "header.b" was added to do. However, the canonicalized fields might need to be repeated, depending on whether different signatures use different canonicalizations or whether "l=" is in use. That's the complicated part. > 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. I'm not clear on why we'd need to say this. Isn't the specification of the authserv-id already sufficiently clear, and it's obvious you'd need to use it properly and consistently for it to be meaningful? Then again, if the recipient of this reports trusts who sent it, then the authserv-id doesn't really matter. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
