[ietf-dkim] Regarding #1201: change the syntax from SPF compat to human compat

[Douglas Otis]

SPF's use of punctuation was indeed not very friendly.  The first  
letter comprising a single word assertion would be much easier to  
recall and subsequently read.  This is especially true when  
punctuation such as ":" or "+" is used to separate various assertion  
flags.

There remains a good reason for not using full words per assertion,  
when a single letter is sufficient.  It should be assumed that over  
time domain-names will become larger.  Perhaps something like  
"xn--55qx5d" may even become the common size for a TLD. There are  
also sizable SLDs such as "kitakyushu.jp" or "chirurgiens- 
dentistes.fr".  When policy contains a confirmation of a sha-1 and  
base32 encoding of an associated domain, this adds a 32 byte label  
and the indeterminate length of the actual domain-name.

Within the DNS message allotment, 12 bytes contain the DNS message  
header, 5 bytes contain the query, plus the number of bytes to  
accommodate the query name, plus one byte per label overhead.  Also  
add the 9 bytes that contain the response, plus 2 bytes per label  
(assuming name compression) followed by the RR data.  Not including  
the name requirements, there are 486 bytes available within this DNS  
message allotment. A TXT RR holding more than 255 characters also  
contains an additional two bytes for defining the character-string  
length, which leaves 484 bytes for the key related data and the name  
information. The name information would require the sum of the label  
sizes plus 3 additional bytes per label.

When 32 character labels of base32 encoded sha-1 hash are used to  
associate domains or local-parts, and that the policy label also  
consumes an additional 7 characters, this represents a 45 byte  
overhead.  The French SLD alone consumes 30 bytes.  Assume two sub- 
domains below this SLD average 16 characters where people in this  
region have become accustom to using long domains names.  To define  
the domain-name for the policy query would require 113 bytes.  That  
leaves 371 bytes for restating the hashed element, asserting policy,  
and perhaps including infrequent associations such as special local- 
parts in order to avoid publishing local-part policy separately (when  
this information can fit).

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dosp-01.html

There are still several errors in this illustrative policy draft,  
largely within the DNS example section.  A better example will be  
made that includes domain associations along with the corrections, in  
addition to offering examples containing a few local-part addresses.   
When this is done, it becomes more readily apparent there is little  
space to spare.  This shows 7 bytes consumed by the version, and  
perhaps another 8 bytes consumed to assert various flags that  
comprise a single and fairly easy to remember first letters of the  
assertions.  Now add to that, a domain name of 68 characters  
contained within the hash that requires 71 bytes to list.  This  
leaves 285 bytes for a local-part list which permits specific  
exceptions without requiring the separate publishing of a local-part  
policy with the added DNS transaction.  If these local-part names  
average 24 characters long, then about 10 such names could be listed  
to avoid the separate publishing of the local-part using the same  
hashed label technique.

-Doug