On Feb 9, 2012, at 10:14 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Alessandro Vesely >> Sent: Thursday, February 09, 2012 9:03 AM >> To: [email protected] >> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt >> >> The whole snippet quoted above seems to be somewhat misplaced, as those >> are all cases of "mechanical reports" that the concluding sentence of >> that paragraph discourages. > > The methods listed in 8.1 all name things that warrant corrective action. > User submission are active demands for corrective action; mail arriving at > spam traps and honeypots are always either from spammers or poorly managed > mailing lists, and virus false positives are (as far as I know) few and far > between. What we took out was spam filtering and authentication failures, > both of which are far more FP-prone. > >>>>> 8.6 implies that the d= domain is always a good place to send an >>>>> unsolicited report if it leads to a deliverable email address. Is >>>>> that what we mean to say? >>>> >>>> No. A "reasonable candidate" implies a few attempts can be done. >>> >>> I'm not sure what you mean there. >> >> Even if the d= domain is a reasonable candidate, one should stop >> sending reports if any of the following is determined to be true: >> >> * abuse@domain is undeliverable, >> * nobody acknowledges the reports (paragraph 13), or >> * the recipients opt-out (paragraph 5). > > Don't we already cover those cases, then? > >>> 8.6 fairly strongly implies that the only reason that a DKIM d= might >>> not be an appropriate place to notify is if the d= is being used to >>> distinguish reputation streams. That's only one of several reasons it >>> may not be a reasonable candidate. >> >> Abusive parties (paragraph 14) make another class of unreasonable >> candidates. > > Added to the end of 8.6: "..., or the verified domain is a fake and > discardable domain created by a bad actor for the purpose of sending abusive > mail." > > Anything else?
One common case is where the d= domain is that of the entity owning the mailing list and generating the content, while outsourcing the delivery of the mail to an ESP. In those cases (and it's a very common case) notifying anyone other than the ESP is probably a waste of time, while notifying the ESP will be extremely effective. I'm not sure whether we want to try and teach people what some decent heuristics are, or just put in enough suggestions to mitigate the harm done to others if they get it wrong, though. Cheers, Steve _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
