On Sun 01/Dec/2024 20:47:31 +0100 Jim Fenton wrote:
[...]
ARC (RFC 8617, experimental) has been discussed as a possible approach
here, but as noted at the end of Section 7.4, has not achieved wide enough
use to be useful here.
ARC, much like DKIM, just provides for crypto-signing messages, additionally
catering for exporting Authentication-Results. There has to be an additional
protocol to state in what cases ARC can be trusted and override DMARC. The
naïve position to always trust ARC is obviously poor, and it is the likely
reason why it is seldom honored.
In 2013, a similar protocol, ADSP [RFC5617], was changed from standards
track to historic, citing limited use and harm caused by incorrect
configuration very similar to the inappropriate use of p=reject described
above. While DMARC has had considerably more use than ADSP, the harm that
has been caused by DMARC is correspondingly higher.
One of the reasons to historicize ADSP was that DMARC was going to replace it.
Now we (the email community) don't have a yet better thing coming up. In fact,
DMARCbis only tweaks a few facets of DMARC without affecting how it works, but,
perhaps more importantly, standardizes it.
Considering the above problems, DMARCbis is neither safe nor effective. It
should not be published as a standards track document by IETF.
DMARC is not the final ultimate solution to the email problem. Perhaps, for
example, someone will deal with recognizing when the friendly frase is at odds
with the actual address, but doing so is only meaningful if we can trust the
actual address. Likewise, more realistically, we can build a protocol to
commit ARC on a per-flow basis, or one to keep track of mailing list changes so
as to validate the original From: rather than munging it.
While the harm caused by DMARC cannot be undone by not publishing DMARCbis,
further work can be assured by promoting DMARC to standard track.
Best
Ale
--
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
