On Fri, 28 Jul 2006, Hector Santos wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Anyway I guess this is just another argument to require support for
inclusion of some kind of allowed-signer list in SSP statements, and
maybe also for a requirement that the SSP statements should be able
to be "sourced" independently of key records. I guess the WG should
consider both requirements and adopt 'em or drop 'em, so including
them for now is probably right.
+1 for both - signer list, independent records.
Incidentally, the DSAP proposal currently considers an "allow list" tag
definition:
4.3. DSAP Tag; 3pl=<dom-list>;
The 3pl= is an optional tag that defines a list of 3rd party domains
who are allowed to DKIM sign the message as a 3rd party signer. This
tag is ignored unless 3rd party signing policy is expected or
optional (3p=always or 3p=optional).
<dom-list> is a comma delimited list of domain names.
Example:
3pl=isp.com,outsource.com,mailinglist.com;
That "3pl" may have been misspelled in the table listing possible tags
as "dl". Please check.
One initial and obvious design consideration is length limit related.
One reviewer did suggest some 'include' concept or protocol to access
large list.
SPF has worked those details out so you might consider its apprach.
But personally I think general "include" is too open and better
is to use something similar to SPF macros where reference can be
made to another locator (with locator dns name based on From email
address or domain) to verify that domain is listed there but
there would never be any more then one additional dns lookup.
An illustration of that concept is:
3pl={d}._3pl;
which when present with "From: alice(_at_)example(_dot_)com" causes lookup
at 'example.com._3pl._policy...'
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html