I do not think we need to go to a macro expansion. I didn't like it in SPF
either.
I want to go simpler, not more complex. Macro languages give me indigestion.
In particular I want to boil SSP down so that the complexity of the policy
language is the absolute minimum. To do this it appears that we may need to
define maybe three additional attributes elsewhere.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Arvel Hathcock
Sent: Wednesday, August 30, 2006 8:52 PM
To: 'ietf-dkim(_at_)mipassoc(_dot_)org'
Subject: RE: [ietf-dkim] Scalability concerns with Designated
Signing Domains
What a ton of mail to catch up on.
We don't need this kind of complexity in my view. A
delegation mechanism already exists. I don't see any good
reason (so far) for embracing a whole other set of problems
trying to reinvent something that already works.
--
Arvel
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of
william(at)elan.net
Sent: Saturday, August 26, 2006 10:19 AM
To: Jim Fenton
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] Scalability concerns with Designated
Signing Domains
I've proposed before that in case of large number of domains
SPF-like macro expansion be allowed in place of actual domain.
On Fri, 25 Aug 2006, Jim Fenton wrote:
[This is the first of a two messages outlining my concerns
about SSP
Designated Signing Domains. I'll break each category of
concerns into
a separate thread.]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html