SM wrote:
Hi Dave,
At 15:49 26-03-2009, Dave CROCKER wrote:
The best I can find is two kinds of distinction. The term
hostname refers to
a constraint on use of the full Domain Name namespace. The term registered
appears to be the way of distinguishing names that appear in the operational
well, now I'm completely confused. to my eyes, your example fits
exactly what 'registered' and 'resolvable' mean, but I guess you
have something else in mind.
Steve is quite right. Since the DKIM key records are at different
names from the related MX or A record, the existence of one doesn't
Hi Hector,
At 23:22 26-03-2009, Hector Santos wrote:
Who is the document addressed to? I must be the only one here that
is having trouble with the new lingo in communications.
The document is addressed to DKIM implementors. The document can
also be used as a base for extensions built upon
Sorry for top-posting, but couldn't we sidestep all of the analysis by simply
saying that the *syntax* (rather than the *semantics*) matches that of domain
names?
Ellen
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of
SM wrote:
Hi Hector,
At 23:22 26-03-2009, Hector Santos wrote:
Who is the document addressed to? I must be the only one here that is
having trouble with the new lingo in communications.
The document is addressed to DKIM implementors. The document can also
be used as a base for
before we get too semantically bogged down, a domain name implys dns
registration otherwise it is a label of convenience
Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
In the IETF 74 DKIM meeting, we had a brief discussion about the current state
of
ADSP, given the recent discussions on i= (and other things). It seems to the
chairs that ADSP isn't severely affected, and that changes would be needed only
in section 2.7, Author Signature, which is the only
On Mar 27, 2009, at 4:37 AM, John Levine wrote:
well, now I'm completely confused. to my eyes, your example fits
exactly what 'registered' and 'resolvable' mean, but I guess you
have something else in mind.
Steve is quite right. Since the DKIM key records are at different
names from the
Siegel, Ellen wrote:
Sorry for top-posting, but couldn't we sidestep all of the analysis
by simply saying that the *syntax* (rather than the *semantics*)
matches that of domain names?
When all is said and done, it's the combination of the selector +
_domainkey + SDID that must be a valid
Tony Hansen wrote:
Siegel, Ellen wrote:
Sorry for top-posting, but couldn't we sidestep all of the analysis
by simply saying that the *syntax* (rather than the *semantics*)
matches that of domain names?
When all is said and done, it's the combination of the selector +
_domainkey + SDID
Has any reader of this spec actually been confused? I sure
haven't seen it, and the advent of zillions of web resources in case
there were any question at all makes this seem like a rather academic
debate.
I agree with Mike. Let's leave the text as it is, and move on.
Barry (participant)
DKIM Chair wrote:
2.7. Author Signature
An author signature is a Valid Signature that has the same domain
name in the DKIM signing identity as the domain name in the Author
Address. If the DKIM signing identity has a Local-part, it is be
identical to the Local-part in the
I understand the desire to constrain the SDID to be a registered name or
under one, but is there a need to make this normative? DKIM verification
simply won't work if the SDID doesn't meet that criterion, and perhaps
that's good enough.
___
NOTE
I was asked to post what I said at the DKIM meeting about opacity and
the AUID (i=) value. Take it as input into your thought processes as you
consider the issues around the Errata. The following is only slightly
expanded over what I said on Tuesday.
==
Part 1
The definition of i= contains
On Mar 27, 2009, at 8:04 AM, Tony Hansen wrote:
Siegel, Ellen wrote:
Sorry for top-posting, but couldn't we sidestep all of the analysis
by simply saying that the *syntax* (rather than the *semantics*)
matches that of domain names?
When all is said and done, it's the combination of the
The current proposal is to remove i= here, and rework the text so that
ADSP uses d= only. We note the following:
That's fine with me. I still don't see much utility in ADSP but this
keeps it from damaging DKIM.
R's,
John
___
NOTE WELL: This list
John Levine wrote:
My concern is this: what do identity assessors use today? An IP
address. They might want that tidbid of information as well. How,
then, not to exclude it?
[ . . . ]
We tell senders that's the handle to put in signatures so receivers
recognize them, and we tell
Jim Fenton wrote:
+1 with Ellen's change.
+1
--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Steve Atkins wrote:
Not only does hatstand.beartrap.blighty.com not resolve, it's not
registered anywhere. It exists solely as a substring of the string
that's actually queried -
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com
The only thing that can be said about the SDID in DNS
Tony Hansen wrote:
The semantics constrain the AUID to be an identifier for the agent/user.
This MAY be the email address of the agent/user of the message, or it
may be some other value that also represents the identity of the
agent/user but is not an email address of the agent/user. If it is
DKIM Chair wrote:
In the IETF 74 DKIM meeting, we had a brief discussion about the current
state of
ADSP, given the recent discussions on i= (and other things). It seems to the
chairs that ADSP isn't severely affected, and that changes would be needed
only
in section 2.7, Author
Note: ADSP is incompatible with valid DKIM usage in which a
signer
uses i= with values that are not the same as addresses in
mail
headers. In that case, a possible workaround could be to add a
second DKIM signature a d= value that matches the Author
Address, but
22 matches
Mail list logo
