Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Hector Santos]

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

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


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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[SM]

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

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Steve Atkins]

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


> 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:
>>>
>>> Steve Atkins wrote:
 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).
>>>
>>> Really?
>>>
>>> Then how does the receiver obtain the public key for performing   
>>> verification?
>>>
>>> key retrieval is defined as using d=.
>> 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
>> ___
>> NOTE WELL: This list operates according to 
>> http://mipassoc.org/dkim/ietf-list-rules.html
>
> -- 
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Dave CROCKER]

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:
> 
>>
>> Steve Atkins wrote:
>>> 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).
>>
>> Really?
>>
>> Then how does the receiver obtain the public key for performing  
>> verification?
>>
>> key retrieval is defined as using d=.
> 
> 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
> 
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 

-- 

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Steve Atkins]

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

>
>
> Steve Atkins wrote:
>> 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).
>
>
> Really?
>
> Then how does the receiver obtain the public key for performing  
> verification?
>
> key retrieval is defined as using d=.

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

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Dave CROCKER]

Steve Atkins wrote:
> 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).


Really?

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

key retrieval is defined as using d=.

d/
-- 

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Steve Atkins]

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

Cheers,
   Steve

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Barry Leiba]

We could say "DNS-resolvable".

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Steve Atkins]

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 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.
>>>   A single domain name -> A single, registered domain name
>> Registered with who?
>> 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?

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

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Dave CROCKER]

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
>>>   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.
>>A single domain name -> A single, registered domain name
> 
> Registered with who?
> 
> 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
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Steve Atkins]

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 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.
>
>A single domain name -> A single, registered domain name

Registered with who?

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

Cheers,
   Steve

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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[Barry Leiba]

Apart from what Dave said...

> I don't have any objection about processing the "update" draft as an RFC.

Good.

> If there is Working Group Consensus about Item 2, I would like
> the DKIM Chair to clarify whether any request for a WG call for
> consensus for any submitted errata related to Item 1 will be
> rejected.

No one I'm aware of has any intention of circumventing the WG process.
 Consensus to process "update" (né "errata") as an RFC closes any
consideration of other ways to handle it.

The remaining errata, which were not controversial, will be handled as
errata, as has been planned all along.

> The "update" document affects the ADSP, Overview and Deployment
> documents.  Can the DKIM Chair state in which order the documents
> will be processed?

We're not specifically defining an order.

That said, we believe the effect on ADSP will be small, and I'll have
a note out about that Friday or Saturday, depending upon when I can
get to writing it up.  We expect that ADSP will proceed first, within
the next couple of weeks.

"Deployment" still needs comments, as Tony presented in SF.  We expect
that any necessary changes to "Overview" will go before that, and an
updated version can go back to Pasi soon -- Tony and the other editors
can tell us how that schedule looks.  Deployment will be last of the
three.

In any case, ADSP will not hold up Overview, which would proceed
independent of any unanticipated delay in ADSP.

I don't think any of this should be a surprise.

Barry (as chair)

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Barry Leiba]

>> 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 this for 7?:
A single domain name -> A single domain name, not necessarily registered,

Barry

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Jeff Macdonald]

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 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.
>
>A single domain name -> A single, registered domain name
>
>
>> 
>> 7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)
>...
>>  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.
>
>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?

none for me. +1


-- 
Jeff Macdonald
jmacdon...@e-dialog.com

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Jeff Macdonald]

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 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.
>>
>>A single domain name -> A single, registered domain name
>>
>>
>>>
>>> 7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)
>> ...
>>>  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.
>>
>>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?
>
> none for me. +1

oh, and +1 for the others

-- 
Jeff Macdonald
jmacdon...@e-dialog.com

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

Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine

[Jeff Macdonald]

+1

On Thu, Mar 26, 2009 at 07:28:15AM +0530, Suresh Ramasubramanian wrote:
>I'd probably say 'freudian slip' for that.  And +1 for text with
>Ellen's change below.
>
>On Thu, Mar 26, 2009 at 5:54 AM, Siegel, Ellen
> wrote:
>
>> Can you explain why you used "dedicated to the assessment of the delivered 
>> name" rather than "... of the delivered identifier"? I can live with it 
>> either way, but it seems strange to say that it consumes an identifier but 
>> assesses a name.
>>
>> Aside from that, it looks fine to me.
>___
>NOTE WELL: This list operates according to 
>http://mipassoc.org/dkim/ietf-list-rules.html

-- 
Jeff Macdonald
jmacdon...@e-dialog.com

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

Re: [ietf-dkim] errata revision: Assessor

[Jeff Macdonald]

On Wed, Mar 25, 2009 at 02:29:52PM -0700, Murray S. Kucherawy wrote:
>On Wed, 25 Mar 2009, Eliot Lear wrote:
>>> 8.  RFC4871 Section 2.11 Identity Assessor
>>>
>>>   Old:
>>> The name of the module that consumes DKIM's primary payload, the
>>> responsible Signing Domain Identifier (SDID).  It can optionally
>>> consume the Agent or User Identifier (AUID) value, if provided to
>>> the module.
>>>
>>>   New:
>>> The name of the module that consumes DKIM's mandatory payload, the
>>> responsible Signing Domain Identifier (SDID).  Other DKIM values
>>> can also be delivered this module; however this additional activity
>>> is outside the scope of the DKIM signature specification.
>>
>> Replace "Other DKIM values" to "Other information".
>>
>> My logic: what the assessor consumes beyond the SDID is outside the
>> scope of the spec.
>
>And add "by" between "delivered" and "this".
>
>After that, +1.

