On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote: > On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote: > >> On Jan 19, 2024, at 10:19 AM, Todd Herr > >> <todd.herr=40valimail....@dmarc.ietf.org> wrote: > >> > >> Perhaps the way forward for DMARC is to look for a Sender header when > >> there is more than one RFC5322.From domain and use that for DMARC > >> processing, with the stipulation that messages that don't contain such a > >> Sender header are invalid and should be rejected?> > > Todd, +1 > > > > I like this idea. The 5322.Sender is required for a 2+ address > > Mailbox-list. > +1 as well. Let me note that, in such case, DMARC should require that the > Sender: domain be aligned with at least one of the From: domains. > > Otherwise, disallow should mean reject/ quarantine when at least one of the > From: domains says so. (Same complexity as previous case.) > > Ignoring, as Section 11.5 points out, exposes an attack vector that must be > taken into consideration. That section says: > > [C]are must be taken by the receiving MTA to recognize such messages > as the threats they might be and handle them appropriately. > > What does it mean "appropriately" in that context? It looks to me as a > neatly carved hole in a security filter.
I think this point about alignment of Sender is definitely correct, but it leads me to a different conclusion: Having to evaluate Sender for DMARC adds a pile of complexity for very minimal benefit. We should leave this where it is and move on. Personally, I would prefer we say to do a DMARC evaluation for each From and leave it to the reciever to evaluate multiple policies (if there are two From values and the result for one is pass and the other is fail with a reject policy, it seems pretty straightforward to decide to reject). It would be substantially less complex than adding another header field to the process, but even that is more than this topic deserves. Let's focus on finishing the draft. What's between the current revision and WGLC? Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
