Subject: [ietf-dkim] Modified Introduction text for rfc4871-errata

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Jun 2009 08:50:23 +0200

Folks,

In reviewing the errata (Update) draft, the IESG expressed concern that a reader 
could miss that there is a potential for software changes due to the change in 
the specification.  Indeed, some IESG readers and others did believe there was 
no software change needed.

To clarify things, without producing text that makes integration into the base 
document a challenge later, a modification to the Introduction is proposed.  I'm 
circulating it to the mailing list to be sure that there are no land mines in 
its interpretations.

If the proposed changes causes you particular heartburn, please explain your 
concern in detail.

Thanks.

d/

Existing Introduction text:

>    This currently leaves signers and assessors with the potential for
>    having differing -- and therefore non-interoperable --
>    interpretations of how DKIM operates.
> 
>    This update resolves this confusion.  It defines new labels for the
>    two values, clarifies their nature, and specifies their relationship.
> 

Proposed text:

       <t>This currently leaves signers and assessors with the potential for
         making different interpretations between the two identifiers and may
         lead to interoperability problems. A signer could intend one to be
         used for reputation, and have a non-reputation intent in setting the
         value in the other. However the assessor might choose the wrong value
         and produce an unintended (and inaccurate) reputation assessment.</t>

       <t>This update resolves that confusion.  It defines additional, semantic
         labels for the two values, clarifies their nature and specifies their
         relationship.  More specifically, it clarifies that the identifier
         intended for reputation lookups (such as white lists) by the
         assessor is the value of the "d=" tag. However, this does not
         prohibit message filtering engines from using the "i=" tag, or any
         other information in the message header, for filtering decisions. </t>

       <t>For signers and assessors that have been using the i= tag for
         reputation assessment a software change to using the d= tag is intended.
       </t>

-- 

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 12 Jun 2009 07:34:53 -0700

This text inappropriately makes a normative requirement on reputation 
systems. Reputation
systems are explicitly outside of the scope of our charter. As well they 
should be as there
has been no discussion about reputation systems may or may not find 
useful, let alone
require, from DKIM.

       Mike

---

From: Barry Leiba <[email-masked]>
Date: Fri, 12 Jun 2009 10:37:58 -0400

>         reputation assessment a software change to using the d= tag is intended.

WFM.

Barry, as participant

---

From: [email-masked] (Wietse Venema)
Date: Fri, 12 Jun 2009 12:56:51 -0400 (EDT)

>          reputation assessment a software change to using the d= tag is intended.

+0.99 

This clarifies what is the primary identifier that signers 
intend to send to assessors.

If it helps to avoid stepping on sensitive toes, you could drop
the last sentence, but I can live with it.

	Wietse

---

From: Doug Otis <[email-masked]>
Date: Fri, 12 Jun 2009 11:07:36 -0700

On Jun 11, 2009, at 11:50 PM, Dave CROCKER wrote:
>>   This currently leaves signers and assessors with the potential  
>> for having differing -- and therefore non-interoperable --  
>>   This update resolves this confusion.  It defines new labels for  
>> the two values, clarifies their nature, and specifies their  
>> relationship.
>
> Proposed text:
>
> value in the other. However the assessor might choose the wrong  
> value and produce an unintended (and inaccurate) reputation  
> assessment.
>
> This update resolves that confusion.  It defines additional,  
> semantic labels for the two values, clarifies their nature and  
> specifies their relationship.  More specifically, it clarifies that  
> the identifier intended for reputation lookups (such as white lists)  
> by the assessor is the value of the "d=" tag. However, this does not  
> other information in the message header, for filtering decisions.

Section 6.3 of RFC 4871 indicates that verifier actions are beyond the  
scope of the specification.  Nevertheless, leaving Appendix D as  
written would have been preferred.

IMHO, the "errata" makes an inappropriate change to Appendix D's  
expression of intent.  Appendix D used the signing identity (the i=  
value) to select "on-behalf-of" addresses  for annotations by MUAs.   
When the i= value is not present, this defaults to "@<d= value>".    
The "errata" makes a significant protocol change by suggesting just  
the d= value is to be used.  Also, it would be wrong to suggest that  
reputations should be based upon the d= value, although such practice  
will advantage larger domains.  The i= value or its default will  
better mitigate intra-domain abuses and provide better coverage than  
will suggesting that reputation and annotations should be limited to  
just domains.  The "errata" should not have made this change while  
redefining terms.

>  For signers and assessors that have been using the i= tag for  

This change was unwise.  When a domain demonstrates poor stewardship  
by signing too many unique and problematic intra-domain sources (i=  
values) , it is not difficult for a service to then publish ratings  
that apply globally for the entire domain.  With respect to services  
offering information for intra-domain sources, a signing domain can  
always decide what they wish to offer, since the i= parameter is  
optional.  From an annotation perspective, perhaps only a portion of  
the i= value will correspond with signed headers, or perhaps there is  
no correspondence.  Nevertheless, the i= value (or its default)  
remains the preferred annotation (and reputation) reference that  
offers the greatest value to recipients.

As SMTP IP address acceptance becomes more constrained, a greater  
proportion of abuse will exploit hijacked accounts within large  
domains.  As such, it is important NOT to make this change to DKIM.   
It is far too soon to start drawing conclusions about DKIM reputation  
strategies.  Larger domains should temper their desire of seeking  
advantages and instead take the long view.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Jun 2009 18:04:30 -0400

> the last sentence, but I can live with it.

I'm pretty sure that the toe compression problem is inseparable from breathing 
and certainly is joined at the hip with posting any email at all.

What appeals to me about having that sentence, in that place, is that it

    --  anticipates possible -- and demonstrated -- confusion when
        reading the Update, especially by itself

    --  is non-normative

    --  disappears when folded into 4871bis.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Fri, 12 Jun 2009 16:06:51 -0700

Can you clarify what IESG concern this is attempting to address?  I
looked at the IESG evaluation record for the draft
(https://datatracker.ietf.org/idtracker/ballot/3084/) and didn't see
anything that this change would address, except possibly Cullen's
comment that he asked three developers what changes to a 4871
implementation might be required and they told him "this document was
completely incomprehensible and they have no idea what needs to change."

I don't see this modification as addressing that comment.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 12 Jun 2009 20:19:30 -0400

Jim Fenton wrote:
> Can you clarify what IESG concern this is attempting to address?  

Frankly, for that level of question, I suggest you direct it to our area 
director.  That will be far more efficient than my attempting to channel him and 
the rest of the IESG.

d/

-- 

   Dave Crocker

---

From: "J.D. Falk" <[email-masked]>
Date: Sat, 13 Jun 2009 14:57:27 +0200

> the last sentence, but I can live with it.

+1 (rounding up)

And, by the way, I'm speaking as operator of a popular reputation assessment 
service.

-- 
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: Jim Fenton <[email-masked]>
Date: Sat, 13 Jun 2009 15:00:29 -0700

Dave CROCKER wrote:

Jim Fenton wrote:

Can you clarify what IESG concern this is
attempting to address?

Frankly, for that level of question, I suggest you direct it to our
area director.  That will be far more efficient than my attempting to
channel him and the rest of the IESG.

OK.

Pasi:

Dave has proposed a change to the rfc4871-errata draft in response to a
concern from the IESG.  Can you clarify what concern the IESG has this
is attempting to address?  I'll repeat my original question below since
you may have missed it.

-Jim

Jim Fenton wrote:

-Jim

Dave CROCKER wrote:

Folks,

Thanks.

d/

Proposed text:

---

From: Jim Fenton <[email-masked]>
Date: Sat, 13 Jun 2009 15:51:27 -0700

(sorry...I clicked the HTML button on the last try and my own PDA was
having problems with it)

OK.

Pasi:

-Jim

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 15 Jun 2009 11:55:36 +0200

> is attempting to address?  I'll repeat my original question below since

It's attempting to address Cullen's comment (about this being
competely incomprehensible to both him and three DKIM implementors he
asked) *and* comments from several other ADs (voiced during the IESG
telechat) that were similar to Cullen's (it's very hard to tell what 
is being changed by this document, or who would be impacted by these 
changes and should read the document).

Currently, Section 1 does attempt to briefly summarize the change,
explain why it's done and describe the consequences, but after
re-reading it now, I think these comments have some merit, and 
slightly longer explanation would be very helpful to readers who 
didn't participate in the DKIM WG discussions. 

Best regards,
Pasi

---

From: Jim Fenton <[email-masked]>
Date: Mon, 15 Jun 2009 17:07:38 -0700

> didn't participate in the DKIM WG discussions. 

Thanks.  I don't share the sense that this additional text clarifies
things much, but I'm perhaps too close to the specification to be a fair
judge of that.

>          reputation assessment a software change to using the d= tag is intended.
and some of the text in the preceding paragraph because it attempts to
do exactly what the WG charter says we won't, specifically:

> To prevent this task from becoming unwieldy, several related topics are
> considered out of scope for the DKIM working group. These topics
> include:
>
> * Reputation and accreditation systems. While we expect these to add
>   value to what is defined by the DKIM working group, their development
>   will be separate, and is out of scope for the DKIM working group.

Finally, will you be taking this proposed text to the ADs who had
concerns to determine whether this addresses their concerns?  I'm
wondering whether they expected a change to be made, since none of them
raised a DISCUSS on this issue (Cullen abstained).

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 15 Jun 2009 22:22:55 -0400

