On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:
On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely <[email protected]> wrote:
On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely <[email protected]> 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.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