+1

-- 
Jeff Macdonald
jmacdon...@e-dialog.com

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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[Dave CROCKER]

SM wrote:
> The three threads created by Dave mention "errata" in the subject 
> line. 


FYI,

After the close of the comment period, I'll issue a new I-D for the document. 
It will say Update rather than Errata.

My continuing use of the word Errata has merely been habit; I mean the document 
that the has been under discussion and I take all discussion about the three 
changes I've asked about as referring to that document...

d/
-- 

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

Re: [ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[SM]

Hi Barry,
At 13:24 26-03-2009, DKIM Chair wrote:
>Regarding the "errata" draft, two points:
>
>1. On the content, we hashed out a few things that needed tweaking, 
>and Dave has
>already posted about these.  The response looks good.  We'll look at a final
>tally on Friday, 3 April, and ask Dave to push out a new draft then.
>
>Please do not discuss this point on this message thread; use Dave's 
>three threads
>for it instead.
>
>
>2. On the process, after discussion with Pasi on the matter, there was an
>overwhelming consensus in the room to move forward by processing the "errata"
>draft as an RFC (with a change in the title to "update" instead of "errata").
>Pasi has agreed to expedite the handling, so it should get to the RFC editor
>quickly.  We need to confirm that on the mailing list, and in this 
>case, silence
>will be taken as consent.  If there are no objections, it looks like 
>the 3 April
>draft will be that final version.

I don't have any objection about processing the "update" draft as an RFC.

The three threads created by Dave mention "errata" in the subject 
line.  If there is Working Group Consensus about Item 2, I would like 
the DKIM Chair to clarify whether any request for a WG call for 
consensus for any submitted errata related to Item 1 will be 
rejected.  I prefer to see the procedure followed so that we can 
close this issue.

The "update" document affects the ADSP, Overview and Deployment 
documents.  Can the DKIM Chair state in which order the documents 
will be processed?

Regards,
-sm 

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

[ietf-dkim] (registered) domain name (Re: errata revision: opaque)

[Dave CROCKER]

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


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 
and one for AUID:

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

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


> 
> 7.  RFC4871 Section 2.10 Agent or User Identifier (AUID)
...
>  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.

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

Re: [ietf-dkim] errata revision: Assessor

[Jim Fenton]

Siegel, Ellen wrote:
>   
>> 8.  RFC4871 Section 2.11 Identity Assessor
>>
>>Old:
>>  The name of the module that consumes DKIM's primary
>> 
>> payload, the
>> 
>>  responsible Signing Domain Identifier (SDID).  It can
>> 
>> optionally
>> 
>>  consume the Agent or User Identifier (AUID) value, if
>> 
>> provided to
>> 
>>  the module.
>>
>>New:
>>  The name of the module that consumes DKIM's mandatory
>> 
>> payload, the
>> 
>>  responsible Signing Domain Identifier (SDID).  Other DKIM
>> 
>> values
>> 
>>  can also be delivered this module; however this additional
>> 
>> activity
>> 
>>  is outside the scope of the DKIM signature specification.
>> 
> Replace "Other DKIM values" to "Other information".
>
> My logic: what the assessor consumes beyond the SDID is outside the
> scope of the spec.
>   
 And add "by" between "delivered" and "this".

 After that, +1.
 
>>> +1
>>>   
>> +1
>>
>> 
> +1
>   

Me too.

-Jim

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

Re: [ietf-dkim] errata revision: opaque

[Jim Fenton]

Dave CROCKER wrote:

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

Dave CROCKER wrote:
  
  
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.

  
  

   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.
  


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



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

Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine

[Jim Fenton]

+1 with Ellen's change.

-Jim

Siegel, Ellen wrote:
>   
>> -Original Message-
>>
>> "Old" refers to the Errata I-D; "New" is the proffered replacement.
>>
>> CAVEAT:
>>
>> This last-of-three postings affects the same section of text as the
>> Assessor
>> revision posting, but attends to a different issue.  I've only just gotten
>> clarification on what this third item was to be, so here's another apology
>> for a
>> bit of confusion.
>>
>> Had I remembered all 3 items I would have tried to merge this with the
>> other
>> Assessor change, which is what the current note attempts:
>>
>>
>> 8.  RFC4871 Section 2.11 Identity Assessor
>>
>>
>> Old:
>>The name of the module that consumes DKIM's primary payload, the
>>responsible Signing Domain Identifier (SDID).  It can optionally
>>consume the Agent or User Identifier (AUID) value, if provided to
>>the module.
>>
>> New:
>>The name of the module that consumes DKIM's mandatory payload, the
>>responsible Signing Domain Identifier (SDID). The module is
>> dedicated
>>to the assessment of the delivered name.  Other DKIM (and non-DKIM)
>>values can also be delivered to this module as well as to a more
>> general
>>message evaluation filtering engine. However this additional
>> activity
>>is outside the scope of the DKIM signature specification.
>>
>> 
>
> Can you explain why you used "dedicated to the assessment of the delivered 
> name" rather than "... of the delivered identifier"? I can live with it 
> either way, but it seems strange to say that it consumes an identifier but 
> assesses a name. 
>
> Aside from that, it looks fine to me. 
>
> Ellen
>
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>
>   

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

[ietf-dkim] Consensus points on "errata" draft from the IETF 74 meeting

[DKIM Chair]

Regarding the "errata" draft, two points:

1. On the content, we hashed out a few things that needed tweaking, and Dave 
has 
already posted about these.  The response looks good.  We'll look at a final 
tally on Friday, 3 April, and ask Dave to push out a new draft then.

Please do not discuss this point on this message thread; use Dave's three 
threads 
for it instead.


2. On the process, after discussion with Pasi on the matter, there was an 
overwhelming consensus in the room to move forward by processing the "errata" 
draft as an RFC (with a change in the title to "update" instead of "errata"). 
Pasi has agreed to expedite the handling, so it should get to the RFC editor 
quickly.  We need to confirm that on the mailing list, and in this case, 
silence 
will be taken as consent.  If there are no objections, it looks like the 3 
April 
draft will be that final version.

Please post any objections or process discussions to this thread.


I'll send a separate note about ADSP.

Barry

--
Barry Leiba, DKIM working group chair  (barryle...@computer.org)
http://internetmessagingtechnology.org/

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Paul Russell]

