On Friday, December 10, 2021 2:18:47 PM EST Todd Herr wrote: > On Fri, Dec 10, 2021 at 1:59 PM Scott Kitterman <[email protected]> > > wrote: > > Ordering isn't guaranteed to be preserved. I think the options are: > > > > 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"). > > > > 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. > > To be clear, what's "current" is what's in RFC 7489, which reads: > > The case of a syntactically valid multi-valued RFC5322 > <https://datatracker.ietf.org/doc/html/rfc5322>.From field > > presents a particular challenge. The process in this case is to > > apply the DMARC check using each of those domains found in the > > RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field > as the Author Domain and apply the most strict > policy selected among the checks that fail. > > > Option 1 above is proposed in DMARCbis as a way to mitigate the risk of a > DoS attack by a bad guy inserting a From: header with umpteen domains, each > of which would have to be checked.
Thanks. I had lost track of that. In that case it might be better to impose a limit (two maybe) to check rather than toss out the check entirely? Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
