Todd Lyons wrote:
On Tue, Sep 21, 2010 at 10:42 AM, Hector Santos <hsantos(_at_)isdg(_dot_)net>
wrote:
� � � dkim-autorespond(_at_)isdg(_dot_)net
The site DKIM Verifier implementation now has ADSP support with my R&D
on the ADSP extension ASL (Allow Signer List) idea. �We are now
Example ADSP record for winserver.com:
dkim=all; asl=mipassoc.org,megabytecoffee.com,
� � � � � � � mapurdy.com.au,santronics.com,isdg.net
I see very quickly the potential for scaling problems. What's your
expected max length? DNS TXT records can consist of 255 byte strings,
so if your length is more than 255 characters, you'll have to split it
into multiple strings (upper bound of any DNS record seems to be
65535). Personally, I subscribe to 43 different mailing lists. For
someone like me, I think you'll have to consider doing like spf where
you can include other txt records for the asl setting in order for it
to scale.
Hi Todd,
Yes, there are DNS considerations here. For the moment, working out
the logistics for the authorized associations for "3rd party"
signatures, including defining Domain Expectations per RFC 5016.
What is known that you can do a single lookup and get multiple records
such as the DSAP (DKIM Signer Authorization Protocol) experimentation
has shown:
_dsap.isgn.net
Non-authoritative answer cleaned up response shown here:
v=dsap1.0; sd=*; rr=0; op=optional; 3p=never; a=rsa-sha256;
fa=fail; fx=fail; fs=fail;
v=dsap1.0; sd=list; rr=0; op=never; 3p=optional; 3pl=mipassoc.org
v=dsap1.0; sd=corp; rr=0; op=always; 3p=never; a=rsa-sha256;
v=dsap1.0; sd=sales; rr=0; op=always; 3p=never; a=rsa-sha256;
v=dsap1.0; sd=europe.sales; rr=0; op=always; 3p=never; a=rsa-sha256;
v=dsap1.0; sd=public; rr=0; op=never; 3p=never;
The above would be an example ADMD policy declaration for various
sub-domains.
The sd=* record with be the default ADMD policy which I shown as the
optional Originating Policy (op=) and a Never to be signed by 3rd
party policy. The fa=, fx=, and fs= are policy failure "handling" hints.
The ASL idea is the "lite" version of this since it has been
prevailing over the last 4-5 years a more simple model is all one
might need to deal with the intermediary agent issues such as List
Servers:
"Not Sign or Always Sign by anyone"
So I think working on the logistics of Policy is important and then
deal with the scaling issues. However, I think a single LOOKUP,
Multiple record Response is ok to deal with this. Of course, the
larger you are, the higher overhead is associated with you and more
management is required. But that applies to anything.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops