DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. But that change would require every unique domain to generate a unique report. Gsuite and Office365 would probably consider that unacceptable.
On Mon, Jan 25, 2021, 1:29 PM Michael Thomas <m...@mtcc.com> wrote: > > On 1/25/21 10:23 AM, John Levine wrote: > >> The list seems to be digging in because no one has raised a use case > that > >> shows a need to revisit the text. This was made worse by asserting that > >> reports must be authenticated, when the text already makes that clear. > > I think the use case is my proposed https reporting. If you think it > > would be useful to allow domain authentication, it's easy enough to > > say that the client SHOULD send a client certificate. Nobody will, but > > every https server and client library I know supports client certs so > > it's not hard to implement. > > Which means that is done completely in bad faith. No thanks. > > > > > I continue to believe that authenticating the domain sending reports > > is of no value, since there is no way to tell what if any connection > > that domain has to the IPs in an aggregate report or the IPs or > > domains in a failure report. If I wanted to send fake gmail failure > > reports, I would register gmail-reports.com and send 100% perfectly > > aligned fake reports from that domain. > > > I send mail to gmail. I send no mail to gmail-reports. If anything you > are demonstrating even further that this is at best underspecified. > > Mike > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
