[ietf-dkim] use cases for wildcard policy assertions

[Siegel, Ellen]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.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