it's less the shotgun nature of spam and more the sheer volume, maybe that's what you meant. "report as spam" buttons in general see good use because as a rule they're easy to use: one click. when you ask users to do much more than that engagement drops off sharply.
we're creeping up on the first anniversary of dmarc's public unveiling, so both deployment and critical thinking around how to really maximize the value of dmarc reporting are still in the early stages, but this is really why we're pushing adoption so hard at maawg and other venues: we think that with broader uptake will come innovation. From: Raman Gupta <[email protected]> Date: Wednesday, November 28, 2012 5:20 PM To: Paul Midgen <[email protected]> Cc: Roland Turner <[email protected]>, <[email protected]> Subject: Re: [dmarc-discuss] Forensic reports (was Re: Debugging what seems to be strange DMARC XML feedback) > On 11/28/2012 03:28 AM, Paul Midgen wrote: >> One thing mail receivers could possibly implement in the future is to >> give the *addressed recipient* the option to send the forensic report >> to the spoofed sender for verification of the spoof and/or criminal >> action against the phisher. The receiver may also expose the ability >> for the recipient to redact the parts of the email they wish to before >> sending the report. This would sidestep the issue of the addressed >> recipient's privacy rights. >> >> >> this is a very creative suggestion, but there are (at least) three >> reasons we wouldn't make a recommendation around this. >> >> 1. we (dmarc.org) have fastidiously abstained from making suggestions >> to MUA authors. > > Ok. > >> 2. there aren't a large enough number of users (a/k/a addressed >> recipient) at large mailbox providers who would invest this much >> effort into reporting mailbox abuse to make the data useful. it's hard >> to get them to reliably to do other things like report spam. > > Understood. > > Gmail seems to have some success with their "Report spam" button, but > yeah, in general, I suspect usage is limited to a small number of more > technical users. However, given the shotgun nature of spam, it only > takes a small percentage of participating users to gather very useful > data. > >> 3. opt-in rates to reporting of all kinds tend to be low. whether >> we're talking about crash reporting, sending anti-virus scan/sample >> data, or allowing spam complaints to actually be reported. so things >> that further narrow the participant set tend not to get implemented at >> large MBPs. > > See above. > >> don't let that deter you from arguing for it, i'd rather see the >> suggestions made than not maybe someday the attitudes will change. > > Maybe. > >> Are there other implementations in the works leveraging DMARC forensic >> reports that anyone is willing to share publicly? I'm not asking in >> the context of my original post -- this is just professional curiosity >> now. >> >> >> what do you mean by "leverage"? consume and do something useful, or >> generate in the first place? > > Both. I'm just wondering if there are other ideas out there, similar > to the one I tossed out, that would enable forensic reporting in more > cases than it is used now, even if some of these agreements are > private, similar to what Roland mentioned. And for the results of that > reporting to be used in innovative ways to take legal action against > spammers. Obviously, with bot-nets and such, many "spammers" don't > even know they are spammers, but one problem at a time :) > > Regards, > Raman >
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