> do exactly what the WG charter says we won't, specifically:

Ahh, right.  That's the sort of land-mine I was afraid might need uncovering. 
Thanks for catching this.

So...

Previous Proposed Text:

        <t>For signers and assessors that have been using the i= tag for
          reputation assessment a software change to using the d= tag is
          intended.
        </t>

New Proposed Text:

        <t>This currently leaves signers and assessors with the potential for
          making different interpretations between the two identifiers and may
          lead to interoperability problems. A signer could intend one to be
          used for reputation, and have a non-reputation intent in setting the
          value in the other. However the verifier might choose the wrong value
          to deliver to the assessor, thereby producing an unintended (and
          inaccurate) reputation assessment.</t>

        <t>This update resolves that confusion.  It defines additional, semantic
          labels for the two values, clarifies their nature and specifies their
          relationship.  More specifically, it clarifies that the identifier
          intended for delivery to the assessor -- such as one that consults a
          white list -- is the value of the "d=" tag. However, this does not
          prohibit message filtering engines from using the "i=" tag, or any
          other information in the message's header, for filtering decisions.
        </t>

        <t>For signers and verifiers that have been using the i= tag as the
           primary value that is delivered to the assessor, a software change to
           using the d= tag is intended.
        </t>

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 15 Jun 2009 21:34:14 -0700

Will somebody please tell the editor that this still violates our charter
since reputation is out of scope?

Thank you.

Mike

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Jun 2009 08:06:52 -0400

Bill,

The word "default" means that an alternative can be specified.  Within the 
formal specification that's not what is normatively provided for, per the 
errata/update clarification.  There is no mechanism for specifying an 
alternative source for the primary, delivered identifier.

Within the four walls of the formal DKIM specification (as modified by the 
errata/update), d= is the primary value delivered to the assessor.  i= is not 
specified as a possible alternative for this role.

A verifier can always choose to do anything (else) it wants to, but that it 
outside the four walls of the specification.  Within the spec, things are not 
flexibile on this point.

As for the "still used and assessed" text you suggest, it seems to be redundant 
with the draft's existing "However, this does not prohibit message filtering 
engines from using the "i=" tag, or any other information in the message's 
header, for filtering decisions" text.

d/

[email-masked] wrote:
> If the intent is to get everyone to use d= for an identifier to reduce confusion between d= and i= perhaps
>  "More specifically, it clarifies that the default identifier
>  is the value of the "d=" tag.
> Other tags such as the i= may still be used and assessed"

-- 

   Dave Crocker

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 16 Jun 2009 14:51:46 +0200

Specification of reputation systems would be in violation of the
charter, but e.g. the recently completed dkim-overview draft does 
talk about the "boundary" between DKIM and assessment systems.

Certainly the intent of this text (rephrasing the Introduction in
draft-ietf-dkim-rfc4871-errata) was *not* to broaden the scope of the
working group... so perhaps the 1st paragraph should talk about
"assessment" instead of "reputation"?

Dave Crocker wrote:
> New Proposed Text:
> 
>      <t>This currently leaves signers and assessors with the
>      potential for making different interpretations between the two
>      identifiers and may lead to interoperability problems. A signer
>      could intend one to be used for reputation, and have a
>      non-reputation intent in setting the value in the
>      other. However the verifier might choose the wrong value to
>      deliver to the assessor, thereby producing an unintended (and

Would "...one to be used for assessment, and have a non-assessment
intent in setting the value in the other. However, the verifier might
choose the wrong value to deliver to the assessor, thereby producing
an unintended (and inaccurate) assessment result." be more accurate?

Best regards,
Pasi

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Jun 2009 09:00:27 -0400

excellent.  that's certainly a simple enough way to resolve the concern.

d/

[email-masked] wrote:
> I don't have a specific objection to the word reputation per se but
> assessment is a more neutral term for this particular group so
> s/reputation/assessment/g should work.

-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 15:01:32 +0200

> raised a DISCUSS on this issue (Cullen abstained).

I am planning to ask Cullen if he finds the new text clearer than
the old one...

Best regards,
Pasi

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 16 Jun 2009 08:00:10 -0700

First thanks to the WG for trying to address the problem I had raised.  
I had assumed nothing would be done to try and correct so I just put  
abstain as clearly some people felt the document was worth publishing  
but as we are trying to fix or clarify this, let me be more explicit.

My focus is mostly on what this errata means to implementations in the  
field. That would be implementations of both DKIM the narrow signing  
protocol and implementations that use the information DKIM provides. I  
think the document should be clear on

1) what is the interoperability problem. Can someone succinctly  
summarize this? When I read the document, I get that there is a  
problem but it less clear what it is or why some implementation would  
end up doing something that did not work with other implementations.

2) what needs to be changed in implementations to fix this? Again, can  
anyone succinctly summarize this. I do not think an implementor that  
did not follow the list could easily read the current draft and figure  
out if there code was OK or not and what changes where needed to their  
code to make it OK

More inline ....

> potential for

I'm not really sure what you mean by a reputation intent and non- 
repuation intent or when a signer or verifier would want one or the  
other.

>          other information in the message's header, for filtering  

Look, this is clear as mud - What I am getting is that the old  
document was unclear if you should use the d= or the i= and this  
document clarifies it to be you should use, uh, I'm totally lost here,  
I use the d= for white lists, which are a form a filtering, but I can  
also use the i= for filtering.

I'm just unclear on what one is supposed to use and when. And honestly  
it does not matter if I am confused in the slightest, but it does  
matter if people implementing this stuff are unclear on this.  
Evidently there is enough confusing about this that it is worth  
writing an RFC to fix it - that I believe. However, people outside the  
WG other than me seem like they too have a hard time reading this and  
figuring out how this clarifies what to do. This does seem like a bit  
of a problem.

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 07:45:05 -0400

I could agree on this version

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Monday, June 15, 2009 10:23 PM
To: Jim Fenton
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

So...

Previous Proposed Text:

New Proposed Text:

--

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Jun 2009 11:49:56 -0400

>> s/reputation/assessment/g should work.

Meant to include this, for completeness:

Replacing 'reputation' with 'assessment', here's the latest version:

       <t>This currently leaves signers and assessors with the potential for
         making different interpretations between the two identifiers and may
         lead to interoperability problems. A signer could intend one to be
         used for assessment, and have a non-reputation intent in setting the
         value in the other. However the verifier might choose the wrong value
         to deliver to the assessor, thereby producing an unintended (and
         inaccurate) assessment.</t>

-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 07:51:55 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Tuesday, June 16, 2009 12:34 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

Thank you.

Mike

---

From: <[email-masked]>
Date: Tue, 16 Jun 2009 08:51:18 -0400

I don't have a specific objection to the word reputation per se but assessment is a more neutral term for this particular group so s/reputation/assessment/g should work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Tuesday, June 16, 2009 12:34 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

Thank you.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 16 Jun 2009 13:51:26 -0400

>         using the d= tag is intended.

+1

-- 
Jeff Macdonald
Ayer, MA

---

From: SM <[email-masked]>
Date: Tue, 16 Jun 2009 10:51:51 -0700

>think the document should be clear on

The proposed update does not affect the DKIM verification 
process.  It can affect the DKIM signing process and the 
post-verification process.  I'll use your message as an example.  The 
DKIM-Signature header for your message contains "d=cisco.com; 
i=[email-masked];"  According to RFC 4871, the domain is taken from 
the "i=" tag and in the absence of that tag, we fallback to the "d=" 
tag.  For this message, we would use "cisco.com" for the 
assessment.  I'm taking a narrow view of the assessment.

It was pointed out that some DKIM signers use a DKIM-Signature header 
such as "d=example.com; i=[email-masked];".  According to 
RFC 4871, we would use "core5.cisco.com" as the domain for the 
assessment.  With the proposed update, the "i=" tag and the fallback 
behavior is ignored.  We use "example.com" for the assessment.

Some DKIM signers may have to change the way they were signing 
messages if they are passing domain related information through the 
"i=" tag instead of the "d=" tag.  The DKIM post-verification process 
also has to be modified to pass the domain from the "d=" tag instead 
of the one from the "i=" tag.

>1) what is the interoperability problem. Can someone succinctly

See the above example.

>end up doing something that did not work with other implementations.

Some people got creative. :-)

>anyone succinctly summarize this. I do not think an implementor that

See the above example.

>out if there code was OK or not and what changes where needed to their

To keep it simple I'd say "use the d= tag only".

>repuation intent or when a signer or verifier would want one or the

reputation intent - help us blacklist, whitelist you, etc.

non-reputation intent - the DKIM signer placed some obfuscated 
information in the "i=" and it was probably not meant to be used for 
reputation.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Jun 2009 14:56:05 -0400

Jim Fenton wrote:
>  I do feel that we're effectively
> using "assessment" as a proxy for "the R-word" which goes back to the
> concern I voiced long ago about not requiring the verifier to pass on
> other values including i= if they're present.  It seems to me that this
> is effectively dictating the operation of the (wink wink, nudge nudge)
> assessor.    But I won't belabor that, since it seems that the rough
> consensus felt otherwise.

Thanks for not belaboring it.

I won't either:

