On 3/31/2023 12:49 AM, Barry Leiba wrote:
I don't see any hope that people will back away from the perceived security
benefits of DMARC to
accommodate mailing lists, even if we publish Barry's language.
But here's where we're missing my main point, so I'll highlight it:
The spec needs to say what the right thing is for the protocol to do,
and what the right way to deploy it is to avoid damage to existing
services. "MUST NOT use p=reject for a domain that hosts
general-purpose user email" is the right thing to say. Saying the
right thing is not dependent upon whether some large senders will
decide not to abide by it -- they have the right to make their own
decisions, and whether they back away or not isn't the point of this
text. We should not have an IETF proposed standard that can knowingly
break existing services without strong normative text that warns
against deploying it that way.
+1
I feel your frustration as well. But if you really feel that way, we
need to deprecate, begin the process of abandoning DMARC and begin
focusing in other directions. But there is a solution.
We can save DMARC by adding ATPS support to it. A simple tag -atps
tell the verifier to check for a signer ATPS authorize record. Alll
ESPs can do a 2nd lookup. Thats not a scaling issue.
ALL ESPs, like you said, can not be a strong DMARC domain for outbound
mail because their end users are very loose with their domain usage.
But Yahoo.com is doing it and I think it helps smaller domains not get
hurt from bigger ESPs spam. But this only works if they ALSO support
ATPS on the receiving side as well!!!
What will a ATPS concept do? I think if we want to finally end this
near 20 year project:
- DKIM-BASE, no changes
- Add ATPS concept to DMARCbis
- Add VBR concept because it is a reputation model as a function of
ADID and SDID.
- Push ARC aside. It is not DKIM and way too much overhead and
clearly, it can not be the replacement solution for not doing ATPS.
For most domains in the market, DKIM. DMARC and ATPS is enough for
deterministic evaluation. For most emails transported, a DKIM VBR
would address an IETF centralize reputation solution and also the
potential business market as Levine wanted with VBR. The DNS order
lookup would be:
- SPF
- DKIM
- DMARC
- ATPS
- VBR
But we continue to have the reputation model being pushed over policy
and we continue to have this problems.
In regards to the text, I think MUST NOT is appropriate but it must
explain why. If you consider the above, then the text will change:
MUST NOT if no 3rd party signer solution is in place.
Then reference ATPS in the IETF manner for a proposed experiment.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
