On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF and DKIM
support, and to support senders that want to drop SPF as one of their DMARC
authentication methods to avoid the SPF upgrade vulnerability. We could
have a DMARC policy tag for authentication e.g. "auth=" that describes the
permitted authentication methods the sender supports and receiver MUST use
for validation. DKIM or SPF are represented as tags "dkim" and "spf", and
if multiple tags are present then they are comma separated and any one
passing is considered passing authentication. Also at least one
authentication method MUST be present. Other authentication methods could
be added in the future as it is our hope that there will be some other
authentication method to improve upon and someday replace SPF. overall. If
"auth=" is missing, then DMARC falls back to supporting SPF and DKIM.
+1, clarifying underlying mechanisms improves DMARC usability.
Version bump only forces domains that wish to use the new tag to create a new
v=DMARC2 record. Old evaluators will read the v=DMARC1 record, whereas they
can just ignore the new tag if we stick to the same version.
After sleeping on it, I think the new tag could also specify DKIM /and/ SPF,
besides or and one only, for domains that want that extra security. Possible
values, for example, auth=dkim|spf (default value), auth=dkim+spf, auth=dkim,
auth=spf.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
