The volume of current attacks should not be a consideration, and speculation about future risks is vacuous. The industry routinely raises C.V.Es against newly discovered and not-yet-exploited security holes, and we should act the same way.
The evidence from Google is that multi-valued From DOES have usage and is usually malicious. That should be sufficient evidence to conclude l that the security hole must be plugged, not ignored. Doug On Mon, Feb 5, 2024, 1:23 PM Alessandro Vesely <ves...@tana.it> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