On 3/26/2009 11:41, Hector Santos wrote:

> The question is whether DKIM is to replace any IP technology, 
> specifically SPF.

...

> Anyway, the point is MOST SMTP vendors are in the business of provide 
> CHOICE not LIMITING it.

As an email systems administrator, I view DKIM as a potential addition to my
toolbox, not as a replacement for any/all of the tools already in my toolbox.

I see SPF and DKIM as complementary, not competing, technologies.  A site might
perform both SPF checks and DKIM signature verification, and configure their
systems to allow a verified DKIM signature to override a failed SPF check when
determining the disposition of an inbound message.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
pruss...@nd.edu

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

Stephen Farrell wrote:
> 
> Murray S. Kucherawy wrote:
>> Perhaps some other vendors would like to weigh in.
> 
> I'm not at all sure we really need to have that discussion on here.
> The logic being that it doesn't affect what we do or don't say in
> the errata I-D.

My only point was to not getting into yet another useless THAT (SPF) 
vs THIS (DKIM) argument and debate that gets us no way.  I was hoping 
at this point we would be more open minded about all this - there is 
NO ONE WAY.

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

Wietse Venema wrote:
> Murray S. Kucherawy:
>> On Thu, 26 Mar 2009, Hector Santos wrote:
>>> And as long as this mindset persist, you are going to get the funny 
>>> looks from many disciplines in this market - mainly SMTP vendors!
>> I represent an SMTP vendor, and I'm not sending funny looks.  I'm pleased 
>> with these developments, and I concur with the stated guidance.
> 
> I'm kind-of a vendor, but I would not spend energy debating
> positions that have only one supporter.

We know you wouldn't because you probably cursed them away as you did 
and tried with me.

The fact is, other vendors, are probably sick and tired with the 
attitude of people like you and others dictating ways that will HURT 
more than it will help.

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[MH Michael Hammer (5304)]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Wietse Venema
> Sent: Thursday, March 26, 2009 3:19 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] what is a standard, was errata revision:
Assessor
> 
> Murray S. Kucherawy:
> > On Thu, 26 Mar 2009, Hector Santos wrote:
> > > And as long as this mindset persist, you are going to get the
funny
> > > looks from many disciplines in this market - mainly SMTP vendors!
> >
> > I represent an SMTP vendor, and I'm not sending funny looks.  I'm
> pleased
> > with these developments, and I concur with the stated guidance.
> 
> I'm kind-of a vendor, but I would not spend energy debating
> positions that have only one supporter.
> 
>   Wietse


I'm not a vendor but I figure some people prefer vanilla ice cream and
some people prefer chocolate ice cream. Some people find both to their
taste. Go figure.

Mike

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Wietse Venema]

Murray S. Kucherawy:
> On Thu, 26 Mar 2009, Hector Santos wrote:
> > And as long as this mindset persist, you are going to get the funny 
> > looks from many disciplines in this market - mainly SMTP vendors!
> 
> I represent an SMTP vendor, and I'm not sending funny looks.  I'm pleased 
> with these developments, and I concur with the stated guidance.

I'm kind-of a vendor, but I would not spend energy debating
positions that have only one supporter.

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Stephen Farrell]

Murray S. Kucherawy wrote:
> Perhaps some other vendors would like to weigh in.

I'm not at all sure we really need to have that discussion on here.
The logic being that it doesn't affect what we do or don't say in
the errata I-D.

Stephen.

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

Murray S. Kucherawy wrote:

>> Sorry, but vendors do not have this luxury.  You would be in conflict 
>> with your operators and customers desires to implement, enable and/or 
>> disable what they want and not what you or I want.
> 
> Your customers don't seek or accept any guidance from you?

Of course.

>> We simple can not dictate to others or even suggest not to use SPF or 
>> another technology and replace with DKIM especially when it hasn't 
>> really proven to have a payoff.
> 
> Sorry, I disagree.  Vendors, especially those who have been involved in 
> this for a long time, are in a prime position to provide appropriate 
> guidance and influence. 

