>> 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.
>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 the goal is to get a sample rather than to rate limit, it makes sense. Please say that so you don't get the same complaint the next time someone looks at it. A percentage would be easier to explain and no harder to implement. >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. Don't feel strongly either way. >> 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). You say to use a null bounce address and a HELO with a domain that produces an SPF Pass. I say use whatever bounce address you want, but be sure that it produces an SPF Pass. I don't see any practical advantage to requiring a null bounce address. If it's not null, and the r= address doesn't work, the reporter might get the report bounced back, but if I were a reporter I'd prefer to know if my reports were going into the void so I could stop sending them. R's, John _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
