> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Saturday, October 22, 2011 10:58 AM > To: [email protected] > Subject: Re: [marf] New Version Notification - > draft-ietf-marf-authfailure-report-03.txt > > I don't. We only discussed reporting multiple broken signatures, and > apparently concluded that it is too much of a complication for a case > that ordinarily does not happen. (Some domains sometimes sign twice; > you may want to run something like this to find out: > > SELECT d.name, s1.domain, count(*) > FROM signatures AS s1, signatures AS s2, domains AS d > WHERE s1.message = s2.message > AND s1.domain = s2.domain > AND s1.id != s2.id > AND d.id = s1.domain > GROUP BY s1.domain; > )
I have no doubt that there are some domains that sign twice, either on purpose or accidentally. The DKIM RFC even contains allusions to the practice. But I don't see how that leads to changes to the text we have now. > However, having two separate reports for a DKIM failure and the > consequent ADSP failure, provided the r='s match, looks overly > verbose. What do we want to do in such cases? Send three reports. Consensus appears to be that this is easier than coming up with some crazy syntax to try to keep it all contained in one report, especially when these are meant to be machine-processed and not handled by humans; it's not much of a burden. > In addition, forwarding from a central host may be a technique worth > being mentioned, although it's quite expensive compared to syslog. It > may be used for vetting and internal auditing, besides updating > delivery-results, reckoning ri=, and the like. Worth? We haven't prevented that kind of design with the text that's there now, so I don't think any changes are needed there either. It would be an odd thing to do, but the current text doesn't block it. I think we're ready for another WGLC, unless you have other cases you'd like to explore. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
