ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Who signs what

2010-09-16 13:57:26
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Steve Atkins
Sent: Thursday, September 16, 2010 11:35 AM
To: DKIM List
Subject: Re: [ietf-dkim] Who signs what

I think you're saying that when I register a domain[1] and use
that domain in both the From: address and the DKIM signature
then that's a third-party signature if I use a subdomain in the
DKIM signature.

Yes.

In the ADSP world the difference between "non-author-domain"
 vs "author-domain" is an important distinction, but you're
using "third-party" vs "first-party" to refer to that.

I don't think there's a difference.  I think having two terms to describe the 
same thing in different ways only serves to confuse the issue.

That's contrary to normal use of the term third-party, as there
is no third party involved in this example - there's me and my
domain, and there's the recipient.

How is a piece of software supposed to detect and apply that?  As soon as you 
make that allowance, then one could argue we should also have a heuristic to 
say "yahoo.co.uk" and "yahoo.com" are related and should share a reputation.

I really don't think we want to go down this path.

And this isn't a theoretical case. Signing with a subdomain of
the domain in the From address is DKIM best practice in a
large fraction of cases.

It's still a third-party signature, with its own reputation.  That is, as I 
understand it, the whole point of signing with a subdomain.

If we describe that as a third-party signature we risk confusing
it with the case of a true third-party signature from a certification
authority or some such. "Third-party that's the author"
vs "Third-party that's not the author".

There's only confusion when we pile adjectives onto the end.  It's third-party, 
or it's not.  Or since some people like ADSP's terms:  It's an author 
signature, or it's not.

Put another way: If we can't converge on terminology in this area to describe 
all the variations, maybe there's a reason for that.

Let's not waste time on this.

The way to avoid wasting time is to use the terminology
that's in the drafts we already have in place, rather than
making up new terminology that's misleading.

Actually I think the time is wasted in trying to identify every possible 
variant of a very simple term that already has a well-defined history, and 
document them all and treat them all differently.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>