I suggest that it is time to propose that RFC 5322 section 3.6.2 be revised to drop support for multiple From fields. The market has clearly spoken that there the feature is not needed. Every MUA that I have used is designed to solicit From and Friendly Name as separate and single-occurrence fields. Similarly, those MUAs present Friendly Name and >From as separate fields, with no evidence that they are designed or tested for lists.
On the technical side, From headers are difficult to parse even with a single address. The address is not consistently enclosed in angle brackets, and the Friendly Name is not reliability enclosed in quotes. Then one has to add the complexity associated with internationalization, and the possibility of local-parts that are quoted strings. I cannot help expecting that some multi-address From lists will simply be mistaken as a complex Friendly Name with a single From address. Of course, an RFC 5322 revision will not happen quickly if ever, and we do not wish to hold our document or our breath waiting for that to happen. But I would like the issue documented. For our document, I think the chairs need to answer the question, can we mimic RFC 7489 by having text that deprecates address lists, as long as we don't prohibit it? I am thinking something like this "Senders should be aware that although RFC5322 allows a message list, few messages actually have more than one address, and as a result recipients may not recognize or accept messages with multiple From addresses." For evaluators that want to both accept such messages and fully evaluate them, it is impossible to argue against checking every address as the most complete security review. In that since RFC 7489 is correct. But I prefer language that says to evaluators, "if you want to accept these messages, do it any way you want since it is at your own risk" Otherwise, product developers may put a lot of effort into code that is rarely used and poorly tested, simply to comply with the specification. For reporting purposes, I think we can require that only one address be used per message, if such messages are reported at all. Doug I On Fri, Dec 10, 2021 at 2:19 PM Todd Herr <todd.herr= [email protected]> 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. > > -- > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* [email protected] > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
