On Wednesday, February 08, 2012 08:07:46 PM Steve Atkins wrote: > On Feb 8, 2012, at 8:02 PM, Scott Kitterman wrote: > > On Wednesday, February 08, 2012 01:06:46 PM Murray S. Kucherawy wrote: > >>> -----Original Message----- > >>> From: [email protected] [mailto:[email protected]] On Behalf > >>> Of > >>> Shmuel Metz Sent: Wednesday, February 08, 2012 1:03 PM > >>> To: [email protected] > >>> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-07.txt > >>> > >>>> It seems to me that providing a mechanism to tell a report > >>>> generator > >>>> to > >>>> knock it off certainly does fit within the second part of that > >>>> admonition. Think of the extreme case where a report generator is > >>>> mailbombing some address extracted by heuristics. > >>> > >>> If it's sending only one report per abusive message received and > >>> sending it to the owner of the source IP then it's not mailbombing. > >> > >> If the reports are for some reason inactionable, then we're already > >> saying elsewhere that they shouldn't be sent in the first place. > > > > Yes, but it's said in context of content analysis. > > > > If you send me reports because someone spoofed my domain and I've not > > indicated somehow that I want those reports (e.g. what's discussed under > > auth failure reporting) then it's inactionable and MUST not be sent. > > > > I really object to an RFC that's going to legitimize random idiots who > > don't understand that SMTP and address spoofing filling my postmaster > > inbox with crap from random spammers that used my Mail From in their > > last spam run. > > > > I would propose adding between 8.6 and 8.7: > > > > 6.5. A report generator MUST NOT send abuse reports to the Mail From > > domain if the message has an SPF result other than Pass, None, or > > Neutral. > > > > This is a special case of an inactionable report that I think is worth > > calling out. > > I'm not sure it is. It's no different from a report in any other format sent > to abuse@wherever. > > Where the problem appears is when someone automates the process. > Those are the people who may be aware of this spec, and those are > the people who'll generate a noticeable volume. It's only those people > developing automation software that most of this is aimed at, and they > are not the ones who need to have SPF explained to them[1]. > > Cheers, > Steve > > [1] Well, OK, some of them are. But they're not going to pay any > attention anyway. Filter their mail and move on, just like we all have > with certain automated reporters already.
That's all true, but I don't think it's not a reason to put it in here. This is the document we're writing on how to do abuse reporting. If we were writing a more global document, I'd want it in that too, but we aren't. The entire document is rife with advice that is also applicable to non-ARF abuse reports, so this is no different in that regard. One of the reasons SPF was created was to reduce the number of bounces people received due to spoofed messages. I feel very strongly we ought to avoid recreating that problem. Scott K _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