1)  DKIM states the goal of delivering an identifier.  Not a mass of interesting 
attributes for the assessor to pick and choose among.  The clarification 
distinguishes between the (one) formally delivered identifier, versus whatever 
informal (outside of the spec) ad hoc, local usage the receive-side might wish 
to engage in.

2)  This is not telling the assessor what to do with the identifier, but making 
sure the assessor and the signer treat the same identifier as the primary one.

3)  The spec failed to distinguish between internal mechanism versus payload. 
This corrects that.

d/
-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Tue, 16 Jun 2009 11:42:19 -0700

> Replacing 'reputation' with 'assessment', here's the latest version:

I'm better with this version; thanks.  I do feel that we're effectively

The important point now is responding to Cullen's concerns that the new
text doesn't clarify things adequately.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Jun 2009 12:29:46 -0700

On Jun 16, 2009, at 10:51 AM, SM wrote:

>> My focus is mostly on what this errata means to implementations in  
>> the field. That would be implementations of both DKIM the narrow  
>> signing protocol and implementations that use the information DKIM  
>> provides. I think the document should be clear on
>
> The proposed update does not affect the DKIM verification process.   
> It can affect the DKIM signing process and the post-verification  
> process.  I'll use your message as an example.  The DKIM-Signature  
> header for your message contains "d=cisco.com;   
> i=[email-masked];"  According to RFC 4871, the domain is taken  
> from the "i=" tag and in the absence of that tag, we fallback to the  
> "d=" tag.  For this message, we would use "cisco.com" for the  
> It was pointed out that some DKIM signers use a DKIM-Signature  
> header such as "d=example.com; i=[email-masked];".   
> According to RFC 4871, we would use ["core5.example.com"] as the  
> domain for the assessment.  With the proposed update, the "i=" tag  
> and the fallback behavior is ignored.  We use "example.com" for the  
> assessment.

Correct, but this change would reduce DKIM protections!

The intent of the i= parameter is to permit finer grain header and  
intra-domain resolution.  This resolution ability is lost when always  
defaulting to the use of d=.  The use of the d= parameter does not  
differentiate between a mailing list of [email-masked] and  
that of a user of example.com,  such as:

  Sender: [email-masked]
  From: [email-masked]
  dkim-signature: i=[email-masked]; d=[email-masked];

Neither reputation OR annotations are better handled when limited to  
JUST the d= parameter.

The i= parameter, when not included, would be "@<d=value>".  This is  
the only time that d= should be used!

> "i=" tag instead of the "d=" tag.  The DKIM post-verification  
> process also has to be modified to pass the domain from the "d=" tag  
> instead of the one from the "i=" tag.

This does not work unless separate sub-domain and selectors are setup  
to contain separate keys.  This also means that users of example.com  
messages will have a valid signature when signed by a subdomain of  
example.com.  As such, this type of change will necessitate the use of  
sub-domains and multiple signatures, which the i= conventions would  
have avoided.

>> 1) what is the interoperability problem. Can someone succinctly

The above example creates problems.  It does not solve any.  The i=  
value remains optional, and does default to the d= value anyway!

>> problem but it less clear what it is or why some implementation  
>> would end up doing something that did not work with other  
>> implementations.
>

Some people are attempting to mitigate intra-domain spoofing.  A REAL  
problem!   DKIM is better than path registration, so don't emasculate  
this difference!

>> 2) what needs to be changed in implementations to fix this? Again,  
>> can anyone succinctly summarize this. I do not think an implementor  
>> that
>
> See the above example.
>
>> did not follow the list could easily read the current draft and  
>> figure out if there code was OK or not and what changes where  
>> needed to their code to make it OK
>

This will not allow domains that might have an intra-domain problem  
from establishing finer grain resolutions, or to clarify whether a  
message was sent on-behalf-of their list, or on-behalf-of some user  
within their domain.

> information in the "i=" and it was probably not meant to be used for  

Yes, the i= value CAN be used for intra-domain reputation.  This would  
occur only when the domain is otherwise good, but when there might be  
problems with some accounts having fun with replay abuse.

-Doug

---

From: hector <[email-masked]>
Date: Tue, 16 Jun 2009 15:39:38 -0400

Cullen,

This is why I still have some faith in the IETF process, common sense 
engineering generally prevails or highlights  the  problem  areas. Thanks.

My apology if the following inline comments goes beyond what you seek, 
but I believe it summarizes an Implementor's engineering viewpoint for 
the key reasons why a) 3-4 years of working on DKIM, have decided not to 
implement it yet, and b) why we have these confusing issues and how 
things evolved.  I sincerely hope you would take a moment of your time 
to read my comments.

 > end up doing something that did not work with other implementations.

DKIM's purpose has been lost with the continued  out of scope undefined 
reputation modeling. A concern raised over and over again, Assessment | 
Reputation - wink wink, same thing when it come to coding it.  Word 
smithing does not solve implementation issues.

When policy (SSP, not ADSP) was a major part of this project, there was 
a defined purpose on DKIM  handling.

In short, DKIM has a  major problem with  fault handling because the 
focus here is on filtering NON-ANONYMOUS white listing as opposed to 
filtering ANONYMOUS faults.  I called this the "Looking for the Golden 
Needle in the Haystack" problem when in steady state, receivers will be 
bombarded with a high volumes of unhandled faults only focusing on 
non-anonymous valid signatures.

For example, cisco.com exposes an exclusive policy signing policy, (only 
cisco.com signs its mail),  a DKIM verifier now has 0% false positive 
fault handling based on the author domain acceptable expectations.  If 
cisco.com doesn't publish a policy,  verifiers are lost when it comes to 
faults.  The only thing available is depending on some form on 
reputation assessment.  I had called this problem the "Battery Required" 
syndrome. Now receiver systems MUST have some sort of reputation lookup 
either local or by 3rd party service, the latter being the key conflict 
of interest focus by the key cogs of this group.

This is the principle reason as an potential implementor after 3-4 years 
participation in the WG, in house development, testing, simulations, we 
see no payoff under the current model and thus have little incentive to 
add DKIM into our product.  I have a problem exposing my customers to a 
protocol that requires "Batteries" in order to work.

 > out if there code was OK or not and what changes where needed to their

You hit the problem in your inline comments. The design issue is overall:

   d=   relates to 1st party signatures
    i=   relates to some  3rd party involvement.

I venture that when DKIM signing was added to the mipassoc.org list 
server and it began to blindly sign mail as a 3rd party,  the issue of 
whose policy do you lookup became obvious; the original domain  author 
(From:) or the signer d=?  Since i= reflects the From: address,  there 
was a potential policy design conflict.

This is when Dave began, what I felt was one of the oddest situations I 
have every seen in my engineering life, to introduce new acronyms and 
strange terminologies in what appears some vain attempt to change the 
"mindset" and meaning of what he was trying to model DKIM on, a non 
policy based framework using reputations, oops "assessors" to evaluation 
the handling of DKIM mail.

The thing is, this was resolved with the broader SSP draft.  But that 
was ambushed by what some believe was a poison pill with a trimmed down 
ADSP.  While its against my personal ethics to share private 
conversations, I think it is important to note that even Eric Allman 
thought ADSP was done to kill policy (using a non-consensus WG 
outcome).  ADSP does not resolve the problem for list servers and its  
only deeming value was its single policy - an exclusive signing 
DISCARDABLE policy.  ADSP does not address other real world high volume 
situations.

Overall, from an engineering standpoint, the focus was lost:

  DKIM did not adequately address the handling of 1 to 1
  communications because the intent to make it work with List Servers,
  a 1 to Many communications model.  This requires an ignorance of
  author domain policies.

The now expired I-D proposal I wrote back in July 2006:

   DKIM Signature Authorization Protocol (DSAP)
   http://tools.ietf.org/html/draft-santos-dkim-dsap-00
   
was done as a SSP derivative to cover the security concerns I had with 
DKIM not addressing the obvious fault handling based on simple common 
sense FAULT policies:

  - Mail with this domain was not expected (domain not used for email)
  - No signature is expected (I never sign)
  - No 3rd party signatures was expected
  - Only 1st party (Author Domain) Signature was expected

I even had a PPS presentation ready in anticipation of attending the 
IETF DKIM meetings:

   http://www.winserver.com/public/ssp/dsap-00.pdf

But the real incentive for writing DSAP was because of the "Writing on 
the Wall" WG atmosphere to eliminate SSP not on technical terms but 
because of rising conflict of interest by those who wanted a 
reputation-based DKIM business models. Not opposed to it, I'm a
business man myself, but I felt it was not good as a basis framework for 
the general network of potential DKIM implementors - signers,
verifiers or both. When I was told by the chairs not to worry 'SSP will 
happen one way or another,"  I agreed to support SSP and not
follow through with DSAP. This helped the chairs and WG with less 
competing policy drafts which I am 100% all for.  But if ADSP was
foreseen, I would not have never dropped DSAP. The irony?  Even the ADSP 
author doesn't believe in his own work and has proposed to move it first 
eliminate it and then move to experimental status.

Thanks

--
Hector Santos, CTO
Santronics Software,  Inc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Jun 2009 13:18:18 -0700

> smithing does not solve implementation issues.

