People who think that SPF should use some sort of "wildcard" scheme to
allow subdomains to be covered by the SPF record of the apex (I'm not
one of these) could volunteer for this work in IETF "DNS extensions"
Working Group.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
--- Begin Message ---
There seems to be in some peoples mind a "need" for mechanism to do a
wild-card "like" thing.
Without having clear requirements and usage examples it is hard to judge what
is wanted by the different people that have posted on the "Faux wildcards" and
"wildcards vs RR types" topic. On the other hand we think that, given that we
have been going in circles, continuing on list will not lead us anywhere.
The chairs would like to propose the following path forward.
We assume that there will be a number of stake holders for such a
"Weird Wildcard Workitem" and we would like them to take some time
to produce the following:
1. Requirement statement
2. Draft rules for proposed mechanism the rules must address at least
the following questions:
a. is this both/either a terminal or non terminal
b. does this match:
only existing names
only non-existing names
both
c. Is this mechanism terminated by
existing name
delegation
if the answer is "delegation" then answer sub question
how does same type at a name affect expansion
d. Is this mechanism expanded to one or multiple labels
e. If answer is multiple levels how are multiple expansion statements
for the same type handled.
3. Usage example or two.
4. List of active participants
Issues like how this is expressed in zone files and zone transfer do not
have to be included at this point, nor do issues like DNSSEC or
dynamic update interaction.
After this has been drafted we'll verify if this work can be done within
charter of this group and if there are sufficient people available that
actually are willing and able to do the work.
So essentially we are asking a small requirements-design team to form
that will do their work on the 0th version. In order to bootstrap this
process stakeholders can contact Olafur (ogud at ogud.com) who will subscribe
them to a mailing list. The list will be discontinued and the archives of
the mailing list will be made available once version 0 is available.
We hope that the working group can have an in depth, in scope and
focused discussion on such version 0.
Olafur and Olaf
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--- End Message ---