On Friday, December 10, 2021 2:14:36 PM EST Alessandro Vesely wrote: > On Fri 10/Dec/2021 19:58:48 +0100 Scott Kitterman wrote: > > On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote: > >> RFC5322 explicitly allows multiple mailboxes: > >> from = "From:" mailbox-list CRLF > >> > >> sender = "Sender:" mailbox CRLF > >> > >> To completely disallow that syntax seems too harsh. It is true that > >> finding multiple authors is extremely improbable. However, it may > >> happen to have to compose a message with multiple authors, possibly > >> because of legal attribution. In that case, being at a loss for proper > >> authentication makes DMARC look like a sort of toy specification. > >> > >> We can be very stern. For example, we can require that the domain of the > >> first author coincides with the domain of the Sender:, and validate the > >> message as if that was the only author domain. Very stern, but not > >> overly > >> stern. > >> > >> Can we fix this inadequacy? > > > > Ordering isn't guaranteed to be preserved. > > Requiring that it be preserved is part of being stern. The attack path > would consist in putting a second, validated author in such a way that it > goes unnoticed in a (specific) MUA display. The first author is unlikely > to get unnoticed, and we require it to be confirmed by the Sender: field > (half the way toward Dave's proposal.)
That's outside the scope of DMARC. This effort needs to work with email the way it's specified now, not how we wish it to be specified. If you want to change the specification of the 5322.From, this isn't the working group you want. Emailcore is over there --->. > > 1. Do not test for DMARC (current, no backward compatibility issues, but > > incomplete coverage). > > > > 2. Test both and one must not fail (not clear if there are backward > > compatibility or reporting issues, doesn't solve incomplete coverage) > > > > 3. Test both and both must not fail (probably not backward compatible, > > would need to figure out reporting, but does solve the "inadequacy"). > > Case 3 is the most complete and secure choice, but it complicates > implementations and, given the rarity, will likely be buggy. > > Backward compatibility is not a worry in this case. Yes, it is. You don't know if anyone is relying on the fact that RFC 7489 specifies that DMARC is not checked on multi-from messages, so you have no idea what you would break. > > > Given the rarity of multi-From messages and that anything with backward > > compatibility issues should have a high hurdle to clear for inclusion, I > > don't think there's a good case for anything other than leave it as is. > > Leaving it as is, case 0, is the worst option. As I understand it, this "hole" in the specification has existed for years and it's not commonly used to "bypass" DMARC. If that's not correct, let's see some data to that effect. If it is correct, why do you think it will change and this will become a problem in the future? We have enough actual problems to solve without getting diverted fixing things that aren't a problem. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
