> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Friday, February 03, 2012 1:43 AM > To: [email protected] > Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-08, was -07 > > > I think we're talking past each other here. What this draft presents > > is a method that amounts to a two-way handshake between someone that > > wants reports about DKIM failures and someone willing to generate > > them. You need to consider both sides of that equation. For report > > generators in particular, simply turning this on without giving any > > thought to the potential for creating a mail storm is possibly a bad > > idea, which means we should provide appropriate cautions. For > > senders/signers, you need to be aware that requesting reports might > > mean you get (legitimately) mailbombed. That's what Sections 8.5 and > > 8.6 try to point out. > > I don't think we are at cross purposes, as we have more matching than > contrasting points. Yet, at times we are unable to understand each > other --possibly my English doesn't help much. > > Define "giving any thought". Auto or manual?
I'll define "without giving any thought" as "install, enable, walk away." > Section 8.5 is about out-of-band arrangements. Quite the opposite; Section 8.5 is about generating reports to anyone that asks for them, rather than sending them to sites that have specifically asked for them. I can improve the language to reflect this. The point is that report generators could be installed to send reports whenever they are requested. For a large email campaign whose signatures all break, this could cause the sender to become inundated with reports. It could also cause the report generator to be overwhelmed generating reports. Both parties need to be aware of this. > BTW, the last phrase: > > data found in the DKIM signatures, which could have been > fraudulently inserted. > > is obsolete now that the data is checked in the DNS. Removed. So here's the pending 8.5: 8.5. Automatic Generation The mechanisms described in this memo are primarily intended for use in generating reports to aid implementers of [DKIM] and [ADSP] and other related protocols in development and debugging. They are not intended for prolonged forensic use. However, such uses are possible by ADMDs that want to keep a close watch for fraud or infrastructure problems. A sender requesting these reports can cause its mail servers to be overwhelmed if it sends out signed messages whose signatures fail to verify for some reason, provoking a large number of reports from report generators. Similarly, a report generator could be overwhelmed by a large volume of messages requesting reports whose signatures fail to validate, as those now need to send reports back to the signer. Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information. In general ARF feedback loop terms, it is often suggested that report generators only create these (or any) ARF reports after an out-of- band arrangement has been made between two parties. This mechanism then becomes a way to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement rather than starting to send them automatically based solely on data found in the DKIM signatures, which may have unintended consequences. > Section 8.6 is about run-time control of traffic. We may solve the > problem or just mention it. Let's see if anyone else is interested. I think I like the idea of common-factoring this into the AS, but I'm watching for others to reply. -MSK _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