I don't agree at all with these claims.  An assessor module can make a complete determination about what to do with a message using inputs from DKIM and several other systems of its choosing (e.g. SPF) without consulting any reputation system at all.  Reputation is just another input to the assessor.  The total set and weighting of the assessor's inputs is both a matter of software design and local policy.

They are certainly disjoint in my implementation.

---

From: hector <[email-masked]>
Date: Tue, 16 Jun 2009 17:26:42 -0400

Hi Murray,

I do not at all disagree with you.   Your black box functional model is 
one we have modeled as well.

However, IMO, in principle the framework must stand on its own for 
general implementation and not depended on other separate or augmented 
technologies to achieve some level of payoff.   You can not assume 
everyone will be using the same model, use SPF and anything else.  e.g. 
How will a remote system handle DKIM facsimile 3rd party spoofs of our 
domain?  What if it doesn't use SPF?

When POLICY was, for all intent and purpose became practically useless 
in its current ADSP form,  we lost 0% false positive fault handling of 
domain signing expectations.  White List Reputation became the principle 
intent by many. New strategic business models are depending on it.  I 
have no problem with this add-valued service. I think its great and will 
use it.   However,  I have a problem when its becomes a "Batteries 
Required" concept in order to get any general payoff from DKIM, 
especially when in the short term the reputation services will be very 
limited and there is no standard protocol for this.  Based on similar 
3rd party protocol implementations experiences in the past, this can 
create major support issues for customers and a major PR problem for us.

Look, it would of been nice if reputation was part of the charter so it 
would not have become such confusing contentious issue, and Dave didn't 
have to struggle with word smithing.  The focus would of been developing 
a reputation standard, models would of been developed and this project 
would of been finished long ago.

Thanks

--

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jun 2009 14:35:45 -0700

> They are certainly disjoint in my implementation.

There are a few points that seem to be lost in all of this:

1) People saying that d= is THE IDENTIFIER are overloading the value: d= a routing
    label to a particular DNS subtree. Whether it has anything to do with THE
    IDENTIFIER is purely coincidental. The assumption that these two functions are
    identical is bogus. i= was supposed to be this stable value detached from the
    mechanical DNS routing function.

2) assessors are going to use what they find useful regardless of whether we hurry
    this draft out any faster or with any less review.

3) What's "useful" to assessors, d=, i=, or even x= is out of scope for the DKIM wg.
    The level of interoperability being pursued here much higher level than
    anything we ever signed up for. We shouldn't force normative changes on implementations
    for functions outside of the scope of this working group.

4) #3 is doubly true since we don't even have any feedback, or an actual problem being
    reported in the field. when I asked about this at the SF meeting, I got a lot of
    bluster about "not revisiting first principles".

In conclusion, changing a spec absent actual problems in the field and to solve problems
that are outside of charter seems dubious and dangerous. Doing so as an emergency must-fix
update is even moreso: it tells the world that there's something dreadfully wrong with
DKIM when that's far from the case.

		Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Jun 2009 14:53:20 -0700

> figuring out how this clarifies what to do. This does seem like a bit

Think about it in terms of an API specification.

The intent here, I believe, is to specify that "d=" is mandatory output of a DKIM verifier module.  "i=" (and everything else, frankly) is optional.  Thus, a compliant verifier implementation will give you a yes/no on the signature and the name of the domain in "d=".  There may be other stuff there, but that's what you need for minimal compliance and interoperability.  A consumer of such a minimal specification could conceivably interchange DKIM implementations and still keep working as before.  However, there are no guarantees if such a consumer decides to try to make use of optional stuff like "i=" or "x=" or "l=" or whatever, because some other DKIM verifier implementation might not give that to you.  But if you code for yes/no and "d=" only, then any compliant verifier will give you what you need to interoperate.

If you as a consumer of such an API feel that you'd rather use "i=" for particular applications or types of messages, then either create or use an implementation that makes that value available.  There's nothing wrong with that either.

(If any of that language resolves the concern, feel free to use it.)

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Tue, 16 Jun 2009 15:13:39 -0700

>    mechanical DNS routing function.

Are you confusing the d= value and the DNS node (including selectors and
suchlike) that the public key lives at?

The d= value has been the persistent identifier for the signer since  
day one,
while the i= value is a more specific value that the signer can  
optionally use.

Given that the RHS of i= is either identical or a subdomain of d= it's  
nonsensical
to consider i= more stable than d=, as i= must change if d= does.

Cheers,
   Steve

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Jun 2009 19:04:02 -0400

> to consider i= more stable than d=, as i= must change if d= does.

In fact, other than the right-hand root of the i= string which must match the d= 
string, nothing in the i= value must exist anywhere except in the message 
containing it.  It's difficult to get much less stable than that.

BUT...

    This thread now seems to be re-discussing the working group decision that 
has already been approved both by the working group and the IESG.

    The goal, right now, is only supposed to be to agree on some non-normative 
clarification text for the Introduction.

    Since the exchange with Bill that replaced "reputation" with "assessment", I 
have not seen any suggestions for changes to the text proposed for addition to 
the draft.

    Have we converged on the text or does anyone have specific changes they are 
seeking?

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Jun 2009 16:11:38 -0700

On Jun 16, 2009, at 2:35 PM, Michael Thomas wrote:
> 1) People saying that d= is THE IDENTIFIER are overloading the  
> value: d= a routing label to a particular DNS subtree. Whether it  
> has anything to do with THE IDENTIFIER is purely coincidental. The  
> assumption that these two functions are identical is bogus. i= was  
> supposed to be this stable value detached from the mechanical DNS  
> routing function.
>
> 2) assessors are going to use what they find useful regardless of  
> whether we hurry this draft out any faster or with any less review.
>
> 3) What's "useful" to assessors, d=, i=, or even x= is out of scope  
> for the DKIM wg.  The level of interoperability being pursued here  
> much higher level than anything we ever signed up for. We shouldn't  
> force normative changes on implementations for functions outside of  
> the scope of this working group.
>
> 4) #3 is doubly true since we don't even have any feedback, or an  
> actual problem being reported in the field. when I asked about this  
> at the SF meeting, I got a lot of bluster about "not revisiting  
> first principles".
>
> In conclusion, changing a spec absent actual problems in the field  
> and to solve problems that are outside of charter seems dubious and  
> dangerous. Doing so as an emergency must-fix update is even moreso:  
> it tells the world that there's something dreadfully wrong with DKIM  
> when that's far from the case.

Agreed.

A while ago, I wrote a specification defining a device interface over  
a new physical layer that encompassed a well established command set.   
A large drive company wanted the specification "simplified" to meet  
their specific needs.  Changing the specification was accomplished  
largely through intimation.  Ironically, the 900 lb company then found  
their product was no longer supported by a 900 lb OS vendor as it had  
initially been, and neither were happy.  What had been removed was in  
fact being used.  Had anyone within management of the drive company  
understood the role played by the elements being removed, they would  
have discovered a transparent bridge within the OS, whereas the  
"simplified" specification (which they wanted as their OEM manual)  
required product specific fix-ups.

One might expect the motivation for changing DKIM is to establish  
parity with path registration.  In doing so, header specific  
annotation with its protection from intra-domain spoofing is reduced.   
Mitigation of replay abuse due to a small number of problematic  
accounts also becomes difficult when the i= value is depreciated as  
being just an optional second choice.  The i= value should be the  
first choice.  The d= value is only to be used when the i= is not  
present, as _defined_ by RFC 4871.

Assessments clearly are unable to cope with the unlimited intra-domain  
identifiers allowed by i= values.  However, most legitimate domains  
are fairly well managed where there is a small percentage of  
problematic accounts.  An assessment process will need to establish an  
upper bound for the number of such problematic identifiers per domain,  
and either base their response upon the problematic intra-domain  
identifiers, or that of the entire domain.   Using a one way hash for  
the i= value below the d= value allows a simple and deterministic  
query for either an intra-domain identifiers or a global domain  
responses.  I would be happy to create a draft to standardize this  
exchange.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jun 2009 16:13:33 -0700

Steve Atkins wrote:
>> value: d= a routing

No. d= is just the locater to that node.

> while the i= value is a more specific value that the signer can  

No, it's the other way around. i= *always* has a value, even if it's
not present; it's not "optional" in the way you're using the word.

> to consider i= more stable than d=, as i= must change if d= does.

I never said anything about "stability". I said that the two aren't
same. i= can be something like mojave.skunkworks.megacorp.com where
d= is just megacorp.com, because it's impossible at megacorp.com to
implement DNS subdomains. This isn't about stability, it's about having
identifiers that match the *mail identity* infrastructure that you'd
like to implement. That shouldn't be constrained by the accident of
routing to the selectors of whatever DNS infrastructure megacorp.com
is stuck with.

	Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Jun 2009 16:23:55 -0700

> containing it.  It's difficult to get much less stable than that.

   i= can be a subdomain of d=. In fact, it is arguably *more* stable as
   i= can remain the same while moving d= up in the hierarchy.

   So somebody please inform Dave that he should re-read 4871 section 3.5.

> has already been approved both by the working group and the IESG.

   This hasn't been approved by the IESG.

> have not seen any suggestions for changes to the text proposed for addition to 

   I suggest that any normative changes placed on the assessor module are outside
   of the scope of the DKIM working group.

   Since Dave has /From: [email-masked]/h:j, he still won't see any suggestions.

> Have we converged on the text or does anyone have specific changes they are 

   No.

		Mike

