On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely <[email protected]> wrote:
>On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote:
>> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely <[email protected]> wrote:
>>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote:
>>>> My recollection is that a general formulation that I proposed had at least
>>>> some traction out of both groups:
>>>>
>>>>> [some appropriate description] domains MUST NOT publish restrictive DMARC
>>>>> policies due to interoperability issues
>>>>
>>>> Leaving aside (for now) the question of what goes into [some appropriate
>>>> description] and with the assumption that there will be some non-normative
>>>> discussion to amplify whatever that is and probably give some indication
>>>> about what domains might do to not be one of those domains, is there
>>>> anyone who just can't live with that formulation of the situation?
>>>
>>> Me, for one. Because more than 98% of domains are going to fall into the
>>> description, however we word it, that statement makes the whole I-D
>>> nonsensical. Cannot we just tell the problem without MUSTard?
>>>
>>> In any case, using the complement of [some appropriate description] is
>>> certainly easier. For example:
>>>
>>> Forcing authentication into Internet mail by publishing restrictive DMARC
>>> policies breaks some well established patterns of usage. Publishing such
>>> policies is thus RECOMMENDED only for domains [in this other appropriate
>>> description].
>>
>> Thanks.
>>
>> I understand your objection to be that the proposed description of the
>> interoperability problems would apply to too many domains, regardless of the
>> modifier we might use. Is that correct?
>
>
>Nearly. Too many would be 40%. 98% is practically all. Indeed, we're
>talking of mailboxes used by humans...
>
>
>> I don't understand the technical issue associated with that objection. I
>> get that you feel the construction is too negative, but I don't have a sense
>> you think it's inaccurate. Focusing on the technical aspects of this, would
>> you please help me understand what you think is technically incorrect about
>> it?
>
>
>Perhaps MUST NOT would have some sense if DMARC were breaking a well known
>protocol. The established patterns of usage we break are in turn breaking
>some other RFCs, aren't they?
>
>Why would the applied workaround have less merit than the original hack, from
>a formal POV? I mean, if we stand by the letter of the protocols so much as
>to feel the need to say MUST NOT.
>
If we think internet standards are meaningful, then if the applied work around
directly conflicts with an internet standard (which From rewriting does: RFC
5321 and predecessors), then it he as substantially less merit.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
