Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Alessandro Vesely <[e-mail]>]

On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote:
> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely <[e-mail]> 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.


Best
Ale
--