25+ years in the mail business myself. Should give me some confidence 
in expressing what I feel.

> And at least from where I'm sitting, a 
> substantial portion of the customer base is at least listening to what 
> we tell them.  And sometimes "customer" is itself referring to a large 
> and influential ISP.

I agree. Customers follow your lead.  However, we can't tell them:

 "Oh btw, SPF sucks!  Don't use it."

>> So yes, when I read those comments, the eyes are rolling.
> 
> I have no doubt *you* think the ideas are absurd. 

Not absurd but silly. I was referring to the yet another useless SPF 
sucks reference that gets us no way.

> But please stop speaking for all SMTP vendors, 

Murray, I am not speaking for ALL SMTP vendors, nor did I say I was. 
I believe SMTP developers are more keen to accepting SPF then 
operators who are bent on accepting all mail and using reputation 
based services.   With all speak in generality in ways to attempts 
represent a common idea, maybe nor yours, but others.

 > because I for one think you're
 > exaggerating, and have experience to the contrary.

Exaggerating what specifically? and what does that mean "experience to 
the contrary?"  If I think I know what you mean, I hope you don't "go 
there."

> Perhaps some other vendors would like to weigh in.

The question is whether DKIM is to replace any IP technology, 
specifically SPF.

Murray, you are going to get different view points.  The fact of the 
matter there are MILLIONS of systems using it.  It isn't going to go away.

Anyway, the point is MOST SMTP vendors are in the business of provide 
CHOICE not LIMITING it.

Are you not in that business?


-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Murray S. Kucherawy]

On Thu, 26 Mar 2009, Hector Santos wrote:
>  > With specific reference to DKIM, what I most want to discourage is
>  > awful IP/domain hybrid hacks like only validating a signature if
>  > the Sender-ID or SPF passes.  So our interop advice is when you're
>  > thinking about DKIM, don't think about IP addresses.
>
> Sorry, but vendors do not have this luxury.  You would be in conflict 
> with your operators and customers desires to implement, enable and/or 
> disable what they want and not what you or I want.

Your customers don't seek or accept any guidance from you?

> We simple can not dictate to others or even suggest not to use SPF or 
> another technology and replace with DKIM especially when it hasn't 
> really proven to have a payoff.

Sorry, I disagree.  Vendors, especially those who have been involved in 
this for a long time, are in a prime position to provide appropriate 
guidance and influence.  And at least from where I'm sitting, a 
substantial portion of the customer base is at least listening to what we 
tell them.  And sometimes "customer" is itself referring to a large and 
influential ISP.

> So yes, when I read those comments, the eyes are rolling.

I have no doubt *you* think the ideas are absurd.  But please stop 
speaking for all SMTP vendors, because I for one think you're 
exaggerating, and have experience to the contrary.

Perhaps some other vendors would like to weigh in.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

Murray S. Kucherawy wrote:
> On Thu, 26 Mar 2009, Hector Santos wrote:
>> And as long as this mindset persist, you are going to get the funny 
>> looks from many disciplines in this market - mainly SMTP vendors!
> 
> I represent an SMTP vendor, and I'm not sending funny looks.  I'm 
> pleased with these developments, and I concur with the stated guidance.

Just to make sure of the specifics my comments addressed:

  > Levine stated:

  > With specific reference to DKIM, what I most want to discourage is
  > awful IP/domain hybrid hacks like only validating a signature if
  > the Sender-ID or SPF passes.  So our interop advice is when you're
  > thinking about DKIM, don't think about IP addresses.

Sorry, but vendors do not have this luxury.  You would be in conflict 
with your operators and customers desires to implement, enable and/or 
disable what they want and not what you or I want.

As a vendor, you have a choice to either built it in, as you do with 
mfilters, as we do with our pcode language as other packages have with 
their embedded languages.  Operators and 3rd party developers can also 
create these add-ons either for their specific sites or sell/give away 
for others us, free or otherwise.

We simple can not dictate to others or even suggest not to use SPF or 
another technology and replace with DKIM especially when it hasn't 
really proven to have a payoff.

So yes, when I read those comments, the eyes are rolling.

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Murray S. Kucherawy]

On Thu, 26 Mar 2009, Hector Santos wrote:
> And as long as this mindset persist, you are going to get the funny 
> looks from many disciplines in this market - mainly SMTP vendors!

I represent an SMTP vendor, and I'm not sending funny looks.  I'm pleased 
with these developments, and I concur with the stated guidance.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID

[Hector Santos]

MH Michael Hammer (5304) wrote:

> Hector,
> 
> This is exactly why I said in the article:
> 
> "Some might assert that an organization should never DKIM sign a
> non-existent message-id header. At this time it is not clear, at least
> to me, that this is absolutely true. The implications of signing versus
> not signing under these circumstances certainly merit a healthy
> discussion before a verdict is reached." 
> 
> I've seen little if any (systematic) discussion of the various cases
> (for all headers) and how unsigned non-existent (at time of injection to
> the mail stream or signing) might be abused at a later point. Most of
> the discussion is about how things SHOULD function, not how they might
> be abused.

I agree.   As I call it "protocol consistency". Simply put, we don't 
have it here.



I think there were many discussions in the past when SSP was still 
part of the picture.  SSP is what sold DKIM to me and others. The 
strong early emphasis and marketing presentation points wrt to SSP was 
the deciding difference over DKEYS.

