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 [email protected] (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
