Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Neil Anuskiewicz <[e-mail]>]

> On Apr 8, 2023, at 3:28 PM, Scott Kitterman <[e-mail]> wrote:
> 
> There are several variations of text that roughly mean the same thing, 
> particularly when you keep in mind that IETF specifications are intended to be 
> interoperability specifications, not implementation specifications.
> 
> We could do I think any of the following and they are roughly semantically 
> equivalent:
> 
> [general purpose]* domains MUST NOT publish p=reject to preserve 
> interoperability
> 
> to preserve interoperability, domains SHOULD NOT publish p=reject unless they 
> are [not general purpose]* domains
> 
> which could be accompanied by:
> 
> [not general purpose]* domains SHOULD determine their email authentication 
> deployment is accurate and complete before publishing restrictive policies 
> (p=quarntine or p=reject) to avoid interoperability issues.
> 
> Publishing DMARC records with restrictive policies does cause interoperability 
> problems for some normal email usage patterns.  Potential impacts MUST be 
> considered before any domain publishes a restrictive policy.
> 
> * whatever the right formulation is, that's a related, but distinct (and I 
> think less controversial question).
> 
> I think there's enough there for everyone to find their preferred answer.  I 
> think it's clear on the interoperability risks, but the last MUST allows for 
> the realist case that people are going to do it anyway.  I have no preference 
> between the first two alternatives.
> 
> 
> 
>> On Saturday, April 8, 2023 5:12:56 PM EDT Mark Alley wrote:
>> Re-looking at the definition of "SHOULD NOT", I don't see why it can't
>> be considered.
>> 
>> "SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
>> there may exist valid reasons in particular circumstances when the
>> particular behavior is acceptable or even useful, but the full
>> implications should be understood and the case carefully weighed before
>> implementing any behavior described with this label."
>> 
>> Seems to fit perfectly with how domain owners currently can pick and
>> choose interoperability with p=none over more strict protection, or vice
>> versa with p=reject, in my opinion. Is that not considered "acceptable"
>> by this definition's context?
>> 
>>> On 4/8/2023 4:10 PM, Scott Kitterman wrote:
>>> Possible.  I didn't count.
>>> 
>>> I didn't see any convergence towards an alternative.
>>> 
>>> I think adding explicitly that the MUST is related to interoperability
>>> reasonably addresses the concern that there are non-interoperability
>>> reasons people are going to publish p=reject despite the side effects.
>>> 
>>> I don't see a stronger consensus for a specific alternative.
>>> 
>>> I think we have exhausted the discussion on the topic, so, whatever the
>>> resolution, I'd like to see the chairs drive the question to closure. 
>>> It's pretty clear it's not going to naturally drift into a universal
>>> consensus.
>>> 
>>> Scott K
>>> 
>>> On April 8, 2023 8:58:13 PM UTC, Dotzero<[e-mail]>  wrote:
>>>> Going back through the thread I find more people questioning/disagreeing
>>>> with the proposed wording than agreeing with it. I don't see a rough
>>>> consensus.
>>>> 
>>>> Michael Hammer
>>>> 
>>>> On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman<[e-mail]>  
> wrote:
>>>>> We've gone nearly a week without any further discussion on this thread.
>>>>> 
>>>>> I reviewed the thread and I think this is the closest we got to anything
>>>>> (most) people agreed on.  I know not everyone liked it, but I doubt
>>>>> we're
>>>>> going to get closer to a consensus on this.
>>>>> 
>>>>> Can we adopt this and move forward on to the next thing?
>>>>> 
>>>>> Scott K

Yes, I think so.  I get the feeling you possibly think it’s text that isn’t going to make much of an impact but presumably it’ll at least make a difference at the margins? The margins can grow as others see the benefits. I don’t know.

Neil