On Monday, January 23, 2012 04:55:48 PM Murray S. Kucherawy wrote: > > -----Original Message----- > > From: Frank Ellermann [mailto:[email protected]] > > Sent: Wednesday, December 07, 2011 5:29 PM > > To: Murray S. Kucherawy > > Cc: [email protected] > > Subject: Re: [marf] DKIM reporting > > > > Some quick observations: s/4871/6376/, s/sender/signer/ (or whatever > > is state of the art in DKIM terminology), and maybe say "alleged > > author" if that is the correct ADSP term. > > Fixed (though there were only a few). > > > It was straight forward to > > find _where_ the marf-reporting-discovery will find its TXT, for marf- > > dkim-reporting it took me some time to check RFCs 6376 + 5617. I think > > (could be wrong) that I understand the ADSP part, but I'm less sure > > about the DKIM part. > > Hopefully the DKIM part is simpler, since it doesn't involve DNS at all > anymore. It's all now signature tags. > > For ri=1 (non-zero) how long are receivers expected to wait for another > > incident? If you want ri=9, and I get only 8 broken signatures within > > a day, does this mean that you want no report because 8 is less than 9? > > The syntax of this has changed now to specify a count and an interval. The > thrust is for "X/Y" you specify you want no more than X reports in Y > seconds. As long as sending another report now would not exceed that > limit, send away.
I think the discussion on the SPF draft re using a percentage instead of X/Y is germane for this draft as well. I think they should do it the same way (and I like a percentage better). > > Or do you want no second report before I got 2*9 broken signatures, no > > matter how long it takes? It is not clear for me why receivers would > > ever wish to follow detailed instructions about their reports, even > > including MUSTs and MUST NOTs in section 5. > > The point there is to give guidance on what to do if you're given a request > for a "foobar" report when you don't know what that is, just like in DKIM > we told people to ignore signature tags they don't know about. You're > right about the MUST NOT though. > > For ADSP ro=u I'm not sure what it is, is this simply "all minus ro=s"? > > Should the ADSP ro=u explanation (5.2) say "and" instead of "but"? > > Yes, fixed. > > > The rf=smtp + rs=... magic is apparently something in the direction of > > the SPF exp= magic. Or maybe not, please add more than one example for > > rf=smtp + rs=... tricks (or a pointer if this is explained elsewhere.) > > "rf" has been removed. > > > For ADSP + DKIM the marf-reporting stuff should fit into the relevant > > TXT records, for SPF I'm not sure. If you (= the WG) intend to create > > a general _report discovery mechanism it would be confusing to create > > additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I > > have no idea or opinion what's better (specific vs. general _report). > > Scott's handling the SPF stuff now, so I'll leave it to him to comment > there. I think the reporting modifiers we're proposing to add will only have a very modest impact on SPF record size and I've yet to run into a situation where overly large records were needed for SPF (people produce them all the time, but they can, IMO, always be redone to avoid the need). I don't see the modest expansion in record size as an issue. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