---

From: SM <[email-masked]>
Date: Tue, 16 Jun 2009 16:33:29 -0700

>     mechanical DNS routing function.

That was the intent.  In 2007, during an informal discussion between 
some of the participants of this WG, someone asked about "d=" and 
"i=".  The general view was to take the domain name from the "i=".

d= was more of a way to identify the DNS subtree which the public key 
can be retrieved.  There was also a long discussion on the mailing 
list which lead to "q=".  One or more participants argued for a query 
infrastructure that was not DNS-based.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 16 Jun 2009 19:26:23 -0400

On Tue, 16 Jun 2009 14:53:20 -0700 "Murray S. Kucherawy" 
<[email-masked]> wrote:
...
>The intent here, I believe, is to specify that "d=" is mandatory output of 
a DKIM verifier module.  "i=" (and everything else, frankly) is optional.  
...

OK, so now I guess I'm confused.  My understanding is that if "i=" isn't 
specified it takes the value of "d=", so I'm not clear how it can be 
undefined?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Jun 2009 17:26:02 -0700

> specified it takes the value of "d=", so I'm not clear how it can be undefined?

Maybe the wording of the errata draft could be improved (I'll propose new text shortly if I can), but here's my understanding:

I believe you're confusing the semantics of the DKIM signature with the definition of the DKIM interface.

Again, think of this in terms of an API definition.  Let's say you're building a DKIM library to sell or give away.  Obviously you need to know what outputs are required, i.e. what application developers will expect from you.

The errata draft is attempting to state clearly that the output of your library has to include the yes/no result of the verification and the "d=" value.  It can include other stuff at your discretion (you might even find that most assessors, the consumers of your library, want a lot more than that), but that's the minimum you have to provide to a consumer in order to be able to claim you are DKIM compliant.

It's not stating at all what the implicit value of "i=" is relative to "d=".  In this context, that fact is irrelevant.

Think of another example, like the socket interface to TCP vs. the TCP protocol itself.  There's what's going on in the protocol stack and then there's what's going on in the C libraries we actually use.  Could be that the language used in RFC4871 and the errata draft don't make that distinction clear, but I believe that's what we're trying to achieve here.

-MSK

---

From: hector <[email-masked]>
Date: Tue, 16 Jun 2009 23:24:46 -0400

> Again, think of this in terms of an API definition.  Let's say you're building a DKIM library to sell or give away.  Obviously you need to know what outputs are required, i.e. what application deve…
Are you trying to say?

     DKIM_RESULT = DKIM_VERIFY(ENVELOPE,  PAYLOAD)
     FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT,  DKIM_TAG_QUERY("D") )  
<<-- minimum requirement?

> The errata draft is attempting to state clearly that the output of your library has to include the yes/no result of the verification and the "d=" value.  
What does the verification process entail?

> Think of another example, like the socket interface to TCP vs. the TCP protocol itself.  There's what's going on in the protocol stack and then there's what's going on in the C libraries we actually use.  
How about higher layer wrappers and classes for sockets which have 
different models, sync vs async for example? <g>

> Could be that the language used in RFC4871 and the errata draft don't make that distinction clear, but I believe that's what we're trying to achieve here.
>   
I got that impression too when it was first put out.  But I think it was 
odd since implementators will do what is necessary to make whatever is 
necessary.   Any API interface and I/O will be defined by the ASSESSOR. 
It will define what is needed to do its work. The input is simple - RFC 
2822 payload.   If you are saying the basic model for an accessor is

     BOOL DKIM_ASSESSOR(BOOL DKIM_RESULT,  STRING D_TAG_VALUE)

thats cool. But why limit yourself?   The process environment data 
points are well defined:
   
     envelope fields
     payload fields
             
That prototype is based on  the presumption of a ADSP model perhaps or 
some other specific unspoken functionality.   What the errata should 
make clear is WHY and specific 2822 headers and possibly meta data 
(envelope) available for accessors at a minimum, may be required. So 
make sure its there for API to be developed.

Look at it this way:

In our SMTP framework, we provide two SMTP Rule Base Messaging 
processing hooks.  One for ENVELOPE processing before reaching DATA: and 
one for Payload Processing,  run after receiving DATA but before a 
response is issued.  So we have something  like this:

    //
    // Incoming mail, check the envelope
    // What SMTP_ENV_HOOK() does is out of scope
    //

    ERES = SMTP_ENV_HOOK(IP, HELO, MAILFROM, RCPTTO)

    CASE ERES
      TEMPORARY_FAILURE: REJECT, SEND 45x
      PERMANENT_FAILURE: REJECT, SEND 55x
      PASS: SEND 250
    END CASE

    //
    // DATA state reached,
    //

    PAYLOAD = RECEIVE_PAYLOAD()

    //
    // Process the payload before DATA response
    // Run 2822 payload filters, maybe a bunch of them
    //

    DRES = SMTP_DATA_HOOK(IP, HELO, MAILFROM, RCPTTO, PAYLOAD)

    CASE DRES
      TEMPORARY_FAILURE: REJECT, SEND 45x
      PERMANENT_FAILURE: REJECT, SEND 55x
      PASS: SEND 250, Message Accepted for delivery
    END CASE

    //
    // Wait for QUIT, RSET for complete transaction
    // End session
    //

So in our hook system,  2822 filters will be written and in general data 
points are available for any scripts written.

Now, this is a DYNAMIC SMTP processing model.   You also have a POST 
SMTP processing model:

    //
    // Incoming mail, check the envelope
    // What SMTP_ENV_HOOK() does is out of scope
    //

    ERES = SMTP_ENV_HOOK(IP, HELO, MAILFROM, RCPTTO)

    CASE ERES
      TEMPORARY_FAILURE: REJECT, SEND 45x
      PERMANENT_FAILURE: REJECT, SEND 55x
      PASS: SEND 250
    END CASE

    //
    // DATA state reached,
    //

    PAYLOAD = RECEIVE_PAYLOAD()

    SEND 250, Message Accepted for delivery

    //
    // - Wait for QUIT, RSET for complete transaction
    // - End session,
    // - Queue Payload plus Meta Data (envelope)
    // - Maybe signal a DKIM application server
    //

So if what you are saying that ACCESSORS need to work POST SMTP,  two 
data points at a minimum must be available:

      - There result of DKIM verification
      - The D= tag of the signature

again, thats cool.   But its very limiting and can reduce the possible 
ASSESSORS that can be designed in the future.  If Dave had a specific 
ASSESSOR in mind, it should be stated what that is.

--

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 07:43:43 -0400

Well it would be nice if i=author.net and d=3rd.party.signer.isp.com but no one agreed so I'll shut up now :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Tuesday, June 16, 2009 6:14 PM
To: DKIM WG
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

Cheers,
   Steve

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 07:40:22 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, June 16, 2009 5:53 PM
To: Cullen Jennings; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Modified Introduction text for rfc4871-errata (resend)

-MSK

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Wed, 17 Jun 2009 09:54:47 -0400

+1

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Murray S. Kucherawy
> Subject: Re: [ietf-dkim] Modified Introduction text forrfc4871-errata
> (resend)
> 
> > >          prohibit message filtering engines from using the "i="
tag,
> > > or any
> Thus, a compliant verifier implementation will give you a yes/no on
the
> signature and the name of the domain in "d=".  There may be other
stuff
> there, but that's what you need for minimal compliance and
> interoperability.  A consumer of such a minimal specification could
> conceivably interchange DKIM implementations and still keep working as
> before.  However, there are no guarantees if such a consumer decides
to
> try to make use of optional stuff like "i=" or "x=" or "l=" or
whatever,
> because some other DKIM verifier implementation might not give that to
> you.  But if you code for yes/no and "d=" only, then any compliant
> verifier will give you what you need to interoperate.
> 
> If you as a consumer of such an API feel that you'd rather use "i="
for
> particular applications or types of messages, then either create or
use an
> implementation that makes that value available.  There's nothing wrong
> with that either.
>

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Jun 2009 11:08:00 -0400

