I would submit that it would be in the best interests of mailbox providers and others who are in the business of making acceptance and filtering decisions to ensure that spammers properly authenticate their email, so as to better and more reliably assign a poor reputation to the associated domains and make it easier to identify them.
On Thu, Jan 21, 2021 at 4:42 PM Seth Blank <seth= [email protected]> wrote: > I don't understand this concern. The data in a DMARC report speaks to the > underlying authentication of a message on receipt, and nothing about the > "spaminess" or not of a message as it's processed. > > On Thu, Jan 21, 2021 at 1:00 PM Brotman, Alex <Alex_Brotman= > [email protected]> wrote: > >> Hello folks, >> >> Thought I'd see if we could come to a conclusion on this ticket. The >> gist is that the reporter believes that (aggregate?) reports can help >> spammers to determine some effectiveness of their message attempts. >> >> Full Text: >> ------------- >> Spammers could use DMARC reports to monitor the effectiveness of their >> campaigns, and we do not want to help them. Do existing implementations >> send reports to any domain that requests them, or only to those domains >> that are considered "acceptable"? If reports are only sent to acceptable >> domains, what sort of criteria have been useful? >> >> System administrators will appreciate such advice. Product developers >> will need guidance about the features they should provide so that a system >> administrator can control which domains do not receive reports. >> ------------- >> >> >From an operator side, I don't agree with this assessment. The reports >> do not show if/why a MBP may place a message in the Junk folder. Could it >> be DMARC quarantine? Sure. It could also be any number of things from a >> large matrix of decisions, none of which are shown in a DMARC report. >> Also, the reports are typically sent once per day (seems like most ignore >> the 'ri'), quite likely some time after the end of the reporting period. >> Additionally, they probably have more efficient/immediate methods of >> evaluating their success rate. >> >> If you believe something has been overlooked, please feel free to share. >> >> -- >> Alex Brotman >> Sr. Engineer, Anti-Abuse & Messaging Policy >> Comcast >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > > > -- > > *Seth Blank* | VP, Standards and New Technologies > *e:* [email protected] > *p:* 415.273.8818 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
