Murray S. Kucherawy writes: > On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster < > [email protected]> wrote: > > By contrast, the new tag cannot be effective until DMARCbis is published > and filtering software updated. This involves years. Even then, domain > owners will never have confidence that the new token support has been > implemented by all recipient evaluators. > > At least on its face, this is a big concern. A domain owner publishing "auth= > dkim" is going to get varying results as some sites update to software > supporting such a tag while others ignore it. I don't know if the potential > for some benefit is a desirable trade for the potential for some confusion.
Varying meaning, those who implement auth=dkim will get extra protection, and those who do not, are left as they are now. I myself think that adding clear indication that sender always uses dkim, and evaluators can rely on that makes the DMARC better, and more secure. And as every DMARC evaluator needs to support DKIM anyways (there is no such thing as SPF only DMARC evaluator, both SPF and DKIM are mandatory to implement), there is no real difference in complexity for evaluators. > Seems like a slam dunk for SPF neutral. I said the problem and it's > solution needs to be laid out in our document because I am one of those > who did not understand it as a possible strategy > > I think I agree. This will also change the behavior of the receivers. For example spamassasin does give more points to SPF_NEUTRAL (around 0.6-0.7) than SPF_PASS (-0.001) etc. I would assume other similar software also use SPF results similarly. The reason why SPF_PASS gives only -0.001 is that it is assumed that spammers will use their own domain and thus can get SPF records to match (DMARC, DKIM and SPF are never meant to work against spammers). -- [email protected] _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
