I'm not sure whether the feature being requested is a) providing the sender with another DMARC tag to specify that they only want aggregate reports to include failures, or b) receivers, at their discretion, being able to choose to only report failures.
I can imagine a valid use case for a), but not for b). On Tue, Jan 21, 2014 at 2:04 PM, Popowycz, Alex <[email protected]>wrote: > The more that’s left up to the receivers as to what does/does not end up > in the aggregate report, the less valuable those reports become. As it > stands already, it’s difficult enough to compare the results coming from > receivers today let alone having the reports become even more fragmented > and less deterministic. Is this suggestion being driven by work effort > concerns (in creating a “complete and accurate” aggregate report? > > > > True, the reporting recommendations are fairly open in the specification, > but an intrinsic value of DMARC is reduced (IMHO materially) if the reports > are diluted. > > > > > > > > *From:* dmarc [mailto:[email protected]] *On Behalf Of *Franck Martin > *Sent:* Tuesday, January 21, 2014 4:21 PM > *To:* Murray S. Kucherawy > *Cc:* [email protected] > *Subject:* Re: [dmarc-ietf] Limiting what goes in aggregate reports > > > ------------------------------ > > *From: *"Murray S. Kucherawy" <[email protected]> > *To: *[email protected] > *Sent: *Tuesday, January 21, 2014 12:55:26 PM > *Subject: *[dmarc-ietf] Limiting what goes in aggregate reports > > > > I've received a feature request for OpenDMARC to limit what goes into > aggregate reports. Specifically, the suggestion is not to store any data > regarding messages that pass the DMARC test and thus only report on things > that fail. > > I don't believe the current specification says anything requiring that all > messages be recorded, so I think this wouldn't violate the specification, > but it might violate the spirit of what was intended or what's desirable to > Domain Owners. > > Comments? > > > > I think it is starting to build too much complexity in what receivers must > do to generate aggregate reports. We should keep it light for receivers, it > is up to senders to process the data. > > > > It seems important to me to be able to look at the ratio pass/fail to know > if you have a phishing problem, or if you have something in your > infrastructure that would reject too many good emails, compared to your > phishing problem, if you move to an active policy. > > > > I think the spec should indicate, if not done already, that the receiver > SHOULD(MUST?) report all emails in the aggregate report, but if people > decide to go for this proposed option then at least notify it dumped some > certain categories. > > > > However if you don't have the report of emails that pass, how do you find > sending IPs that may have your DKIM key? > > > > So I'm not for limiting what goes in aggregate reports. > > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
