On 6/22/10 2:47 PM, Jeff Macdonald wrote: > On Mon, Jun 21, 2010 at 3:37 PM, Douglas Otis<[email protected]> wrote: > Hey Jeff, > http://www.ietf.org/id/draft-otis-dkim-tpa-label-04.txt > http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-04.html > > Doug I stopped reading at section 3.2. I think this is too ambitious. > But I want some of this functionality. What I'd like is a draft like > this that doesn't require any dkim changes. Ahem. This draft does not require _any_ changes to DKIM, and only appends to values placed in the ADSP dkim tag.
By doing so, this provides a restrictive assertion able to reject messages lacking an Author Domain, or that have not been authorized, or that don't include specified headers. > I also don't want it tied > to ADSP. I see an alternate definition of 3rd party. It seems the > definition in this draft doesn't call this a 3rd party: > > DKIM-Signature: ... d=foo.example.net > From: [email protected] > > Per the draft, 2.2.2. Third Party Signature A "Third Party Signature" is a Valid Signature that does not qualify as a Author Domain Signature. An author domain must exactly match with the From domain. A tpa-label for foo.example.net within the example.net domain allows DKIM-Signature: ... d=foo.example.net to be considered equivalent to an author signature of d=example.net. This would allow From: [email protected] to be signed by DKIM-Signature: ... d=foo.example.net. Importantly, when there is no valid author-domain signature or authorized third-party, the message should be refused. This changes "dkim=all" into providing a clearly actionable result. :^) The tpa-label scheme also provides a set of scopes to require a header added (i.e. sender or list-id) that contains the domain of "foo.example.net". This is to provide a mechanism for recipients to isolate messages by using available sorting tools. This scheme also handles authorizing third-party services that don't use DKIM, but offer a means to confirm EHLO, or the return-path. Hopefully, such allowances would only be an interim solution. The hash label also prevents anyone from walking this list, assuming you might want to limit the information to those with a need to know. > I think some folks say it is. > > A simplification of this draft would be: > > 1) if the signature validates > a) create a label composed of<d=>._tpa.<author-domain> > The simpler approach was not used in favor of a scheme able to handle large domain names. We have yet to see the extent of international domain names that start at the root, with several wanting to construct foreign phrases. Look at some of the top level domains used by the French, as a possible clue for where this lead once this also includes the use of ACE-labels (or a-labels for short). This scheme also places all authorizations into a single zone with less DNS related interaction and faster lookup. The chance of collision for 3 x 10^45 domain names is less than 0.1%. > So for the above, one would do a DNS lookup at: > > foo.example.net._tpa.example.net > Yes, this is fine, provided domain names constrain themselves to using less than half of whats allowed. The tpa-label approach using a hash label reduces the maximal domain name size by 6%, and ensures consistent response accommodations where listed domains can be wildcarded or not listed as needed. Causing too large of a response might cause difficult to resolve because resource record allocations changes per domain. > if there is a record, there is a stated relationship between > <author-domain> (example.net) and<d=> (foo.example.net). > > I'll read the rest of your draft, but I'm wondering if my > simplification would be enough for most folks. IMHO any service that > builds off of DKIM should do something like this. It would reduce the > need for multiple signatures. > I hope to be working with the OpenDKIM group to include these functions in an experimental version. The code needed to generate tpa-labels is already written. I am talking to my employer about creating a general purpose _tpa. zone that others could delegate or use with DNAME to access a list of safe third-party services. More sensitive domains will likely want to publish their own _tpa list. The nature of these services might dictate inclusion of List-Id or Sender headers. Just imagine. By using this scheme, anyone using a large DKIM signing provider that allows use of a customer's From email-addresses (that check ownership first), could then tightly restrict acceptance of their messages while still being able to participate in mailing lists, or use other email providers without needing to share DKIM key information. A restriction that the large provider would be unlikely to impose. Your customers could do it, and it would just work. That is where things need to be remain simple. I noticed a few typos and others have indicated a few missing bits on the last draft. A minor update will be published soon. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
