On Friday, December 10, 2021 2:24:12 PM EST Scott Kitterman wrote: > 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.
So, based on Todd's email that I failed to read before I sent this, please ignore this. It's wrong. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
