Thanks you Doug for a neat analysis.
On Thu 17/Oct/2024 06:16:07 +0200 Douglas Foster wrote:
[...]
Sender authentication is incredibly useful when it is pursued from a
strategy of maximizing PASS instead of hunting for "really bad Fail", but I
have yet to find anyone else using it with this philosophy, and my attempts
to explain it to this group have met continued failure. I know it
is the right path forward because I have spent the last five years building
a solution based on From maximization. Some of the differences between
the document and a successful implementation based on maximizing Pass:
- I apply the DMARC test to every message, not just those with DMARC
policies.
- I never block based on a verification failure. Failures go to
quarantine and are investigated. So I don't have "the mailing list
problem".
Investigation is a rather obscure step. How do you determine whether a message
is wanted? Does it involve human resource? AI? Do you ask the recipient?
Since indirect messages are not sent on a whim, determining the mechanism that
generates them can lead to their identification. In that case, it won't be
necessary to investigate further messages belonging to the same stream.
IMHO, the recipient is the best source of information about the wantedness of
an indirect message. She or he must have taken steps in order for the
underlying forwarding mechanism to be set up.
- When a wanted message does not arrive with Pass, I construct alternate
authentication. DMARC and DMARCbis provide no guidance about handling
false positives, and have nothing to say about alternate authentication
techniques. My survey of the commercial market suggests that the concept
of alternate authentication is not understood by the filtering industry.
Hm... DMARC is based on SPF and DKIM. What alternative authentication methods
do you deploy? Are they fully automated and deterministic?
- Having created alternate authentication for direct flows, the solution
for indirect mail flows has fallen into place: I need to apply the DMARC
test to every organization boundary in the Received header flow. This is
conceptually necessary to avoid both false positives and false credential
upgrades, but it is technically very difficult, so it is my current area of
research and I am optimistic. ARC is a very important tool for this
effort. ARC is the WG's first venture into alternate authentication.
DMARCbis is not sure what to do with ARC because it does not have a prior
history of using alternate authentication methods. Bottom line: ARC is
valuable because it is an available tool for an environment where multiple
authentication tools are needed.
Both Received: headers and ARC sets can be spoofed. ARC can be
cryptographically verified, so the last hop's set, if valid, is reliable. That
is sufficient to identify messages that belong to an known stream.
However, the last hop's ARC signer, in general, is not trusted. The missing
part is the investigation. If we could describe a method to identify the
forwarding mechanism and its wantedness, it'd be straightforward to override
DMARC failures. Meanwhile, we have to resort to heuristic investigation
methods, presumably based on fuzzy data.
The WG wants to fix the mailing list problem. Maximizing Pass has been my
solution, and it works. Warning domain owners that they may not be
appropriate candidates for p=Reject, as our current document does, has not
worked in the past and is unlikely to work well in the future. Instead of
asking sending domains to embrace weak security, why not advise receiving
domains on how to embrace optimal security?
Those are two different points. Discouraging domains involved in relevant
mailing list traffic from publishing p=reject aims at a restricted usage of
DMARC. If everybody were so diligent, DMARC policies could be honored
unquestionably. In fact, it is more reliable for receivers to flag which
domains /are/ so diligent. For example, DMARC fail with d=paypal.com can be
honored unquestionably.
The other point, advising receiving domains to embrace optimal security, is
under the impasse of specifying investigations. I'm not sure a BCP describing
fuzzy methods to alternatively authenticate indirect mail flows would be worth
its salt. Since devising a protocol to have mailing list subscribers confirm
the wantedness of their subscriptions is feasible, I'd rather spend energies on
that.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
