Option 1:. Change spec to require DMARC evaluation on all From domains. Will an individual who is constructing a multi-from message be able to ensure that the message pases DMARC on all of the names! Not likely. So multi-from depends on non-verification and is therefore out of scope. Supporting multiple domain evaluation would also add a lot of complex and rarely used code to every implementation.
Option 2:. Decide the best way to declare multi-domain From as out of scope. As you indicated, neither PASS nor FAIL nor NO POLICY fit the situation perfectly. PERMERROR does. On Tue, Nov 15, 2022, 7:03 AM Alessandro Vesely <ves...@tana.it> wrote: > On Tue 15/Nov/2022 11:59:42 +0100 John Levine wrote: > > It appears that Alessandro Vesely <ves...@tana.it> said: > >>They still do: > >> > >> 550-5.7.1 [62.94.243.226] Messages with multiple addresses in From: > header are > >> 550 5.7.1 not accepted. > ht21-20020a170907609500b0078e1e77f443si1407469ejc.418 - gsmtp > >> > >>The question is whether they do so because of what we say or if we say > so because of what they do. > > > > Whatever the reason, this reminds us that multi-address From headers are > a > > tiny tiny nit, not worth the time we've spent on them and certainly not > > worth any more. The existing language isn't broken and there is no need > to change it. > > > No. We can see that either you violate standards by blocking à la Gmail, > or > you're open to attack schemes based on exempting messages from DMARC > evaluation. I'd call that broken. > > > Best > Ale > -- > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
