Todd Lyons wrote:
> On Tue, Sep 21, 2010 at 10:42 AM, Hector Santos <[email protected]> wrote:
>> � � � [email protected]
>> 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
[email protected]
http://mipassoc.org/mailman/listinfo/dkim-ops
