On 5/25/2004 8:45 AM, Dave Crocker sent forth electrons to convey:
However some of the postings in the thread seem to have a tone along
the lines of "if we can toss out all of the cases, then we do not need
to support wildcards". That line of thinking is folly.
Yup. It's folly. (It's folly where there are wildcards already.) We
need to handle wildcard MXes.
One of the postings you're probably referring to was mine, so I want to
make clear that I think wildcard MX support is needed.
(Sorry - that posting of mine is irrelevant in the big picture - I was
just pointing out that IF you already have a zone file with a long list
of A and MX records, THEN adding a duplicate list for one more type -
MARID (whether that's a real type or a 'subtype') - isn't much work
given a good 'search and replace' tool. If you already have wildcard
records, then this argument doesn't apply - support IS needed. Perhaps I
misread the intent of the original poster I was replying to. I was the
only person at the meeting who actually uses a wildcard MX record, BTW.)
I've fallen behind, probably missed some discussion - did we decide that
lookup _marid.host TXT record
is better than
lookup host TXT record,
which, IIRC, SPF-ID will be doing anyway for backward compatibility with SPF,
and hence the need for wildcard support beyond the usual way? I'm wondering
aloud why we're not sticking with SPF's syntax but changing the semantics and
usage.