> On Mar 30, 2023, at 10:16 AM, Todd Herr
> <todd.herr=40valimail....@dmarc.ietf.org> wrote:
>
> My fear is that adding further text to DMARCbis that says "MUST NOT use
> p=reject" along with the new language in Policy Enforcement Considerations
> results in a spec that says:
> As a domain owner, you can request treatment for unauthenticated mail, but
> your request may not (and probably will not) be honored, and by the way
> You mustn't request treatment anyway
> The next step in that path is a world where the p= tag loses its usefulness
> as a proxy for where a domain owner is in its authentication journey, because
> everyone's at p=none, because DMARCbis says so.
>
> At this point, DMARC becomes useless, because one of two things happen:
> Failed authentication loses its meaning as a signal because no one knows
> whose authentication policies are thought to be solid and whose aren't, or
> Failed authentication is given more weight than it should be given because a
> DMARC record becomes a de facto p=reject, because no one knows whose
> authentication policies are thought to be solid and whose aren't
> Anyway, this is why I continue to support the idea of describing the
> interoperability issues, but opposed to the idea of telling domain owners not
> to use p=reject.
>
A domain should not use a policy that will cause problems. However, even for
domains that are private, it may not have control of target mail MX, the
hosting MSA, MTA, MLS involved nor what the final MDA will do. The reputation
of the MTA is hurt too with p=reject. We have to clean the mess up of the
domain p=reject mail senders in other to transport their mail.
DMARC policy model has been useless for the same reason ADSP — lack of a 3rd
party (re)signer authorization. Same problem. We abandoned ADSP for this
reason. The only key difference DMARC offered is reporting and imv, it’s the
only reason it is still alive. If its going to replace ADSP as far as policy
is concern, then it should to fix the problem offer something more that deals
with the problems and not just leaving hanging for the network to fix.
DMARCbis should come with a MUST NOT when additional information to help the
receiver what to do when failure occurs is not available.
I propose two tags:
-rewrite
says if the first initiate signer succeeded and you need to resign, then you
are allowed to rewrite the ADID. This handles list distribution problems.
If a domain does not have -rewrite, a subscriber and list submission MUST be
denied.
-atps
says if ADID does not equal SDID then do an SDID ATPS lookup at the ADID zone.
This handles reception for all mail. If a domain does not have -atps, then the
receiver MUST honor the domain reject policy for failures.
This allows you to keep your strong DKIM Policy advocacy like many here are,
like me.
DMARC did one thing good.
When we started all this in MARID, all the new DNS-based applications proposed,
SPF, DKIM, ADSP and many other LMAP protocols explored, we all knew it will
take many years before we can begin to measure the payoff with receivers
performing the DNS Lookups we needed them to do. With DMARC, I believe we know
have the receiver lookup market penetration to justify an additional ATPS
lookup piggybacking off the DMARC record lookup.
We can do a lot more to resolve many of the problems we had.
But it always came to the question, why can’t reputation do this in lieu of
policy?
Well for obvious reasons. There is no standard and there are too many false
positives and erroneous labeling of bad guys. Different receivers can have
different assessment methods or none at all (most of us), making small systems
targets of DKIM spoofs, replays. The Batteries Required syndrome.
However, reputation is needed as a layer after the DKIM Policy is done. We have
VBR. What’s wrong with it?
Even providing a new DMARC extended tag
-trust:acme-trust-service
Can tell the receiver to do a trust check on the signer domain. It does not
mean the receiver would honor the trust results but maybe it could help systems
with the mail handling.
—
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