ADSP watered it down and since we no longer have a true champion of 
policy based DKIM implementations speaking on our behalf, our voices 
and concerns are ignored and stamped out.

I will say, if ADSP is not part of the picture, I will not bother with 
DKIM. Maybe, if someone came with a DNS DKIM ZONE, that had only a 
listing of domains with ALWAYS SIGN, but with nothing like this, pure 
DKIM processing will be a waste of time.

I should of never gave up on DSAP (DKIM Signature Authorization 
Protocol) and kept on it. I only did so after being told SSP would be 
more considerate of the concerns outlined in DSAP.   If I knew SSP was 
going to be taken over by ADSP especially by someone who never 
believed in POLICY to begin with, which made the whole process, well, 
stink, no doubt I would had never given up on DSAP.

Oh well, as long as DKIM-BASE remains open and not locked down to 
specific accessors and reputation trust services, then at least there 
is still hope for new I-D and inventions to happen.  Maybe then I will 
introduce DSAP again.

While there might be some folks here that despise SPF, and even among 
those who support it and know its not 100% perfect, it did prove one 
thing:

 The industry desire to accept the idea of a DOMAIN EMAIL
 POLICY Discovery process solidified by the millions of domains
 and receivers that support SPF.

There is no doubt about that.



-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Dave CROCKER]

John R. Levine wrote:
> Sure, but you don't write the implementation guide into the standard. 


And while it's not, strictly speaking, an implementation guide, the working 
group's Deployment draft is in that direction, which is why it would be great 
for folks to take a look and start commenting on it...

DomainKeys Identified Mail (DKIM) Development, Deployment and Operations



d/
-- 

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

Re: [ietf-dkim] errata revision: opaque

[Barry Leiba]

Charles says...
> 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.

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Eliot Lear]

The problem here, John, is that we are /sort of/ standardizing the 
communication path between verifier and assessor.  I want it clear that 
other information will necessarily flow.  Dave's proposed text does 
that, so I'm happy.


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

Eliot Lear wrote:
> John,
> 
> I want to not constrain the document to the point where it does not 
> reflect the complexities of the reality in which we find ourselves.  
> You've stated that reality below, by the way.  A very simple decision 
> tree one could easily envision is something along the following:
> 
> [Sender]>[Signer]-->[...]--->[verifier]-->[DBLs]--->...
> 
> ...->  [pass]-->[dkim|spf|other]-->[assessor]-->[...]-->[mda]
> 
> 
> 
> Or, put in other terms:
> 
> [Outlook]>[Exchange]-->[...]--->[sendmail]-->[RBLs]--->...
> 
> ...->  [pass]-->[milters]-->[spamassassin]>[mda]
> 
> 
> These diagrams aren't perfect, but I think the illustrate one approach 
> we see in the wild.

It has to be generalized which I believe is one of a fundamental 
philosophical differences between Developers vs Administrators:

Model 1:

Sender -> SMTP <--> DATA <--> DKIM/ACCESSOR(S)

Model 2:

Sender -> SMTP -->  accept -> post smtp --> DKIM/ACCESSOR(S)

In model 1, all process variables are readable to the dynamic DATA 
shims, hooks, processed online in real time during the SMTP session.
Rejection here provides feedback and satisfies all technical (and 
legal) requirements (practices).  If one implements ADSP, the term 
discardable is more of a rejection.

In model 2, we have the post smtp (accept first) framework where how 
data is passed to the DKIM/ACCESSORS depends on the storage framework 
of the backend.  Here you can have, for example:

 - 1 file per message in a RFC 822/2822/5322 format
 - can come with index and/or meta files.

 - some proprietary or open spec database,
 - SQL, SDK/API I/O, RPC client/server, etc.

This model 2 is more flexible for mail bot scripting, especially if 
the storage is raw in RFC format.   This is also where lost of 
controls  of what is stripped, added, signed or not signed.  Just as 
note, ours is a proprietary database with a RPC client/server API, so 
we have full control of what "accessors" will have access and they 
must adhere to our storage format.  This is why to open to the door 
for 3rd party developers, we use the DATA approach which gives them 
access to the temporary RFC storage prior to full acceptance and final 
database storage.

The problem model 2 presents today is the ACCEPT/BOUNCE RFC 5321 
requirement dilemma.  Thus ADSP needs terms like DISCARDABLE to make 
it acceptable to just drop and discard messages - not like a SMTP 
REJECT which has notifications designs built in.

Anyway, the point is until we recognize the different models here and 
how depending on the model, an approach is taken, with  one side 
(model 2) thinking the other model 1 doesn't exist, will never 
significantly exist (even when all indications show this is the 
direction with more powerful machines) or that they believe that all 
storage is 1 way only, then it will have to get consensus with across 
the board considerations.

This is why I agree with you, that we should not lock in what 
information is preserved for accessors because we don't even know what 
these accessors are and/or how and when they are going to be processed.

We need to generalized this protocol so that it fits both dynamic SMTP 
and post SMTP models.

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[John R. Levine]

> I want to not constrain the document to the point where it does not reflect 
> the complexities of the reality in which we find ourselves.

Assuming I've counted your negatives correctly, I think I understand what 
you want, and although it is a perfectly reasonable way to write one's 
code, it's not a good way to write a standard.