>> From: [email-masked] [mailto:ietf-dkim-

Hmmm.  Noting two quick +1s to Murray's text and in the interest of still trying 
to bring this "quick" errata/update effort to a close, I'm inclined to suggest 
adding his explanatory text to the existing proposed addition.

While it's entirely plausible that Murray can formulate a superior version of 
the basic text for the addition, I think that the existing +1s for the existing 
text and the +1s for Murray's commentary offers us something quicker.

So, here's a suggested merging of the two:

      <t>So, this Update clarifies the formal interface to DKIM, after
        signature verification has been performed. It distinguishes DKIM's
        internal signing and
        verification activity, from its standardized delivery of data to that
        interface.</t>

       <t>The focus of the Update is on the portion of DKIM that is much like
         an API definition.  If DKIM is implemented as a software library for
         use by others, it needs to define what outputs are provided, that is,
         what data that an application developer who uses the library can expect
         to obtain as a result of invoking DKIM on a message.</t>

       <t>This Update draft defines the output of that library to include the
         yes/no result of the verification and the "d=" value.  In other words,
         it says what (one) identifier was formally specified for use by the
         signer and whether the use of that identifier has been validated. For
         a particular library, other information can be provided at the
         discretion of the library developer, since developers of assessors --
         these are the consumers of the DKIM library -- well might want more
         information than the standardized two pieces of information. However
         that standardized set is the minimum that is required to be provided
         to a consuming module, in order to be able to claim that the library
         is DKIM compliant.</t>

       <t>This does not state what the implicit value of "i=" is, relative to
        "d=".  In this context, that fact is irrelevant.</t>

       <t>Another example is the difference between the socket interface to TCP
         versus the TCP protocol itself.  There is the activity within the
         protocol
         stack, and then there is the activity within in the software libraries
         that are actually used.</t>

Comments? (And yes, quick +1s are eagerly sought.)

d/
-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Wed, 17 Jun 2009 11:37:22 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Wednesday, June 17, 2009 11:08 AM
To: MH Michael Hammer (5304)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
Importance: High

d/
--

   Dave Crocker

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 17 Jun 2009 22:17:08 +0530

+1

>         using the d= tag is intended.

s/intended/required/ possibly?

Otherwise I'm good with this change.

---

From: hector <[email-masked]>
Date: Wed, 17 Jun 2009 13:08:42 -0400

API Definition? The socket example? Come on.

BTW, What is the definition of an Application Programming Interface 
and what portion of DKIM is like an API definition.

This is incomprehensible, overdone to get some simple concept across 
that only needs 1 or 2 paragraphs.  Dave, these paragraphs is really 
obscure. You can do better and get this API angle out.

If you going to this level, you need to be more specific with software 
engineering terminologies and how it applies to SMTP.  Murray's API is 
not going to be same as MY API or that guys API and it may not be just 
in C or C++, but in multiple of languages, and the API be COM 
interface, a .NET interface,  including a JAVA interface.  It may come 
in the form of shims, hooks, callouts, triggers, events or what have 
you.

If the functional model is attempted be described, a simple paragraph 
that ALL developers with SMTP knowledge will understand might be:

   DKIM Verification and Assessors Processing can be done during
   the SMTP session or post acceptance level.  In order to provide
   assessors the available data it might need, the DKIM
   verification result, the RFC 5321 envelope fields and RFC 5322
   payload SHOULD be made available for internal and external
   Assessor processing.

   At a minimum, the DKIM verification result and the DKIM-Signature
   signing domain identity (D=) value MUST be made available to
   assessors.

   How the information is provided to Assessors is implementation
   dependent and not in scope of this document.

Simple? Huh?

---

---

From: Douglas Otis <[email-masked]>
Date: Wed, 17 Jun 2009 10:13:25 -0700

On Jun 17, 2009, at 8:08 AM, Dave CROCKER wrote:

> inaccurate) assessment.

Can you provide examples of interoperability problems?

Any reputation assessment system should not:

1) limit what is to be assessed.

2) allow inclusion of un-assessed information used to provide  
annotation!

The change being recommended reduces intended protections.

> This update resolves that confusion.  It defines additional, semantic

This statement is wrong because:

1) Any white-listing practice based upon replayable signatures _will_  
be abused.

2) Use of the i= value is being defined as permission to discard email!

This is creating an operational problem by having email is accepted  
and then having it discarded.  This creates a disincentive for signers  
to offer additional intra-domain information.

> So, this Update clarifies the formal interface to DKIM, after
> internal signing and verification activity, from its standardized
> delivery of data to that interface.

What interface, the presentation layer?

> The focus of the Update is on the portion of DKIM that is much like
> to obtain as a result of invoking DKIM on a message.
>
> This Update draft defines the output of that library to include the
> yes/no result of the verification and the "d=" value.

It would be inherently unsafe to intentionally ignore information used  
for presentation.  As such, the i= value (or its default) SHOULD be  
assessed.  It can be and I'll be happy to describe an API that meets  
the requirement.
Such an API can avoid the inter-operational problems your change will  
create.

> This does not state what the implicit value of "i=" is, relative to
>  "d=".  In this context, that fact is irrelevant.

The i= value clarifies the entity on whose behalf the signature was  
added, and directs annotation process.  The d= value is irrelevant to  
an assessment of behavior history, especially when the d= value might  
combine the behaviors of millions. This change to DKIM is simply  
wrong, since the goal of DKIM is to defend against spoofing.  This  
change invites massive intra-domain spoofing.

> Another example is the difference between the socket interface to
> TCP versus the TCP protocol itself.  There is the activity within the
> protocol stack, and then there is the activity within in the software
> libraries that are actually used.

The TCP socket does not acknowledge TCP packets and then discard them  
before being presented, and yet this is the change being advocated. :^(

Measures that email must take to fend off massive abuse should not  
then result in email becoming even more unreliable.

Public MTAs (port 25) should explicitly declare an intent to issue  
email.  It may not be too late to resurrect your CVS effort.  Once  
public MTAs can be identified and consolidated, the overall size of  
public MTA assessments is likely around 8 million.  This would exclude  
servers that depend upon email for monitoring purposes.  These sources  
will likely require specific ACLs.

Anti-abuse schemes that attempt to redirect assessments to customers  
of public MTAs will not scale, especially when they involve dozens of  
transactions.  Each transaction or cryptographic operation will be  
abused a million fold.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 10:14:08 -0700

> <<-- minimum requirement?

I don't fully understand your notation, but I think what I'm saying is that a minimal DKIM implementation provides what's in parentheses on the second line.  It might provide more, but to claim to be compliant (after approval of the errata document) it has to provide at least that much.

> What does the verification process entail?

You've shown it in the first line above.

> > Think of another example, like the socket interface to TCP vs. the
> > TCP protocol itself.  There's what's going on in the protocol stack and
> > then there's what's going on in the C libraries we actually use.
> 

Also good examples: None of them offer you direct access to data in the TCP headers, for example.  They could, but they don't.  All you need as an application writer is the payload (if any) and a return status from an operation.  The internal bits are generally not your concern.  If you really want the internal stuff, you can switch to raw sockets or an API with more switches and knobs.

The libc function gethostbyname() is another example: you give it a hostname and it gives you back one or more IP addresses (or an error).  If you want more control over the query and the reply, switch to the res_*() functions.  If you want even more control over stuff like timeouts and the actual transport, use res_mkquery() and manage the sockets yourself.  The underlying protocol is the same in all cases.

(I could be wrong but for the sake of example, let's say:) POSIX specifies gethostbyname() will give you back what you want plus an error status in a global variable called h_errno.  Let's also say some implementation decides to do invisibly do DNSSEC, and for that implementation you get another global called h_dnssec that tells you whether or not the reply was secure.  Both the "standard" implementation and this one are POSIX-compliant, but this one has some extensions.  And maybe everyone desires that extension and installs this version of the resolver and uses it.  It may even become wildly popular, but the extension is "officially" not interoperable in terms of what the standard says.  The DKIM errata document, to me, simply declares a minimal interface that you MUST export in order to be able to say you are compliant.

> thats cool. But why limit yourself?

Nobody's saying you have to limit yourself.  On the contrary, what I believe the errata document is trying to do is specify clearly that you have to do at least X, but doesn't constrain you from doing more.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 10:24:56 -0700

> and what portion of DKIM is like an API definition.

I'm quite comfortable with drawing an implicit "you must be this tall" line and assuming someone reading this, i.e. an implementer (e.g. YOU), will know what an API is.

Or would you rather require even the definitions of words like "framework", "authentication", "email", "public key", "verification", "source", "messages" and "transfer", all of which appear in the first sentence of the abstract of RFC4871, be included?

Let's not be absurd here.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 10:31:20 -0700

>          used for assessment, and have a non-reputation intent in setting the

s/a non-reputation/some unspecified/

>         verification activity, from its standardized delivery of data to that

s/,//

>          that are actually used.</t>

s/used/made visible to consumers/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 10:33:35 -0700

> in the form of shims, hooks, callouts, triggers, events or what have

I don't think the proposed text defines any property of the API other than the fact that it must export two things: the verification result and the "d=" value.  The text does not stipulate what language has to be used, nor does it specify what that interface must look like.

So it already satisfies your requirement.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 10:42:08 -0700

> 1) limit what is to be assessed.

The proposed text does not put any limits on what gets assessed.  If an assessor wants more information, it is free to use a verifier that provides more information.

> 2) allow inclusion of un-assessed information used to provide

That's out of scope, since the annotation is not placed by the verifier, which is what we're discussing.

> 1) Any white-listing practice based upon replayable signatures _will_

That also seems to be out of scope to me, since it's not in the realm of the verifier.

> 2) Use of the i= value is being defined as permission to discard email!

That also seems to be out of scope to me, since it's not in the realm of the verifier.

> What interface, the presentation layer?

A DKIM API, which I suppose would live in the presentation layer.

> Such an API can avoid the inter-operational problems your change will

So you are seeking to make delivery of "i=" a third mandatory output for a compliant DKIM verifier?  I believe there is already consensus against the "mandatory" part of that.

