On 05/02/2024 00:29, Murray S. Kucherawy wrote:
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely <ves...@tana.it> wrote:
What do we think has changed since then that warrants reconsidering that
position? Have we started to see multi-value From attacks?
A DMARC filter has to do something when it sees a multi-value From:.
Why? It hasn't so far (i.e., ~10 years).
Not sure what you mean. Certainly, a multi-value From: won't halt the
filter process, so it has to do something. What? Skip the message as
it is out of DMARC scope, which substantially means pass it?
What's the evidence that we have something to fix here? That is, why
is Section 6.6.1 of RFC 7489 suddenly inadequate?
It is not:
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.
We're missing that statement in DMARCbis, aren't we?
AFAIK, we just anticipated such attacks. Their becoming trendy
depends on how DMARC filters are going to be implemented. The
latter, in turn, depends on how we specify DMARC. >
Is it just me, or does that sound like a circular dependency graph?
Specify -> Implement -> Devise attacks. It is not circular, although
you can then have DMARCter...
Another concern is how acceptable it is to specify a standard which
does not admit input which is perfectly valid according to a lower
layer standard. Are they conflicting? >
I would argue that they are not. DMARC can assert that it only acts on a
profile of the layers below it, and anything outside of that profile is
simply not within scope.
RFC7489 seems to imply that DMARC is only used for a fraction of email
messages, such as bank transactions. Nowadays some domains are voicing
to require authentication for each and every message. A rather
different scenario.
If you as a receiver don't like the possible gap that creates, you're
free to do something about it, but you're not doing so under any
normative guidance from DMARC.
Isn't that a specification hole?
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
