On 6/22/10 2:47 PM, Jeff Macdonald wrote:
On Mon, Jun 21, 2010 at 3:37 PM, Douglas
Otis<dotis(_at_)mail-abuse(_dot_)org> 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: bar(_at_)example(_dot_)net
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: bar(_at_)example(_dot_)net 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