"Murray S. Kucherawy" <[email protected]> wrote:
>The IESG has the following issue they'd like us to resolve on the DKIM >reporting draft, and the result might also apply to the SPF reporting >draft, before it can be approved for publication. > >"- is rr=all a good default? If a bad-actor sends a supposedly signed >mail with a DKIM-Signature with 1000 fields then what happens if the >Signer's DNS has no rr tag? Maybe some special case for unknown >DKIM-Signature tokens or a max on the number of reports for a single >message? (Note: I'm assuming that a separate report can be, or is to >be, generated for each DKIM-Signature token that fails, clarifying that >only one report is ever sent for one inbound mail with a broken >signature would also fix this.)" > >It's my understanding that we would generate one report per failed >signature, because a single message might bear multiple signatures from >different domains that have different reporting requirements, so the >parenthetical solution won't work for us. A maximum on the number of >reports per message is somewhat arbitrary given that a Verifier can do >them in any order. > >We have a few options here: > >- require an "rr" tag, rather than having a default >- have some default other than "all", chosen from the set of available >report requests > >And we might in addition: > >- add a report request for unknown signature tags > >What does the WG think? The telechat is this coming Thursday, so >having this resolved by then would be ideal. Since a domain doesn't have to publish a record asking for these reports and (as an added bonus) ra= doesn't have a default, there's no worry about reports being generated for domains that don't opt-in. Typically, I think if I needed to moderate volume, rp= would be the right knob to turn anyway. The most I would do is say something like SHOULD NOT generate more than one report to a single domain per message. To the extent there's an issue here, I think that addresses it. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
