On Mon 06/Dec/2021 17:40:47 +0100 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 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.
That's very generic and almost works. Could we add "peculiarity" (or a better
word) for cases where there's nothing wrong but amendments are possible? That is:
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 peculiarity, misconfiguration or omission the Domain Owner can
take steps to address such failures.
For example, DKIM signing with strict/strict canonicalization is not a
misconfiguration, but switching to relaxed/strict can survive a forwarder which
reflows header fields.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