People do all sorts of stuff, much of which we can't anticipate.  Trying 
to guess all the ways that people will use or abuse standards just leads 
to confusion.

> While I understand your desire, let there be room for people do try what 
> what works, and to adapt to circumstances.

Sure, but you don't write the implementation guide into the standard. 
You limit it to the rules to interoperate.  That's why the SMTP standard 
doesn't say oh, you could also use uucp.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID

[HLS]

On Wed, Mar 25, 2009 at 10:14 PM, Mark Martinec
 wrote:
>
> Hector Santos wrote:
> > The problem is protocol consistency.  The signer within the domain
> > network needs to make sure it adds the missing headers.
>
> There is probably a general agreement that a message when submitted
> to a signer should contain all mandatory header fields (From and Date)
> as required by RFC 5322, along with all the SHOULD ones (Message-ID,
> and some others in special cases according to section 3.6).
> And it should be syntactically correct in other aspects too (line length,
> allowed characters, ...), otherwise a garbage-in garbage-out principle
> applies.
>
> It also seems prudent to supply a To, even though it is not required by
> the RFC 5322, as many MTAs or MUAs expect it and/or supply it if missing.


Many systems, including ours, leave level of compliance up to the
operator.  Some systems, will abort the transaction (at DATA) when the
headers did not to either 822, 2822/5322.  Others will do the same
post SMTP (accept first). Some systems behavior as drop off points for
printers, faxing, text messagings, etc using simple clients where the
addressing is purely at the envelope.  Not the headers. Generally,
these systems required authenticated clients. The submission protocol
may also enforce the injection of headers.

I'm old school though, I really really really hate middle ware that
fool with passthru mail.  so if this is an original submission,
that is one thing, you have more ethical engineering acceptance and
authority to "adjust" the mail.  With relays, other than adding the
required trace headers, I always leaned on not "adjusting" the
headers.  It is really a taboo to do so.  I believe RFC 5322 reflects
this traditional practice.

> > And receivers really should not be adding one - especially if it is as you
> > say, DKIM compliant.
>
> I don't agree with the above. I think the core issue is the fact that
> there is a great semantic difference between including an absent
> header field name into the 'h' tag, and including an existing one.
> The fact that DKIM uses the same syntactic mechanism to express
> each is just a coincidence.

Well, I am quickly coming to cerment the reality that much of the
philosophical and discipline conflicts depends on how one expects to
use DKIM.

I come from an Fault Tolerance background - AI, Expert Systems,
process controllers, simulators, modeling, etc. where fault detection
is very much part of the working success of a system.

So if you (speaking in general) can't define how to handle DKIM
faults, I find to see how one can succesfully work in the handling of
DKIM whitelisting without eliminating or reducing the abuse of it.

So even if one wants to use DKIM for whitelisting, you still need to
protects against the faults of the WhiteListing models.

> > The DKIM specification clearly says what headers SHOULD be considered
> > and what SHOULD NOT.  I always felt there should a default and that h=
> > was optional (to reduce the bandwidth), but having h= should help
> > remove any guessing.
>
> The invention of an 'h' tag made a tremendous improvement in survivability
> of a DKIM signature over the initial DomainKeys drafts.

But thats because DKEYS signed all headers.  I was referrig to a
default set of headers.  For example, no h=, might mean the basic
fundamental headers:

   From:
   To:
   Subject:
   Date:

at the very least, something 100% of all mail systems have, and 99.99%
of all rendering devices ergonimically show to users.

[Note: I'm not proposing to make it optional]

> > > - signature includes Message-ID in h tag, but there was no Message-ID in
> > >   the original message at the time of signing. When a receiving MX
> > > inserts a missing header field, it breaks the signature.
> >
> > But if it was signed with one, then someone stripped it before the MX
> > got it.
>
> Not in cases I observed. There was no Message-ID at the time of signing.
> It's easy to prove - just deleting the late-added Message-ID makes a
> signature valid again.

Ok, I was scatching my head by what you mean by MX.  Do you mean the
MDA?  Sure, the MX does not have to be a MDA, it can be a router.

This all goes back to my first point above.  It is final destination
or a relay.  Problems begin when relays begin to tamper with mail.
But if its final destination, why would a DKIM-aware reciever add
something before it attempts to validate the signature, if any?

> > This is an issue for many.  We are talking about the MS-DOS, UNIX vs
> > MAC storage and/or display world.  This is one of the reasons why we
> > have not implemented yet.
>
> That was a lone incident of bare CR characters finding their way into
> a message. It was due to a bug in a disclaimer-adding software.
>
> I don't think that MS/Unix/Mac differences in line endings will present
> a share of failures worth mentioning. So far I have yet to find a single
> case of such breakage. The DKIM rfc is clear on it, and as long as
> 

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Eliot Lear]

John,

I want to not constrain the document to the point where it does not 
reflect the complexities of the reality in which we find ourselves.  
You've stated that reality below, by the way.  A very simple decision 
tree one could easily envision is something along the following:

[Sender]>[Signer]-->[...]--->[verifier]-->[DBLs]--->...

...->  [pass]-->[dkim|spf|other]-->[assessor]-->[...]-->[mda]



Or, put in other terms:

[Outlook]>[Exchange]-->[...]--->[sendmail]-->[RBLs]--->...

...->  [pass]-->[milters]-->[spamassassin]>[mda]


