Ale is right, the document needs to address the problem. I agree with Google that multiple-From has no important use-case, and therefore a wise evaluator should simply reject the message. For the same reason, I believe the RFC5322.bis group should have deprecated the feature. But since that is not happening, we need to plug the security hole that it creates.
A domain that publishes p=reject needs to be protected from all impersonation attacks, whether the malicious attacker uses one From address or multiple. Consequently, an evaluator must take one of two actions on a multiple-domain From header: 1. Reject the message,. If the message is rejected on other criteria, such as suspicious content, DMARC evaluation is optional. 2. Evaluate DMARC on all listed domains, taking the most restrictive result. 3. Take any action based on local policy. Multi-domain From addresses MAY be omitted from aggregate reports by evaluators who are unwilling to code for this additional complexity. Doug Foster On Sun, Jan 28, 2024 at 8:40 AM Alessandro Vesely <[email protected]> wrote: > On Sat 27/Jan/2024 16:13:08 +0100 Scott Kitterman wrote: > > On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote: > >> > >> 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, > > > Let's also recall there was a proposal to consider Sender: anyway. > > > > but it leads me to a different conclusion: > > > > Having to evaluate Sender for DMARC adds a pile of complexity for very > minimal > > benefit. > > > Yes. > > > > We should leave this where it is and move on. > > > No: substantially, /where it is/ is to ignore. To handle appropriately > means > receivers are on their own w.r.t DMARC.) It is a hole: > > From: [email protected] <lots of whitespace>, > user@attackdomain > > > > Personally, I would prefer we say to do a DMARC evaluation for each From > and > > leave it to the receiver 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 > > > I'm not sure which one is more complex. Evaluating each From: implies a > tree > walk for each domain, while verifying Sender: alignment can reduce that > number. > > However, it is probably better to choose a solution based on semantics > rather > than on complexity. Your solution solves the example above, which is good. > > For Sender:, instead, we need to also require that the aligned domain be > the > one of the _first_ From: mailbox. Such additional requirement preserves > the > principle of end user visibility that led to choose From: in the first > place, > and definitely reduces complexity. > > > Best > Ale > -- > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
