On Sun 05/Dec/2021 04:23:45 +0100 Scott Kitterman wrote:
On December 4, 2021 10:09:48 PM UTC, Seth Blank
<[email protected]> wrote:
On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski <[email protected]> wrote:
I am Ok with adding text of this nature, and I think it's helpful in
explaining to folks approaching DMARC for the first time. But I start to
lose focus on reading long introductions (okay boomer). >>>
Maybe the Intro could get a section or two to help focus it.
I am glad to assist wordsmithing Doug's comments if that is useful.
as an individual, I don't like the wording that Doug has provided at all. I
think I understand what he's trying to say, but the text as proposed is far
more confusing than clarifying.
Further, with SPF and DKIM, it is explicit that you can treat a pass in
certain ways, but that you are to make no such determination when the
authentication method does not pass. But DMARC is explicitly about
providing policy when the auth methods do not validate in an aligned
manner. So, while we all know there are legitimate reasons such validation
might fail, this language feels out of place in DMARC because addressing
these failures is the purpose of the protocol.
As chair, if the group believes some clarification is still needed here,
that makes sense and follows from similar text in the other auth methods.
My ask would be that it provides clarity to address operational matters,
per the charter for this phase of work.
I don't think marketing materials belong in the document. If you want to give
an overview about utility and usage of DMARC, then it should be something about
it being super useful and low risk for automated transactional email, but there
are substantial false positive risks for email sent from people.
From a practical POV, a filter can reject or pass a message. So quarantine
means pass but with Authentication-Results pointing out the fact, so that local
delivery scripts can take are of it.
What I would add, perhaps in an appendix, is the usefulness of a domain
database that the filter leans on. Besides feeding aggregate reports, a
database allows users to dynamically enable/ disable DMARC per domain, as well
as to whitelist or kill-on-sight specific domains.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
