On Sun, Apr 05, 2009 at 12:21:51AM +0100, John R. Levine wrote:
One of us should send in a separate technical erratum saying that DKIM
key records SHOULD be published only for SDID domains that have
corresponding MX or A records and can receive mail.
I believe your later posting on this
The following shouldn't be discouraged:
From: f...@bar.com
DKIM-Signature: ... d=43343.rep.bar.com ...
where 43343.rep.bar.com doesn't have any MX or A record.
On further reflection, you're right. The signature isn't an email address
or a web site, so there's no reason it needs anything
On Fri, Mar 27, 2009 at 11:37:10AM -, 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
Folks,
My intent with the suggested wording was *only* to make the language exactly
match what DKIM requires. It was an exercise in precision, accuracy and
completeness, not modification or enhancement. That is, nothing new was
intended.
It clearly did not achieve that goal.
I'm reading the
On Sat, Mar 28, 2009 at 10:34 PM, Dave CROCKER d...@dcrocker.net wrote:
Hence the wording should be: A single domain name that... for both SDID and
AUID.
Does this match everyone's assessment of consensus?
Acceptable.
___
NOTE WELL: This list
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
Of Dave CROCKER
Sent: Thursday, March 26, 2009 6:50 PM
To: Jim Fenton
Cc: DKIM IETF WG
Subject: [ietf-dkim] (registered) domain name (Re: errata revision:
opaque)
Jim Fenton wrote:
Just for completeness, I'll point out that some might feel that the
(indirect) statement that the domain
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
] On
Behalf Of Steve Atkins
Sent: Thursday, March 26, 2009 9:21 PM
To: DKIM IETF WG
Subject: Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)
On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote:
Steve Atkins wrote:
On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote:
6. RFC4871
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)
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
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
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
Jim Fenton wrote:
Just for completeness, I'll point out that some might feel that the
(indirect) statement that the domain name portion of the AUID has domain
name semantics is too strong. The subdomain portion (the portion, if
any, that is a subdomain of the SDID) doesn't need to be an
On Thu, Mar 26, 2009 at 07:59:48PM -0400, Jeff Macdonald wrote:
On Thu, Mar 26, 2009 at 03:49:38PM -0700, Dave CROCKER wrote:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers
On Thu, Mar 26, 2009 at 03:49:38PM -0700, Dave CROCKER wrote:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the identity claiming responsibility for
introduction
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
A single domain name - A single, registered domain name
...
7. RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
A single domain name - A single, syntactically valid domain name
Well, to make them similar, how about
On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the identity claiming responsibility
for
introduction of a
Steve Atkins wrote:
On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the identity claiming responsibility
for
On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote:
Steve Atkins wrote:
On Mar 26, 2009, at 3:49 PM, Dave CROCKER wrote:
6. RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
New:
A single domain name that is the mandatory payload output of
DKIM and that refers to the
We could say DNS-resolvable.
Barry
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Mar 26, 2009, at 6:26 PM, Barry Leiba wrote:
We could say DNS-resolvable.
We could, but it's not actually a requirement that the SDID resolve in
the DNS (and in many cases it won't).
I think domain name is just vague enough to avoid these problems. If
you try and make it more specific
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.
RFC 1034 and RFC 1035 make many references to resolvers.
d/
Steve Atkins wrote:
On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote:
On Mar 26, 2009, at 7:05 PM, Dave CROCKER 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.
hatstand.beartrap.blighty.com doesn't resolve. A query for it returns
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
service, ie, the
30 matches
Mail list logo
