On 7/6/2020 7:27 PM, Jim Fenton wrote:
On 7/6/20 3:41 PM, John Levine wrote:
This proposal makes lists sort through all of the changes they make
and try to figure out which ones match a tag and which ones don't.
That is surprisingly hard, e.g., I found that when you have
multipart/alternative and add a message header, it edits the header
text into both of the alternative versions. Good luck unscrambling that.
Perhaps I didn't explain this clearly enough. Mediators don't need to
sort through changes at all. All they do is check to see if the incoming
message had an aligned signature or SPF, and include a tag in the DKIM
signature that they apply indicating that.
+1. By far, the simplest "ADD-ON" thing to do -- checking the MLM
entry points.
Receiving domains that intend to enforce DMARC would need to verify the
DKIM signature of the mediator, and if the signature came from a
credible mediator and the tag is present, accept the message as though
it had an aligned signature.
+1, this would work. The term "credible" will need to be defined as to
how it is established.
Non-whitelisted local policy Authorized/Trusted resigners has been the
central crux of the problem in the DKIM policy model. It needs to be
automated and we can't get unfocused which the idea that "bad guys"
can also be DKIM/DMARC compliant. Detected "Bad Guys" is a different
dilemma. I believe the of the top goals is to raise the bar for
everyone so that we can get to that secondary Trust/Reputation layer.
The problem has been Signer Reputation wanting to push out DKIM Policy:
Layer 1: DKIM Policy Deterministic protocol
Layer 2: DKIM Signer Trust/Reputation
The argument has always been by Mr. Levine and others, why need Layer
1 of all we need is layer 2?
The answer is that Layer 1 is an deterministic immediate filtering
process to remove the contaminants of a mail stream, similar to an
osmosis process. It includes checking RFC5322 correctness, like double
5322.From lines, to address fake MUA from Display replay concerns.
But the push to use only Layer 1 perpetuated the brush back and
delayed the adjusted needed in Layer 1 to address authorized resigner
issues that Layer 2 will need.
If we go to back DKIM-STD, there was strong cogs efforts to remove or
rather not recognized the Author Domain Identity (ADID) from a future
DKIM Trust Assessment algorithm where only the SDID (Signer Domain
Identity) and optional AUID (Agent User Identity) were parameters to a
trust assessor. I had argued (and lost) that the ADID needed to be
part of the algorithm, officially in DKIM-STD. But the effort was
too strong to remove any recognition of its importance. The cogs had
a hard time doing this because DKIM policy was too strong of a
concept. It would simply not go away. 5322.From could not be removed
from DKIM-STD. It could not avoid the fundamental idea that 5322.From
is the minimum required header to be bound to the signature.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
