The #2 option (backward compatible with new auth tag) is a good clarification what we were thinking and that Wei mentioned here: https://mailarchive.ietf.org/arch/msg/dmarc/KeGbMfX91WJk_aziKsrRfI6AYkI/
I don't know if there is a better way to encode that, but I'm supportive of making a change that that would allow domains to tell us (gmail) that they prefer us to require both dkim and spf for DMARC evaluation (or whatever combination of DKIM and SPF they desire). /E On Thu, Jun 22, 2023 at 3:38 PM Ken Simpson <[email protected]> wrote: > >> Barry, this is obviously a new relaxation option. From a mail system >> integration standpoint, the options are: >> >> 1) A version bump to DMARC2 with new semantics with backward DMARC1 >> compatibility, or >> >> 2) Use a DMARC1 Extended tag option allowed by DMARC1. Alessandro cited >> an excellent backward compatible extended tag option: >> >> auth=dkim|spf (default value), auth=dkim+spf, auth=dkim, auth=spf >> >> >> > > FWIW, I support the concept above, which would be compatible with DMARC > today. Would anyone from a large receiver like to comment? > > Regards, > Ken > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
