On April 12, 2023 9:51:14 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:
>>
>>
>> On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>>> On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
>>>> On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>>>>> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
>>>>>> I don't feel strongly about N=10, but I do feel strongly that N=5 is
>>>>>> insufficient. My gut feel is that 6 or 7 is likely more than enough to
>>>>>> cover all real world examples, but it's a gut feel only and not backed
>>>>>> by data.
>>>>>
>>>>> IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1
>>>>> (instead of 4), and then say that N=5 is the value we currently consider
>>>>> good but recommend to make it configurable. Or we could leave the text
>>>>> as is (if it's easier to understand it that way) and just recommend to
>>>>> not hardcode "5" and "4".
>>>>
>>>> I don't think everyone picking their own N is going to promote
>>>> interoperability.
>>>
>>> It would, as long as subsequent standard revisions suggest different
>>> values, and people more or less follow. Compare with suggested/
>>> recommended RSA key lengths.
>>
>> I don't think that's an apt comparison, but even if it were, what's the
>> advantage of making the outcome of record lookups less consistent?
>
>
>Not getting stuck in hard-coded limits, like 10 lookups for SPF, for example.
If we'd written N lookups where N=10 instead of 10 lookups, the impact on the
installed base would be no different. We'll publish a new RFC and everyone
will update their systems in no time isn't a thing. It's also not a topic I
think it's useful to spend time on, so I'm out of this thread.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