> before being presented, and yet this is the change being advocated. :^(

That would be a protocol detail that's hidden from the user, and thus not relevant to an API specification such as the one we're discussing.

---

From: hector <[email-masked]>
Date: Wed, 17 Jun 2009 16:44:36 -0400

Murry,

How else can this be said?

Think SMTP and think how a SMTP system will provide the process 
environment variables to either embedded filtering system or external 
SMTP filtering system.

Most SMTP servers with an "ACL" or similar concept, including SendMail 
with its mfilters, our ours with WCX hooks, etc do not limit the 
external interface prototyping to just one or two variables.  The 
process variables are fixed:

    2821 (envelope)
    2822 (payload)

How these are provided to the "filters" differ from SMTP to SMTP 
system, by in general, both are available.

Here's the problem.

You have generalize ASSESSORS to have two minimum inputs:

   BOOLEAN (DKIM verification result)
   STRING (DKIM D= value)

1) Why?  Do you have a specific ASSESSOR in mind that is only
    privy to certain people?

2) How does a DKIM implementation generalize the fixed prototype
    to satisfy newer ASSESSOR that require different input? You
    are going to need some protocol that defines the input
    requirements for the specific and different assessor.

The more general function prototype is to provide the entire process 
environment variables, this is 1000% better for the general population 
of developers of accessor routines:

    ASSESSOR_RESULT is a function of SMTP data + DKIM result

this allows for example,a SMTP system to run a wildcard filter

    FOR EACH ASSESSOR in ASSESSORS.LIST
       RESULT = EXECUTE( ACCESSOR, ENVELOPE, PAYLOAD)
       IF NOT RESULT
          THROW EXCEPTION, RETURN FALSE or whatever
       END IF
    END FOR

That is general fit all never fail model. I'm pretty sure it applies 
to everyone, even you.

In short, it is the unspoken ASSESSOR API limited to two fields that 
needs to change to better fit a generalize global SMTP/DKIM model.

If don't your suggested way, then its becomes harder to program 
because it will look like this:

    FOR EACH ASSESSOR in ASSESSORS.LIST
       PARAMETERS = QUERY_ASSESSOR_REQUIRED_DATA(ACCESSOR)
       RESULT = EXECUTE( ACCESSOR, PARAMETERS)
       IF NOT RESULT
          THROW EXCEPTION, RETURN FALSE or whatever
       END IF
    END FOR

EXECUTE will now have to create the proper function prototype stack 
with the variable list parameters in order to satisfy specific 
ASSESSOR APIs with different functional prototypes.

Just providing feedback on years experience of developing an a high 
end SDK/API for C/C++, DELPHI, JAVA, PHP, VB, .NET languages and three 
basic API models; native, COM and .NET.

--
HLS

Murray S. Kucherawy wrote:

 > I'm quite comfortable with drawing an implicit "you must be this 
tall" line and assuming someone reading this, i.e. an implementer 
(e.g. YOU), will know what an API is.
 >
 > Or would you rather require even the definitions of words like 
"framework", "authentication", "email", "public key", "verification", 
"source", "messages" and "transfer", all of which appear in the first 
sentence of the abstract of RFC4871, be included?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Jun 2009 14:24:05 -0700

>    BOOLEAN (DKIM verification result)

Correct.

> 1) Why?

There is use in specifying an API here.  Every other protocol we've named so far as examples have an API, whether de facto from lots of experience, or implicit from the spec that defines it the protocol, or something actually explicit defining the API.  There's no evidence that this is a bad idea.

>  Do you have a specific ASSESSOR in mind that is only
>     privy to certain people?

Nope.  And let's stop with the insinuations that there's something secret going on here.

>     requirements for the specific and different assessor.

Yep, and nothing that's been said so far precludes this idea.  Defining a minimum does not also automatically define a maximum or establish other constraints.

So if you write an API in any of the dozen languages of expertise you claim, as long as it takes at least a message as input (and other stuff, if you wish) and returns at least the result and the "d=" value (and other stuff, if you wish), you're compliant.  You can provide *any* other hook into the API you want, but as long as you do that minimum, you're good to go.

What's an example of an API you might need which is broken by that simple requirement?  You may use any language or data structure you wish for this exam question.

>     ASSESSOR_RESULT is a function of SMTP data + DKIM result

Yep.  And the only part of this that we're discussing is "DKIM result"; the proposal is to define that as "at least the verification result and the value of 'd='".  The rest of this is outside of RFC4871's scope.

>           THROW EXCEPTION, RETURN FALSE or whatever

Yep.  And nothing I've said blocks such an implementation.

> That is general fit all never fail model. I'm pretty sure it applies

Yep.

> needs to change to better fit a generalize global SMTP/DKIM model.

This is a false conclusion.  The assessor is not constrained or even discussed in the proposed change.  If the assessor needs, let's say, the value of "i=", then it just needs to use a verifier that makes it available.  Such a verifier is compliant as long as it also makes the DKIM verification result and "d=" available.

>           THROW EXCEPTION, RETURN FALSE or whatever

I'm confused again by your notation, so I can't really respond to it, but this doesn't look a lot more complicated to me than your other pseudo-code above.

> ASSESSOR APIs with different functional prototypes.

No.  Each assessor will feed a message to the DKIM API and get back the result and "d=".  If it wants more, it just has to ask for whatever the "more" is from the API as well.  This might be additional parameters to the same function, or subsequent accessor functions.  In any case, I don't agree that this is complicated.

The assessor is free to pick any DKIM API that provides what it needs.  All the errata is saying is that all DKIM APIs must return, at a minimum, the "d=" and the evaluation result.  There are no other limits imposed.

> basic API models; native, COM and .NET.

You're not the only developer on this list with decades of professional experience in multiple environments, Hector.  Let's leave the resumes off the list, please.  We're here to co-operate, not compete.

---

From: hector <[email-masked]>
Date: Wed, 17 Jun 2009 19:10:16 -0400

Murray S. Kucherawy wrote:

 > All the errata is saying is that all DKIM APIs must return, at a
 > minimum, the "d=" and the evaluation result.  There are no other
 > limits imposed.

The concern I have is that an SMTP vendor may erroneous model his 
"Assessor" hook by recording two data points on the design presumption 
the assessor functional signature is:

     bool dkim_accessor(bool dkim_result, string d_tag_value);

When new assessors emerge, the potential is very high a different 
signature is required thus the new accessor will not be compatible 
with SMTP servers that do this.

For example, using our system, when we first produced our WCSAP 
product back in 2003 which evaluates the SMTP envelope using SPF and 
DNSRBL originally, the "API" prototype was fixed:

      BOOL Call_WCSAP(
              IP,   // client connecting ip address
              CDN,  // client domain name (HELO/EHLO)
              RP)   // Return Path, (MAIL FROM)

The Assessors here were locked for SPF and DNSRBL lookups and it 
return a TRUE and FALSE result.  TRUE continue with DATA, FALSE, a 550 
   reply code was issued.  The functionality was locked based on 
existing well known "standard" technologies at the time.  That is what 
I see here.

What happen is that over time, it evolved where we needed to pass more 
SMTP session and server information when a new assessor "scripting 
rules" were added:

     IP         // client connecting ip address
     CDN        // client domain name (HELO/EHLO)
     RP         // Return Path, (MAIL FROM)
     FP_LIST    // Forwarding Path (RCPT TO)
     SRV        // Server Host domain
     SRVIP      // Server Host IP
     AUTHID     // ID of AUTHenticated user

and the return status was no long TRUE or FALSE but a 64 bit double word:

     HIWORD - ACCEPT, REJECT, REJECT_BUT_KEEP
     LOWORD - REPLY_CODE

After this change, its been stable and there was no need to change in 
3-4 years.

So in my view, the SMTP system can potentially design the DKIM 
assessor two fields signature hook and lock himself in. Now only 
specific assessors are compatible with it.  Since we don't have any 
real experience of what assessors will need, I believe we can preempt 
the potential problem for SMTP servers and Assessor Developers by 
suggesting all information SHOULD be made available, and therefore 
Assessor Developers will have a persistent and consistent protocol to 
work with all DKIM compliant SMTP systems.

> You're not the only developer on this list with decades of professional 

 > experience in multiple environments, Hector.  Let's leave the
 > resumes off the list, please.  We're here to co-operate, not
 > compete.

Of course, there was no suggestion otherwise, but it shows there are 
multiple valid viewpoints and I believe in general the RFC should 
minimize implementation API discussions here, especially the socket 
paragraph (get rid of it).  I think it is not correct as stated and 
could cause problems. I just don't think its necessary. The fact you 
did state they can add more information, it should not be a subjective 
thing. We are talking about the Assessor Interface, it should be a 
fixed consistent interface that all Assessor developers can depend on.

Anyway, I think this thread has run its course. :-)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 17 Jun 2009 18:01:53 -0700

On Jun 17, 2009, at 2:24 PM, Murray S. Kucherawy wrote:

> There is use in specifying an API here.  Every other protocol we've  
> named so far as examples have an API, whether de facto from lots of  
> experience, or implicit from the spec that defines it the protocol,  
> or something actually explicit defining the API.  There's no  
> evidence that this is a bad idea.

This has already been defined by RFC 4871 as the i= value, and when  
that is not available, this defaults to @<d= value>.

The i= information is intended to provide guidance for annotating  
messages, whereas the d= value simply indicates where the key is  
published.  A modification to RFC 4871 that has the i= parameter  
routinely excluded from assessment then fails to offer the intended  
guidance AND fails to fully consider the source of the message.  The  
described use of your API even suggests that by offering i= value  
guidance, that the related message might become discarded.  There is  
ample evidence that discarding accepted email is deleterious, and in  
general, a bad idea.  The fact that users will not see discarded  
messages does not make this any better.   Some of the loudest  
complaints stem from missing messages.

