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.
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. 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. 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 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. R's, John _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
