-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Roland Turner
Sent: Wednesday, April 09, 2008 1:14 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] use cases for wildcard policy assertions
On Tue, 2008-04-08 at 18:50 -0400, J D Falk wrote:
Or there will be paranoid admins who would want to state "we don't
send
any mail at all from *, unless I state otherwise in a more-specific
record." In other words, they'd be trying to change the default
state
from "unknown" to "discardable." Some of my personal domains would
benefit from this; they're the ones where I currently have "v=spf1
-all"
records.
This strikes me a particularly interesting one. It's not pure paranoia
so much as fail-safe / default-access-denied thinking (not that this
is
access-control per se).
Setting aside questions of whether consensus has already been reached,
and the painful technical details of trying to deal with hierachies of
names rather exact matches with individual domain name, it strikes me
that any reasonable "outsider" will look at a spec that doesn't allow
him to specify in one step (rather than hopefully-correctly attached
to
every single zone entry now and through all future changes) "Acme
Corp's
email is ALL signed, or it's not ours" and wonder what the spec
authors
were thinking.
I think if we go this route we need to 1) be more clear about what is
and isn't supported, and 2) include some explanation of how a subdomain
that wants a different policy (e.g. "unknown" where the parent domain is
"all", or "discardable" if it doesn't send any mail and the parent has
published a weaker practice record).
I think part of Dave's point is that doing a good job of (1) may not be
as straightforward as it seems.
Examples for (2) are very important in both directions (creating a
subdomain policy that is a) weaker and b) stronger than that of the
parent domain).
Ellen
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html