Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

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 <mike@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
>