These diagrams aren't perfect, but I think the illustrate one approach 
we see in the wild.
> Standards can't compel anyone to do anything.  The most they can do is
> to tell you how to make it most likely that you will interoperate with
> everyone else.  That's why rules like nobody else can sign my mail are
> silly and unenforcable, and why I carefully worded the discardable bit
> in ADSP to make it clear that it's advice, not a command.
>

We'll come to that point.  You and I have a draft to write, still, by 
the way, about DNS and ADSP experiences.

> As Dave reminded us yesterday, the primary goal of DKIM is to provide
> a better handle than IP address for managing mail.  The best way to
> make that work is to agree as clearly as possible what that handle is.
> We tell senders that's the handle to put in signatures so receivers
> recognize them, and we tell receivers that's the handle to check to
> best know who's trying to talk to you.  Assessors will certainly do
> all sorts of other stuff as well, but this is the best advice on how
> to interoperate with DKIM.
>

Right.  And so I am comfortable with the changes Dave proposed.
> With specific reference to DKIM, what I most want to discourage is
> awful IP/domain hybrid hacks like only validating a signature if the
> Sender-ID or SPF passes.  So our interop advice is when you're thinking
> about DKIM, don't think about IP addresses.
>

While I understand your desire, let there be room for people do try what 
what works, and to adapt to circumstances.  You might say that this does 
not sufficiently constrain the situation from an interoperability 
perspective, but I am concerned that doing otherwise will cause this 
work to be ignored due to pragmatic real needs, the obvious case being 
the converse of what you wrote above, where a DKIM signature check is 
made only when an SPF check fails.  Only actual data and analysis will 
tell you whether that order is reasonable.

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

Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID

[MH Michael Hammer (5304)]

> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Hector Santos
> Sent: Thursday, March 26, 2009 7:40 AM
> To: IETF-DKIM
> Subject: Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID
> 
> Charles Lindsey wrote:
> > On Wed, 25 Mar 2009 11:28:52 -, Hector Santos
> >  wrote:
> >
> >
> >>> - eBay and PayPal: signs non-existent Resent-From, preventing
> resending
> >>
> >> Another case of BLIND signing!  Read the freaking specs!!
> >
> > Not necessarily. Signing a non-existent header is a valid way of
> > preventing it being added subsequently, and maybe that is what you
want
> > (e.g. in this case if the mail is "for original recipient's eyes
only").
> > Not that Ebay and Paypal were necessarily trying to do that,
although
> > they are the sort of organisations that just might want to do it in
> > specific situations.
> 
> Good point Charles.
> 
> I guess I can see benefits of signing an non-existing header with the
> intent to preempt some downlink injection.  But only from the
> standpoint of the intent to force a failure handling process. i.e,
> eBay, Paypal and entities of the like do not expect these failures to
> be ignored.  Possible example is Reply-To.  They might not want a
> Reply-To and will rely on From: for any user feedback.  So they sign
> an non-existing Reply-to, this preventing any replays with an injected
> Reply-to for MUAs to use.
> 
> I can see that.
> 
> 

Hector,

This is exactly why I said in the article:

"Some might assert that an organization should never DKIM sign a
non-existent message-id header. At this time it is not clear, at least
to me, that this is absolutely true. The implications of signing versus
not signing under these circumstances certainly merit a healthy
discussion before a verdict is reached." 

I've seen little if any (systematic) discussion of the various cases
(for all headers) and how unsigned non-existent (at time of injection to
the mail stream or signing) might be abused at a later point. Most of
the discussion is about how things SHOULD function, not how they might
be abused.

Mike

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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[Hector Santos]

John Levine wrote:
>>> The reason for saying DKIM, here, was to make sure the reader knows 
>>> it's ok for other DKIM-Sig values to be delivered.  Without the DKIM 
>>> reference, the sentence would seem to be so broad as to have truly 
>>> nothing to do with DKIM.
>> 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?
> 
> Standards can't compel anyone to do anything.  The most they can do is
> to tell you how to make it most likely that you will interoperate with
> everyone else.  That's why rules like nobody else can sign my mail are
> silly and unenforcable, and why I carefully worded the discardable bit
> in ADSP to make it clear that it's advice, not a command.
> 
> As Dave reminded us yesterday, the primary goal of DKIM is to provide
> a better handle than IP address for managing mail.  The best way to
> make that work is to agree as clearly as possible what that handle is.
> We tell senders that's the handle to put in signatures so receivers
> recognize them, and we tell receivers that's the handle to check to
> best know who's trying to talk to you.  Assessors will certainly do
> all sorts of other stuff as well, but this is the best advice on how
> to interoperate with DKIM.
> 
> With specific reference to DKIM, what I most want to discourage is
> awful IP/domain hybrid hacks like only validating a signature if the
> Sender-ID or SPF passes.  So our interop advice is when you're thinking
> about DKIM, don't think about IP addresses.

And as long as this mindset persist, you are going to get the funny 
looks from many disciplines in this market - mainly SMTP vendors!

The funny thing here, we don't POLICY, yet we dictate policy.  John, 
you have no control over what people will use and how it will be 
blended.  The fact is, envelope comes first, not payload, so you will 
always have this to deal with.

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] errata revision: opaque

[Charles Lindsey]

