Subject: [ietf-dkim] errata revision: opaque

From: Dave CROCKER <[email-masked]>
Date: Wed, 25 Mar 2009 13:56:12 -0700

Folks,

The following is offered to prime the discussion/decision process for the one of 
the pending Errata items, developed in the SF working group meeting. It reflects 
what I heard as the gist of the group preference. Obviously, I might have 
entirely misunderstood...

So, anything that permits progress is encouraged, such as "looks good", "change 
x to y", and "replace the whole thing with this different chunk of text".  There 
are no doubt other constructive responses, but this ought to establish the tone...

"Old" refers to the Errata I-D; "New" is the proffered replacement.

6.  RFC4871 Section 2.9 Signing Domain Identifier (SDID)

     Old:
       A single, opaque value that is the mandatory payload output of
       DKIM and which refers to the identity claiming responsibility for
       the introduction of a message into the mail stream.  It is

     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 message into the mail stream.  For DKIM
       processing, the name has only basic domain name semantics; any
       possible owner-specific semantics is outside the scope of DKIM.

7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)

     Old:
       A single, opaque value that identifies the agent or user on behalf
       of whom the SDID has taken responsibility.

     New:
       A single domain name that identifies the agent or user on behalf
       of whom the SDID has taken responsibility.  For DKIM
       processing, the name has only basic domain name semantics; any
       possible owner-specific semantics is outside the scope of DKIM.

12.  RFC4871 Section 3.9 Relationship Between SDID and AUID

     Old:
       Hence, DKIM delivers to receive-side Identity Assessors
       responsible Identifiers that are opaque to the assessor.  Their
       sub-structures and particular semantics are not publicly defined
       and, therefore, cannot be assumed by an Identity Assessor.

     New:
       Hence, DKIM's mandatory delivery to a receive-side Identity Assessor
       is a single domain name.  Within the scope of its use as DKIM output,
       the name has only basic domain name semantics; any possible
       owner-specific semantics is outside the scope of DKIM. That is,
       within its role as a DKIM identifier, additional semantics cannot
       be assumed by an Identity Assessor.

OK.  Start shooting.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Al Iverson <[email-masked]>
Date: Wed, 25 Mar 2009 16:11:20 -0500

Looks good to me.

I have a mild reservation in that "opaque" struck me as the most
appropriate term to begin with, but I'll certainly be OK with this.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 25 Mar 2009 14:36:29 -0700

darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn 
darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn darn

definition of AUID is screwed up.  didn't mean to change it.

so...

>        possible owner-specific semantics is outside the scope of DKIM.

       New:
         A single value that identifies the agent or user on behalf
         of whom the SDID has taken responsibility.  For DKIM
         processing, the domain name portion of the AUID has only basic
         domain name semantics; any possible owner-specific semantics is
         outside the scope of DKIM.

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 25 Mar 2009 21:40:21 -0000

>       possible owner-specific semantics is outside the scope of DKIM.

While I'd think it would be dandy if the i= were a domain name, I
suspect I'd be outvoted, so perhaps it would be better to say
something like this:

       A string that identifies the agent or user on behalf of whom
       the SDID has taken responsibility.  The string has the syntax
       of an e-mail address where the domain part is the same as the
       SDID or a subdomain of the SDID.  For DKIM processing, the AUID
       has no semantics beyond validation that it complies with the
       syntactic rules; any possible owner-specific semantics is
       outside the scope of DKIM.

R's,
John

---

From: Michael Adkins <[email-masked]>
Date: Wed, 25 Mar 2009 17:25:39 -0400

>        possible owner-specific semantics is outside the scope of DKIM.
Are we changing the format of the AUID from an email address where the
lhs is optional to a domain name?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Mar 2009 16:00:51 -0700 (PDT)

>       outside the scope of DKIM.

I'm fine with either form.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Wed, 25 Mar 2009 19:23:27 -0400 (EDT)

>        outside the scope of DKIM.

+1 

I wasn't aware of a proposal to change i= into domain form, but
I must admit that could not attend the entire meeting over the
phone.

	Wietse

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 25 Mar 2009 16:24:49 -0700

> lhs is optional to a domain name?

