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<dotz...@gmail.com> 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<skl...@kitterman.com> 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
On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote:
I'm happy with that suggestion.
Barry
On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman<skl...@kitterman.com>
wrote:
Would you feel any better if the MUST NOT was followed by 'to preserve
interoperability '? That's implicitly there and I believe technically
correct. If you value other properties of the system higher than
interoperability, then the advice may not apply, which is fine.
Scott K
On March 29, 2023 3:32:10 PM UTC, "Brotman, Alex"
<Alex_Brotman=40comcast....@dmarc.ietf.org> wrote:
I’m just not sure how we determine what is high-value.
comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine
The top one is corporate, middle is consumer, bottom is consumer (but
not
actually used) & customer comms (sub-domains). They’re all used in
various ways for internal messaging. Should I tell our corporate
admins
that they need to no longer publish p=reject? They’re violating the
RFC
by doing so? There are very few consumer-oriented messages that
originate from comcast.com. Are we doing it right? It makes things
a
little harder when one of our employees wants to use a mailing list.
But that still feels like the right thing to do.
If it’s not obvious, I’m having a hard time with “MUST NOT”, and
dictating to domain owners what is in their best interests, regardless
of our perceived value of their domain.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc<dmarc-boun...@ietf.org> On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr<todd.herr=40valimail....@dmarc.ietf.org>
Cc:dmarc@ietf.org
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail
flows
I'm very much against text such as this, as I think it encourages
deployments that are contrary to interoperability and to the intent of
p=reject.
I contend that p=reject (as with the similar construct in the older
ADSP)
was intended for high-value domains and transactional mail, and that
it
was never intended for use in domains where general users send general
email.
I stand by the MUST NOT that I proposed.
Barry
On Wed, Mar 29, 2023 at 10:33 PM Todd Herr
<todd.herr=40valimail....@dmarc.ietf.org<mailto:
40valimail....@dmarc.iet
f.org>> wrote: On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick
<resn...@episteme.net<mailto:resn...@episteme.net>> wrote:
If you agree that interoperability is increased, then I'd suggest that
you actually do agree that the proposed text is appropriate.
I don't know that I agree that interoperability is increased...
I'm having trouble squaring proposed language that says "Domain owners
MUST NOT publish p=reject because it breaks interoperability" with the
following language from section 5.8:
Mail Receivers **MAY** choose to accept email that fails the DMARC
mechanism check even if the published Domain Owner Assessment Policy
is "reject". In particular, because of the considerations discussed
in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT**
reject
messages solely because of a published policy of "reject", but that
they apply other knowledge and analysis to avoid situations such as
rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.
It seems inconsistent to state with certainty that authorized mail
will
be rejected due to authentication breakage when there is no
requirement
that a reject policy be honored (and we have plenty of evidence that
Mail Receivers are following the 'SHOULD NOT reject messages'
guidance).
Language that would be more consistent in guidance to the domain
owners
might look something like this:
After careful analysis of the aggregate report data as described in
section 5.5.5 (Collect and Analyze Reports), Domain Owners **MAY**
choose to change their policy from 'none' to 'quarantine' or 'reject'.
If, in the Domain Owner's judgement, unauthorized and deceptive use of
its domain name in the RFC5322.From field puts at risk the trust it
has
built with its recipients, then it is **RECOMMENDED** that the Domain
Owner make use of the p and/or sp tags to set policy to 'quarantine'
or
'reject' for those streams most at risk of loss of trust.
If going that route, probably want to consider expanding on 5.5.5,
too; I
need to think about it some more.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