On Wed, 25 Mar 2009 20:56:12 -, Dave CROCKER  wrote:


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

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: ...@clerew.man.ac.uk  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

Re: [ietf-dkim] Postfix: change of Content-Transfer-Encoding breaks DKIM signature / RFC recommendation

[Charles Lindsey]

On Wed, 25 Mar 2009 21:55:48 -, Florian Sager  wrote:

>>> According to the mails below the RFC compliant change of content
>>> encoding in MTA-forwarding may break signatures that follow the RFC  
>>> 4871
>>> recommendation to include header "Content-Transfer-Encoding" in the
>>> signature. This header should be removed from section 5.5. Recommended
>>> Signature Content (The following header fields SHOULD be included in  
>>> the
>>> signature ...).
>>>
>>
>> Unfortunately, this does not solve the problem.  The 8bit-MIME to
>> 7bit conversion as required(*) in RFC 1652 replaces the entire
>> message body, and therefore it invalidates DKIM signatures even
>> when the Content-Transfer-Encoding header is not signed.
>>
> Well, I thought the canonicalization would reduce the encoding problems
> but I didn't check this.
> I expect if a redesign of DKIM would take place an improved
> canonicalization method could solve this problem?

Indeed, I pointed this out when I first joined this list, but it was too
late for inclusion in our draft at that time (though the Chair did suggest
I should write up a draft for an enhancement, and it could indeed be done
if/when we do a full -bis).

There are details of my canonicalization at
http://www.cs.man.ac.uk/~chl/uncode/uncode.html



-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  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

Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID

[Hector Santos]

Charles Lindsey wrote:
> On Wed, 25 Mar 2009 11:28:52 -, Hector Santos 
>  wrote:
> 
> 
>>> - eBay and PayPal: signs non-existent Resent-From, preventing resending
>>
>> Another case of BLIND signing!  Read the freaking specs!!
> 
> Not necessarily. Signing a non-existent header is a valid way of 
> preventing it being added subsequently, and maybe that is what you want 
> (e.g. in this case if the mail is "for original recipient's eyes only"). 
> Not that Ebay and Paypal were necessarily trying to do that, although 
> they are the sort of organisations that just might want to do it in 
> specific situations.

Good point Charles.

I guess I can see benefits of signing an non-existing header with the
intent to preempt some downlink injection.  But only from the
standpoint of the intent to force a failure handling process. i.e, 
eBay, Paypal and entities of the like do not expect these failures to 
be ignored.  Possible example is Reply-To.  They might not want a 
Reply-To and will rely on From: for any user feedback.  So they sign 
an non-existing Reply-to, this preventing any replays with an injected 
Reply-to for MUAs to use.

I can see that.


-- 
Sincerely

Hector Santos
http://www.santronics.com



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

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

[John Levine]

>> The reason for saying DKIM, here, was to make sure the reader knows 
>> it's ok for other DKIM-Sig values to be delivered.  Without the DKIM 
>> reference, the sentence would seem to be so broad as to have truly 
>> nothing to do with DKIM.
>
>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?

Standards can't compel anyone to do anything.  The most they can do is
to tell you how to make it most likely that you will interoperate with
everyone else.  That's why rules like nobody else can sign my mail are
silly and unenforcable, and why I carefully worded the discardable bit
in ADSP to make it clear that it's advice, not a command.

As Dave reminded us yesterday, the primary goal of DKIM is to provide
a better handle than IP address for managing mail.  The best way to
make that work is to agree as clearly as possible what that handle is.
We tell senders that's the handle to put in signatures so receivers
recognize them, and we tell receivers that's the handle to check to
best know who's trying to talk to you.  Assessors will certainly do
all sorts of other stuff as well, but this is the best advice on how
to interoperate with DKIM.

With specific reference to DKIM, what I most want to discourage is
awful IP/domain hybrid hacks like only validating a signature if the
Sender-ID or SPF passes.  So our interop advice is when you're thinking
about DKIM, don't think about IP addresses.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] errata revision: Assessor

[Hector Santos]

Eliot Lear wrote:
> On 3/25/09 10:28 PM, Dave CROCKER wrote:
 >
>> The reason for saying DKIM, here, was to make sure the reader knows 
>> it's ok for other DKIM-Sig values to be delivered.  Without the DKIM 
>> reference, the sentence would seem to be so broad as to have truly 
>> nothing to do with DKIM.
> 
> 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?

+1

Why can't this "sentence" reflect the reality that the DKIM parameters 
or results to be pass to assessors is going to be function of the 
assessors themselves?

The model must be able to make available all 5321/5322 process 
variables.  What is passed or used by assessors will depend on what we 
are talking about.


-- 
Sincerely

Hector Santos
http://www.santronics.com


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

Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID

[Charles Lindsey]

On Wed, 25 Mar 2009 11:28:52 -, Hector Santos 
wrote:


>> - eBay and PayPal: signs non-existent Resent-From, preventing resending
>
> Another case of BLIND signing!  Read the freaking specs!!

Not necessarily. Signing a non-existent header is a valid way of
preventing it being added subsequently, and maybe that is what you want
(e.g. in this case if the mail is "for original recipient's eyes only").
Not that Ebay and Paypal were necessarily trying to do that, although they
are the sort of organisations that just might want to do it in specific
situations.



-- 
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl
Email: ...@clerew.man.ac.uk  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