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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
