dkim-ops
[Top] [All Lists]

Re: [dkim-ops] DKIM Testing Feedback Loops

2010-09-22 07:42:17
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

<Prev in Thread] Current Thread [Next in Thread>