On 10/7/09 2:10 AM, Daniel Black wrote:
On Wednesday 07 October 2009 09:38:37 Doug Otis wrote:
Doug,
I've in favour of a solution to option C) as you describe it: To
authorize mailing lists to better ensure their message's handling
while asserting a (ADSP) policy of "all".
Publishing third party allow records on the author domains seems to
be the most reliable method here.
A simplified record syntax of the following could be used:
mipassoc.org._3p._domainkey.example.com IN TXT
"dkim={all|unknown|discard}"
Daniel,
A DNS label is limited to containing 255 label characters which includes
a length byte for every label. In your example of a simple domain
reference, this has used 41 bytes. Subtracting the fixed labels, this
leaves a remainder of 240 bytes to specify both domains. In some
regions, the TLD and SLD labels have come rather long, especially when
using ACE (puny code) labels. As an alternative, the hash example only
consumes 32 characters for the authorized domain.
Using the simply label approach, the maximal domain length supported
requires that all maximal domain sizes be below 120 characters. This
limit is needed to constrain the resulting reference to 15 +
authorized-domain-length + authorizing-domain-length to the maximum
domain length. Which means in essence, maximum domain length MUST remain
well below 120 characters before the simple approach is assured to function.
As DNS evolves into encoding non-ASCII character strings, and with
perhaps a growing competition for TLDs which will mean these too will
grow in length and will be encoding international character sets, a
maximal limit imposed by the "simple label" approach seems certain of
avoiding trouble.
The hash approach only requires that the authorizing domain occupy less
than 204 characters, as opposed to all maximal domains being less than
120 for 170 increase in available space. In the last draft that
proposed this message, it contributed C code for a command line function
that generates the hash labels using standard libraries.
advantages: * simple * DNS can be delegated at the _3p level (or any
level below) * same format as ADSP (needed at least dkim= to avoid
conflicts with all wildcard SPF record) * could apply mail-filtering
same as ADSP (only stricter)
disadvantages: * cannot do full mailbox ietf-dkim(_at_)mipassoc(_dot_)org
(don't
know if this is needed)
That was what the g= parameter within the DKIM key was intended to
resolve. Clearly, authorized third-party domains should be expected to
perform this level of screening instead.
far left side benefits: A list archive like gmane or mailarchive
could publish a DNS hierarchy in the same form as a service to
verifiers who want the answer to the question "Is this a email
list?"
Agreed. Perhaps this could include a policy assertion about the nature
of the third-party domain.
A simple and static hashed "authentication" record could be applied
by customers at their leisure _without_ modifying how third-party
DKIM providers sign their customer's email.
good
Use of a hashed authentication record allows all messages to
receive the same signature,
I don't know what this means.
Sorry. I meant the same signature key reference. In other words, no
change needs to be made in how messages are signed and which keys are used.
where there would be no transitioning concerns with respect to when
a customer's DNS server synchronized with that of the provider's
key references.
good.
Extracting cost for this service could occur when allowing
customers the use of their own domain in From headers. After that,
no hand holding or DNS publication coordination would be required.
Another benefit could include an easy ability to authorize
mailing-lists that modify messages. Such authorizations could be
added and removed without affecting the operation of the outbound
MTA or the mailing list.
good goal.
On that we agree.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html