>> 2) How does a DKIM implementation generalize the fixed prototype to  
>> satisfy newer ASSESSOR that require different input? You are going  
>> to need some protocol that defines the input requirements for the  
>> specific and different assessor.
>
> Yep, and nothing that's been said so far precludes this idea.   
> Defining a minimum does not also automatically define a maximum or  
> establish other constraints.

Yes it does curtail the alternative.  By limiting assessments to just  
the d= value, and then suggesting that the i= values can be used for  
subsequent discard, creates a significant impediment to even offering  
the intended information.

In addition, by not assessing the intended "on-behalf-of" identifier,  
the i= value may overlook deceptive sources that might have been  
replayed and impractical to recall.  A service that offers an  
assessment of the i= value will ensure the information used to  
annotate a message is not from known deceptive or abusive sources.  If  
the service wishes to ignore a portion of the the i= value, it can.   
But ignoring a portion of the i= value has a potential for creating  
inter-operability issues.  The imaginary inter-operability issue  
becomes real with this change. :^(

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 17 Jun 2009 17:44:40 -0400

> s/intended/required/ possibly?

while you are right, practically speaking, that sounds normative, and this text 
needs to avoid any hint of trying to be normative.

-- 

   Dave Crocker

---

From: hector <[email-masked]>
Date: Thu, 18 Jun 2009 14:18:34 -0400

> that is not available, this defaults to @<d= value>.

This is why I as seeking an answer to why just d= and not anything 
else.  What it for a reputation system?

What if the new Assessor was for POLICY? which will need three inputs:

     boolean Dkim Verification result
     string 5322 Dkim-Signature: d= value
     string 5322 From: domain value

Why isn't this DKIM-BASE errata preparing its sister chartered 
protocol ADSP (policy) in preparation for this three input field assessor?

--

---

From: Douglas Otis <[email-masked]>
Date: Thu, 18 Jun 2009 12:18:10 -0700

On Jun 18, 2009, at 11:18 AM, hector wrote:

> Douglas Otis wrote:
>
>>>> 1) Why?
>>> There is use in specifying an API here.  Every other protocol  
>>> we've  named so far as examples have an API, whether de facto from  
>>> lots of  experience, or implicit from the spec that defines it the  
>>> protocol,  or something actually explicit defining the API.   
>>> There's no  evidence that this is a bad idea.
>>
>> This has already been defined by RFC 4871 as the i= value, and  
>> when  that is not available, this defaults to @<d= value>.
>

The response from a closed group of large email providers regarding  
how they would like to have their reputation handled was to have their  
entire domain's messages receive the _same_ reputation.  This is not  
surprising.  Treating all of their messages en mass makes it  
impractical to isolate abusive accounts or to retain delivery  
integrity.  :^(

This is also why they wish to ignore DKIM's potential for replay  
abuse.  DKIM suffers the problems found with any cryptographic  
solution that can be replayed.  Once all of the domain's signatures  
are white-listed as suggested, this will invite massive levels of abuse.

-Doug

---

From: hector <[email-masked]>
Date: Thu, 18 Jun 2009 19:34:45 -0400

---

From: hector <[email-masked]>
Date: Thu, 18 Jun 2009 20:43:01 -0400

Douglas Otis wrote:

> surprising.  

Right. Glad to hear it is consortium or group and not just one. It 
will help centralize it. Buts it still is a "Batteries Required" 
problem for the general across the board adoption of DKIM.  If its an 
open service system (free "basic service" signup model if offered, 
free client lookups), then the problem is lessen.

> Treating all of their messages en mass makes it  

This is why I was so adamant about having a policy system that wide 
adoption of DKIM receivers can use as a default defense.  Not everyone 
has to be signers. The migration path might be that most will become 
DKIM verifiers first, then their domain signing strategy is worked out.

> abuse.  

Looking for the golden (DKIM) needles in the (abuse) haystack. :)

> DKIM suffers the problems found with any cryptographic  

I am not so concern about replays as is my overall two concerns:

1) Obvious DKIM faults, spoofs direct or indirect (bad guy has your 
domain in his list and is DKIM ignorant) are not protected when they 
are so easy to detect using basic DKIM signing policies.

2) The levels of faults (abuse) will overwhelm the fewer good finds, 
enough such that low to mid size receivers will turn off the 
processing. When the payoff::efficiency ratio begins to be so low, 
DKIM begins to become ignored.

Bad guys can use this form of DKIM DoS strategy as did the Sorbig Dual 
Blitz attack which help jump start the IETF email security efforts. It 
was the final straw for many.  SorBig first blasted systems with IP 
faults to forced system to shutdown popular RBL sites, then it blasted 
people with intentional accept/bounce attacks.

Whats odd, is the bad guys are probably laughing it up is the best 
thing to circumstance DKIM is to now try to use it - ignore it, keep 
with Legacy operations. Don't raise any flags.  But if they wanted to 
spoof DKIM domains, all they need to is blast enough systems to seek 
out DKIM receivers who don't subscribe to the Centralized Consortium 
Reputation Service.

What irks me the most is the lost time and opportunity to have a major 
impact on the spoof and domain abuse problem across the board, for all 
sizes of people. Not just my large customers but all my customers. 
What the large companies need to realize that the little systems can 
really help them too.  So it is to their benefits that all systems, 
from small to large on the public Port 25 SMTP network can use policy 
or a reputation system.

We could of have both Reputation and Policy as powerful assessors to 
DKIM-BASE completely by now. But it was the reputation people who 
didn't want Policy.  The policy people has always said that reputation 
is also important part of the picture. I even felt Reputation should 
have been part of the charter so that people can be open about it, and 
work out all the issues. They didn't have to worry about blatant 
charter ignorance and didn't have to play games with word smithing.

Just consider in the Draft DKIM Overview up to revision 05:

     http://tools.ietf.org/html/draft-ietf-dkim-overview-05.txt

it directly said:

    2.3.  Filtering

    ...

    Unless a scheme can correlate the DKIM signature with accreditation
    or reputation data, the presence of a DKIM signature SHOULD be
    ignored.

I know I posted concerns about that. Don't recall if others publicly 
posting concerns, but this has been remove since revision 06 with a 
complete rewrite of the DKIM overview draft.

Quite frankly, at this point, it should really be added back in. It 
will give domains a better idea, as the above statement implies, that 
DKIM-BASE is worthless without without being part of some reputation 
scheme  We should not denied them this guidance.

    Unless a scheme can correlate the DKIM signature with
    accreditation or reputation data, or ADSP policy or some
    other assessor scheme, the presence of a DKIM signature SHOULD
    be ignored.

Honestly, I really think this is GOOD (and ethical) advice now.

--

---

From: hector <[email-masked]>
Date: Fri, 19 Jun 2009 03:35:48 -0400

Murray,

I just wanted to touch base on something I missed in your last post. A 
statement you made that now totally contradicts mthe model I thought 
you were talking about.  Maybe this discussion can help mold a better 
understanding for DKIM integrators.

 > No.  Each assessor will feed a message to the DKIM API and get
 > back the result and "d=".

I thought I understood your model. I am not so sure now with the above 
statement which made be read more carefully what the ERRATA is saying 
and I simply can not comprehend it.

This somewhat conflicts with the layered DKIM model I had in mind 
which was DKIM WG chartered direction of splitting DKIM into a base 
spec to be integrated with higher layer policy, reputation and other 
"assessment" technology as there invented, materialized and applies 
to DKIM-BASE.

I thought "Assessors" were things like policy and reputations 
protocols and others yet to be invented, that assess the verification 
result of DKIM signature.

The thought the only required feed for DKIM-BASE was the 5322 payload:

   5322 -> DKIM-BASE -> status, d= -> DKIM-ASSESSOR -> PASS/FAIL

and the ERRATA discussions was about what DKIM verification result and 
additional data is needed for the next Assessor layer which ultimately 
provided final pass/fail (accept/reject) result.

Your statement seems to describe something different.

Does the Assessors do verification, policy, reputation and anything 
else with a final result of status and the d= tag?

If so, I was completely off base on what I thought this ERRATA was 
above. I can see better why you described your API as so, but IMV this 
is a prime example why should keep the API metaphor out of the errata 
and get this better cleared up.  It appears your idea of an API 
perfectly shows where there would be conflicts with a more straight 
forward understanding of DKIM layered framework.

    SMTP feeds DKIM-BASE, the result and additional data feeds a
    higher layer, which I thought were "assessors" but apparently
    not.

Assessor is really not the best term for this because it seems to 
applies it does everything, including the verification process and I 
guess it does, right?

Sorry I didn't understand your API, but it is very odd. This ERRATA is 
really complex and incomprehensible and in my opinion, it does seem to 
somewhere alter implementations API libraries I explored, like the 
ALT-N DKIM API library.  This API used the basic idea of a three layer 
approach:

    SMTP FEED (5322 Message)
      --> DKIM-BASE verification
           --> Optional DKIM-POLICY Evaluation Hook (one only)

I thought we were talking a simple change to better support future 
verification result analyzers, evaluators, policy, reputation, etc:

    SMTP FEED (5322 Message)
      --> DKIM-BASE verification
           --> Optional DKIM-ASSESSOR Hooks (multiple possible)

Whatever.

--