ietf-dkim
[Top] [All Lists]

Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

2007-06-06 22:46:00

On Jun 6, 2007, at 10:11 PM, Hector Santos wrote:

Douglas Otis wrote:
On Jun 6, 2007, at 3:35 PM, Hector Santos wrote:
But why NO MAIL?  Why not other policies?

A system can have a default NO MAIL policy or a default I SIGN EVERYTHING or anything else.

Here is a workable Wildcard syntax that has a default NO MAIL POLICY

*._ssp       0  TXT   ... no mail policy...
_ssp         0  TXT   ... I may sign ..
public._ssp  0  TXT   ... I never sign ...
sales._ssp   0  TXT   ... I always sign ..
corp._ssp    0  TXT   ... I always sign ..

and one with a default I ALWAYS SIGN

*._ssp       0  TXT    ... I always sign ..
public._ssp  0  TXT   ... I never sign ...
This requires a transaction at every label within the domain in question, where of course, this also clobbers SLDs.

Explain to me why this is a problem?

I am borrowing the logic used from one of the original LMAP proposals, DMP, which SPF based on its merged designed with another LMAP RMX? proposal.

This is a single lookup by the client, no traversal, no loop, required.

Your reasoning is unclear to me.

Given the domain a.b.c.d.e.f.g.h.i.j.k.foo, please explain what
single DNS query you would make and what answer you would
expect to receive.


THe *._SSP record gives you the global default result as desired by the main domain.

So regardless of the subdomains provided, you have a GLOBAL default.

Then for specific subdomains, you can further defined specific txt records to override the default.

Again, I am no DNS expert, but is there a TECHNICAL problem with this?

Explain it to me in terms of where there is overhead, pressure or lots of work, if any, on the DNS server?

Cheers,
  Steve

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html