On Monday, December 6, 2021 11:40:47 AM EST Todd Herr wrote: > On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman <[email protected]> wrote: > > On December 6, 2021 1:35:10 PM UTC, Todd Herr <todd.herr= > > > > [email protected]> wrote: > > >On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely <[email protected]> wrote: > > ... > > > > >> Should any overlooked systems be found in > > >> the > > >> > > >> reports, the Domain Owner can adjust the SPF record and/or > > >> configure > > >> DKIM signing for those systems. > > >> > > >> I'd s/overlooked systems/failures/, since surprises can also arise from > > >> systems > > >> that the Domain Owner considered to have been set up well. > > > > > >How about: > > > > > >"Should any authentication failures for systems under the Domain Owner's > > >control be found in the reports, the Domain Owner can adjust the SPF > > > > record > > > > >and/or configure DKIM signing for those systems." > > > > Have mercy for the poor admins whose bosses will waive this at them and > > demand they "fix" all the issues in their failure reports. Most cases of > > DMARC failure are outside the control of the sending domain and this > > doesn't seem to acknowledge that at all. Yes, maybe the DNS group decided > > one day to prettify their zone files by lower casing everything and now > > everything is getting a DKIM fail, but usually it's a problem elsewhere. > > > > Maybe add "caused by local misconfiguration or omission" after > > authentication failures? > > In the interests of future-proofing, should there ever be additional > underlying authentication protocols, I propose this: > > Should any authentication failures for systems > under the Domain Owner's control be found in the reports, in cases > where the failures are caused by local misconfiguration or omission > the Domain Owner can take steps to address such failures.
I think that's good. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
