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.
>>
>> tim
>>
>
>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.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
