On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely <[email protected]> wrote:
> On 05/02/2024 00:29, Murray S. Kucherawy wrote: > > On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely <[email protected]> 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? > RFC 7489 says this: In order to be processed by DMARC, a message typically needs to contain exactly one RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain (a single From: field with a single domain in it). Not all messages meet this requirement, and handling of them is outside of the scope of this document. So I don't know what's different now versus when this was written to compel a change in posture. So yes, I interpret this as saying "DMARC ignores it (if it even gets there)", and some other piece of the receiving engine can deal with it. To me the more important thing is that this citation and yours: > 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. > ...are in conflict, and that's what needs resolution. In DMARCbis (Section 5.7.1) we appear to have resolved that conflict and consider such messages out of scope, and DMARC processing ends. I think that's a reasonable choice. What I don't think is that DMARC is the right place to make any proclamation that a multi-valued From should be rejected out of hand, or for any reason that is not derived from the DMARC algorithm. >> 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... > I would prefer to iterate via a future DMARCter than continue to iterate on, and possibly never ship, DMARCbis. RFC7489 seems to imply that DMARC is only used for a fraction of email > messages, such as bank transactions. Where do you observe such an implication? > > 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? > No, it's perfectly fine to declare that DMARC only applies to certain classes of messages. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
