On 4/25/2023 10:06 PM, Scott Kitterman wrote:
On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote:
On 4/25/2023 9:06 PM, John Levine wrote:
PS: If anyone was going to suggest we just tell people how to change
their mailing lists to work around DMARC, don't go there.
I don't follow.
A "no change" recommendation caused problems. The current fix is:
1) "Rewrite From" to tear down restrictive DMARC security,
2) Prevent Subscription/Submission of restrictive DMARC domains.
#1 is undesirable. Empirical practice on a different internet has shown when
following #2, for an existing list with members with restrictive domains, they
will essentially become Read-Only List members because any submission/reply by
them will be blocked.
Hector,
I think we all understand that there are things mailing lists can do to
mitigate the interoperability impacts of DMARC. I don't think it's germane to
the current question. Please, let's stay focused.
I honestly don't follow the PS. What is the question? Where are we
not suppose to "go there" to?
Let me ask, is DMARCbis going to be intentionally ambiguous about
these long time inherent protocol problems? Just like ADSP was? Or we
just want it to be open ended - say nothing? I don't know. We do
that. But not like this, for so long. I just wish to finally close
some of the most obvious loop holes and reduce false positives with
well defined options like done with SPF. SPF has a way to offer 3rd
party machines. DMARC also needs a way to offer 3rd party signers.
Something like a simple DMARCbis endorsement would work wonders:
Verifier MAY check|explore|consider|implement an extended technology
for ADID::SDID authorization. There are a number of concepts
available
using a DNS or non-DNS approach to verifier the association, if any.
The following proposals are available:
Personally, I think it should be reduced to two simple approaches,
described in IETF fashion:
ATPS - Murray's protocol. Brilliant. Simply wasn't promoted.
VBR - Levine's protocol. Also brilliant. Why was it not used?
A published DMARCbis will most likely not going to change again for a
long time. So it should recognize in this draft document, the need to
help close the loop holes ADSP failed to do causing it to be
abandoned. DMARCbis risk the same sound engineering challenges.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