we probably merely have a race condition, here, but best to be certain:

    No. I made a mistake.

    The latest text (both Levine's and mine) move that aspect of the text back 
to where it was.

    Again:  No change in the definition of AUID (i=) was intended and I am 
/very/ sorry for that bit of sloppiness.

d/
-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Wed, 25 Mar 2009 20:56:12 -0400

<participant>Taking into account the "oops" and its correction, I like
this text.</participant>

Barry

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Thu, 26 Mar 2009 07:23:51 +0530

+1 from me.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 26 Mar 2009 11:16:51 -0000

>        possible owner-specific semantics is outside the scope of DKIM.

No, that is not quite right. The single domain name is the mandatory  
_part_ of the payload, but the payload (as passed to the Assessor) may,  
and most likely will, include further information (the contents of the h=  
field, for example), which a smart assessor may be able to use, especially  
in special circumstances it wots of.

But, as I have already pointed out, it is not IETF policy to delve, more  
than superficially, into the details of exactly what is communicated  
between the various related agents that are fed off an MTA.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Mar 2009 10:57:57 -0400

Charles says...
> between the various related agents that are fed off an MTA.

Right, exactly so on the last sentence.  My concern was only to make
sure that the text made it clear that it's not trying to limit
anything.  Beyond that, I don't think we should be listing
implementation details that are beyond the scope of what DKIM actually
does.

Barry

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Mar 2009 13:25:04 -0700

Dave CROCKER wrote:

so...

Dave CROCKER wrote:

Old:

New:

New:

Whew.  Thanks for the revision.  I'm happy with this and the other
definitions in your original message, although I'd suggest s/semantics
is/semantics are/

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
actual domain at all.

I'm not sure it's necessary to clutter the definition with this detail,
however.  I'm happy with it the way it is.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 15:49:38 -0700

Jim Fenton wrote:

> (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 actual 
> domain at all.
> 

Well, I think we should make sure that clarification text doesn't wind up 
diverging from the precise semantics of what it is trying to clarify, lest we 
create ambiguity.

So while this might be a pain, I think it's good you caught this issue and 
raised it.

I don't claim to know the nuances of this issue well enough.  For starters, I 
did some searching around, which might or might not have improved my 
understanding...

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 public database.

That is, the former refers to names and the latter refers to a query mechanism.

When we say "actual", I think it translates into what the documents I'm seeing 
are calling "registered".

RFC4871's i= text says:

      "The domain part of the address MUST be the same as or a subdomain of the 
value of the "d=" tag"

which does not imply registration or non-registration.  Either appears to be legal.

I think this does motivate two improvements to the draft language, one for SDID 

> 6.  RFC4871 Section 2.9 Signing Domain Identifier (SDID)
...
>        possible owner-specific semantics is outside the scope of DKIM.

    A single domain name -> A single, registered domain name

> 7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
>        possible owner-specific semantics is outside the scope of DKIM.

    A single domain name -> A single, syntactically valid domain name

{{ no, I'm not in love that that wording choice.  /d }}

How much indigestion does this cause?

d/
-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 26 Mar 2009 20:03:44 -0400

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:
> none for me. +1

oh, and +1 for the others

-- 
Jeff Macdonald
[email-masked]

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 26 Mar 2009 19:59:48 -0400

none for me. +1

-- 
Jeff Macdonald
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Mar 2009 20:34:34 -0400

...
...
...
>    A single domain name -> A single, syntactically valid domain name

Well, to make them similar, how about this for 7?:
    A single domain name -> A single domain name, not necessarily registered,

Barry

---

From: Steve Atkins <[email-masked]>
Date: Thu, 26 Mar 2009 18:04:08 -0700

>    A single domain name -> A single, registered domain name

Registered with who?

If the SDID is, say, hatstand.beartrap.blighty.com?

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 18:10:12 -0700

> If the SDID is, say, hatstand.beartrap.blighty.com?

Registered with the DNS, the global distributed hierarchical service.

 From the other uses of this language I'm seeing on the net, this isn't said 
explicitly.  Do you really feel that the meaning is not clear?

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Thu, 26 Mar 2009 18:21:01 -0700

On Mar 26, 2009, at 6:10 PM, Dave CROCKER wrote:

> From the other uses of this language I'm seeing on the net, this  
> isn't said explicitly.  Do you really feel that the meaning is not  
> clear?

Registered means that the string is registered with a registry.

That's not something I'd want the language to even hint at, let alone  
actually say. It's going to lead to confusion when explaining this to  
people, as you'll need to directly contradict the wording in the spec  
when you reassure them that, no, there is no central DKIM registry.

Cheers,
   Steve

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Mar 2009 21:26:40 -0400

We could say "DNS-resolvable".

Barry

---

From: Steve Atkins <[email-masked]>
Date: Thu, 26 Mar 2009 18:31:51 -0700

> 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 without making it misleading, it's  
going to take more than just a couple of words to describe accurately.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 18:36:52 -0700

> the DNS (and in many cases it won't).

Really?

Then how does the receiver obtain the public key for performing verification?

key retrieval is defined as using d=.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Thu, 26 Mar 2009 18:51:48 -0700

On Mar 26, 2009, at 6:36 PM, Dave CROCKER wrote:

>> We could, but it's not actually a requirement that the SDID resolve  
>> in  the DNS (and in many cases it won't).
>
>
> Really?
>

If you receive an email with a selector of banjo.aardvark and an SDID  
of hatstand.beartrap.blighty.com then you'll hopefully be able to  
resolve banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but  
that's all you can say about ability to resolve any query in the  
domain tree under the SDID, including the SDID itself.

At least, that's how I understand it.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 19:05:13 -0700

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/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Thu, 26 Mar 2009 19:20:25 -0700

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  
NXDOMAIN, and it doesn't exist in DNS in any way:

      steve$ dig  hatstand.beartrap.blighty.com txt
      ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12223

Yet it's potentially a valid SDID, because  
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com *does* return  
a TXT record.

      steve$ dig +short  
banjo.aardvark._domainkey.hatstand.beartrap.blighty.com txt
      "I am a public key - no, really!"

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 terms is that  
the signer of the mail has the ability to add TXT records in the  
subtree rooted at that domain.

Given that, trying to make more specific statements about what the  
SDID is than something vague like "a domain name" is likely to lead to  
something that's misleading or plain wrong.

-1 on "registered" or "resolvable".

Cheers,
   Steve

>>>> We could, but it's not actually a requirement that the SDID  
>>>> resolve  in  the DNS (and in many cases it won't).
>>>
>>> Really?
>>>
>> If you receive an email with a selector of banjo.aardvark and an  
>> SDID  of hatstand.beartrap.blighty.com then you'll hopefully be  
>> able to  resolve  
>> banjo.aardvark._domainkey.hatstand.beartrap.blighty.com, but   
>> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
>
> -- 
>
>  Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 26 Mar 2009 22:51:44 -0700

Hi Dave,
>service, ie, the public database.

The problem with this document is that it is not a specification 
about DNS and the reader may not restrict his/her interpretation to 
that only.  People commonly view the term "registered" as meaning 
that the domain name has been registered through a registry.  You can 
get away with that by specifying "registered in DNS".  Generally, we 
don't have to go to such lengths as it is implicit that the domain 
name should be resolvable.  Given the amount of debate we have been 
having about DKIM, some people might prefer to have all the details 
nailed down so that we don't have to argue about this again in 
future.  Some people will come up and say that "registered in DNS" 
means that the domain name must also be registered through a registry.

>     A single domain name -> A single, syntactically valid domain name

I don't know and I prefer not to know, whether there are 
syntactically invalid domain names. :-)  If I want to know what a 
"single domain name" is, I'll see what the RFCs say.  My statement is 
not a case of "the RFC says so" as I am not an advocate of such an 
argument.  I refer to the relevant text as, in my eyes, it provides a 
good explanation as to why we do things in a particular manner.

There isn't any requirement that DKIM must only be used on the public 
Internet.  In practice, most users of the technology will be on the 
Internet.  Let's agree about the term without constraining where DKIM 
can be used.

I suggest using "a domain name".  I don't see the point of having 
"single" in that text as the public key retrieval will fail if we use 
more than one domain name.  If the WG wants to be precise, I'm fine 
with that.  The interpretation of domain name here is within the 
context of DNS.  For those of you who don't understand what that 
means, please talk with the DNS folks.  They are highly skilled in 
the art of frustrating application designers when that question is raised. :-)

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Fri, 27 Mar 2009 02:22:12 -0400

SM wrote:
> that only.  

Who is the document addressed to?  I must be the only one here that is 
having trouble with the "new" lingo in communications.

Imagine when its all said and done, someone getting into this may need 
  to take out a dictionary and print out a legend of new acronyms and 
stick it on his monitor, learn how to pronounced the syllables of the 
new acronyms and to thinking 2-3 times to understand what they mean 
and reflect in email.

Its all nuts. But I am the only person here that feels that way, so 
proceed.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: John Levine <[email-masked]>
Date: 27 Mar 2009 11:37:10 -0000

>> 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
require or imply the existence of the other.

I don't want to hold up this errata/update/whatever any more than it
already is, so I'd suggest taking out any wording about the DNS status
of the SDID.

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.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 27 Mar 2009 06:24:44 -0700

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 DKIM.

Regards,
-sm

---

From: "Siegel, Ellen" <[email-masked]>
Date: Fri, 27 Mar 2009 09:41:09 -0400

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: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf 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:
>

---

From: Hector Santos <[email-masked]>
Date: Fri, 27 Mar 2009 10:32:21 -0400

SM wrote:
> The document is addressed to DKIM implementors.  The document can also 
> be used as a base for extensions built upon DKIM.

Well, before you can have DKIM implementators, they probably have 
something to first with electronic mail, and at some point it all has 
to revert back to layman terms (as we know it today) for customers to 
enjoy.

The question I ask to myself is this:

Can someone successful implement DKIM using RFC 4871 without having to 
resort to this errata?  Or does errata significant enough in fixing 
the original functional specifications that makes it mandatory to have?

-- 
Sincerely

Hector Santos

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 08:46:11 -0400

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: [email-masked] [mailto:[email-masked]] 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)

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 27 Mar 2009 08:30:03 -0700

+1

> corresponding MX or A records and can receive mail.

Any reason for that? It doesn't strike me as an obviously good idea.

Cheers,
   Steve

---

From: Tony Hansen <[email-masked]>
Date: Fri, 27 Mar 2009 11:04:22 -0400

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 domain name whose TXT records
can be accessed using DNS. This is the *only* name out of all of these
that MUST be in the DNS.

	Tony Hansen
	[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Mar 2009 09:40:38 -0700

> can be accessed using DNS. This is the *only* name out of all of these

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.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Mar 2009 13:45:47 -0400

> there were any question at all makes this seem like a rather academic

I agree with Mike.  Let's leave the text as it is, and move on.

Barry (participant)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Mar 2009 11:04:06 -0700 (PDT)

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 WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Mar 2009 10:53:32 -0700

On Mar 27, 2009, at 8:04 AM, Tony Hansen wrote:

> When all is said and done, it's the combination of the "selector  
> +_domainkey + SDID" that must be a valid domain name whose TXT  
> records can be accessed using DNS. This is the *only* name out of  
> all of these that MUST be in the DNS.

A valid DKIM signature confirms the signing agent is controlled by the  
domain indicated in SDID.  A valid signature also establishes an  
authority to assert UAID values that must reside at or under the  
domain.  (A valid DKIM signature verifies the UAID assertion by the  
SDID.)  When UAID values do not match against email-addresses within  
signed header fields, portions of the UAID namespace below the SDID  
may not represent an valid email destination.  However, the UAID value  
always represents an SDID identifier for on whose behalf their  
signature was added.

The SDID value could be seen as analogous to a State issuing a drivers  
license.  A valid signature could be analogous to untampered laser- 
scribed laminate and seals.  The License Number could be analogous to  
that of the UAID, where it might be replaced by a State email-address  
of the driver.  Such replacement can be denoted by its use within  
signed header fields.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 27 Mar 2009 16:19:31 -0600

> -1 on "registered" or "resolvable".

Sounds like the real requirement is that a DKIM verifier be able to figure 
out which key to use, based on that string.  There must be an IETF standard 
way to describe that....

-- 
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

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 28 Mar 2009 10:04:42 -0700

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 dominant sense of the considerable set of postings on this topic 
as being:  Return to the original wording of the Errata draft.

Hence the wording should be: "A single domain name that..." for both SDID and AUID.

Does this match everyone's assessment of consensus?

d/

-- 

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Sun, 29 Mar 2009 07:16:24 +0530

> Does this match everyone's assessment of consensus?

Acceptable.

---

From: "John R. Levine" <[email-masked]>
Date: Mon, 30 Mar 2009 15:32:21 +0100 (BST)

> The following shouldn't be discouraged:
>
> From: [email-masked]
> 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 more than a key 
records.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jeff Macdonald <[email-masked]>
Date: Mon, 30 Mar 2009 10:29:01 -0400

>corresponding MX or A records and can receive mail.

-1

please don't, or at least, please explain.

From: [email-masked]

-- 
Jeff Macdonald
[email-masked]