On Monday, January 23, 2012 09:37:49 PM John Levine wrote: > Since Scott says he wants to move this forward, here's some comments: > > In section 3, the r= option lets you specify an arbitrary address, > which is an invitation to remote mailbombing. I have my doubts about > the utility of inviting reports from random strangers, but if you're > going to do it, make it just a local part so you can only mailbomb > yourself.
I agree. I'd like to change this in -03. > The rf= option specifies a report format. The only plausible report > format described in an IETF standard is ARF, and it seems unlikely > that there will others, so lose this option. If you want to make > private arrangements to use non-standard formats, that's fine, but > they don't go into the spec. I'm fine with this. Since this is going into an IANA registry, the same RFC that defines the report type can define this. > The ri=N option asks senders to discard N/(N+1) of the reports they > might generate. It's not clear to me what this is supposed to > accomplish. If the goal is to limit the traffic, I'd suggest making > it the maximum number of reports to send per minute or per hour. Keep > in mind that people sending reports will do whatever they do, so hosts > MUST be prepared to deal with whatever garbage reporters send. Here I disagree. Assuming senders implement this as specified (and yes, I know they all won't) I think some kind of a global fractional rate is better than a per sender volume. In applications where I've seen similar things done in private arrangements, the goal is to get a statistically valid sample of data without putting excessing strain on sending or receiving systems. If you specify X per hour or Y perm minute then low volume senders will send at their normal rate while high volume senders throttle back. This skews the sample data. I find the current method a bit confusing to follow in English, but it would be easy enough to implement in code (I inherited it from the document split out). Describing the rate as a percentage of volume might be a little more understandable. I could see doing either. > In 6.2, it correctly notes that an included SPF record might have an > r= field, inviting all sorts of mischief. I'd suggest adjusting > section 3 to say that the r= ri= and ro= options should be ignored in > includes and perhaps in redirect records. I agree for include: as it's intended to cross administrative boundaries. Redirect is intended to be used within a single administrative structure and the target domain is the same as for the initial record (this is described in paragraph 6.1 of RFC 4408), so I think for redirect it is OK to process them. > I would shrink 6.3 somewhat and just say that the envelope of any > report sent to an address found using the process in this document > MUST have an envelope that produces an SPF Pass. You think that's better than <> for Mail From and HELO/EHLO that Pass? What about the rest of the text? Just ditch it? I'm not sure I'm following you here, so I'd appreciate it if you would amplify (with a proposed 6.3 text). Thanks for the review, Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
