Giving this some more thought from the opposite point of view... the
benefits to an auth=DKIM method in DMARC itself would remove the need for
domain owners to do SPF tinkering for any upgrade mitigation, and shared
mail infrastructure where one could potentially be affected by SPF upgrade
could instead be mitigated by the new tag, but still retain positive SPF
authentication.

So, theoretically, if we look at it that way, there are a couple of
upsides, although obviously there is additional added complexity, and as
Doug surmised, the adaptation of mail filters will take a
significant amount of time before we see any semblance of ubiquitous
adoption.

I'm on the fence currently about the auth= method.

- Mark Alley

On Sun, Oct 29, 2023, 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Reporting allows certainty within the limits of the reporting mechanism.
> My inference is that many domains stop at p=none for an extended period or
> forever because the reporting mechanism does not provide that certainty.
>  For my part, I backed away from reject when I received fail-with-reject
> reports from Outlook.com.  These proved to be false results (messages were
> not blocked) but the fear remained.  Since then, domain members have
> started participating with mailing lists, and I have not determined how the
> list handles p=reject participation.  So I am back at none.
>
> More importantly, the SPF neutral gimmick can be applied immediately, with
> confidence that it will be handled as intended by essentially all
> evaluators.
>
> 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.
>
> Additionally, we have testimony that the neutral gimmick has been recently
> used on a large scale, to block SPf upgrade attacks, with good results.
>
> 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
>
> Doug
>
> On Sun, Oct 29, 2023, 2:03 PM Richard Clayton <rich...@highwayman.com>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> In message <CAH48ZfyvA5F8vqUQqyUujKqZHyLKK-fpDm0C3abwet=Zq-
>> f...@mail.gmail.com>, Douglas Foster <dougfoster.emailstanda...@gmail.co
>> m> writes
>>
>> >    * auth=DKIMOnly requires that the domain owner have high confidence
>> >      that every message source is applying DKIM signatures.
>>
>> which of course the reporting mechanism allows them to acquire
>>
>> - --
>> richard                                                   Richard Clayton
>>
>> Those who would give up essential Liberty, to purchase a little temporary
>> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: PGPsdk version 1.7.1
>>
>> iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw
>> XWnnTNQEzFoispkq3McuQGgw
>> =PlmH
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> 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
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to