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.)
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.
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. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
