[ietf-dkim] Who signs what
Murray S. Kucherawy
msk at cloudmark.com
Thu Sep 16 11:52:39 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.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 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.
> 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.
More information about the ietf-dkim