Subject: [ietf-dkim] errata revision: Assessor

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

Folks,

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

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

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

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.

OK.  Start shooting.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 25 Mar 2009 22:23:15 +0100

Dave,

Thanks for this.  One suggested change:

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

Eliot

---

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

>> 8.  RFC4871 Section 2.11 Identity Assessor
...
> My logic: what the assessor consumes beyond the SDID is outside the 

Is your concern that the presence of the DKIM qualifier could be taken to 
/exclude/ other values?

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.

d/
-- 

   Dave Crocker

---

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

> My logic: what the assessor consumes beyond the SDID is outside the

And add "by" between "delivered" and "this".

After that, +1.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 25 Mar 2009 17:51:24 -0600

> And add "by" between "delivered" and "this".

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Wed, 25 Mar 2009 20:00:02 -0400 (EDT)

+1

	Wietse

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 25 Mar 2009 20:19:38 -0400

+1

Ellen

---

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

<participant>I like this text.</participant>

Barry

---

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

I am +1 for this.   Let's leave stuff beyond the SDID 'opaque'

>> My logic: what the assessor consumes beyond the SDID is outside the

--srs

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2009 06:53:05 +0100

On 3/25/09 10:28 PM, Dave CROCKER wrote:
> Is your concern that the presence of the DKIM qualifier could be taken 
> to /exclude/ other values?

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

Eliot

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 07:37:50 -0400

+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

---

From: John Levine <[email-masked]>
Date: 26 Mar 2009 11:39:11 -0000

>address.  They might want that tidbid of information as well.  How, 

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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 08:10:33 -0400

> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2009 14:16:04 +0100

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

> to interoperate with DKIM.

Right.  And so I am comfortable with the changes Dave proposed.
> 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

---

From: "John R. Levine" <[email-masked]>
Date: Thu, 26 Mar 2009 13:45:24 +0000 (GMT)

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

> 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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 10:30:49 -0400

> These diagrams aren't perfect, but I think the illustrate one approach 

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Mar 2009 15:42:04 +0100

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

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 26 Mar 2009 07:59:56 -0700

> 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

    <http://dkim.org/ietf-dkim.htm#deployment>

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Mar 2009 10:40:39 -0700 (PDT)

> 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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 14:10:13 -0400

Murray S. Kucherawy wrote:
> 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:

  > 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Mar 2009 11:26:46 -0700 (PDT)

> disable what they want and not what you or I want.

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

> 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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 14:41:49 -0400

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

Of course.

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Mar 2009 18:45:35 +0000

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

---

From: [email-masked] (Wietse Venema)
Date: Thu, 26 Mar 2009 15:19:09 -0400 (EDT)

> 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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 26 Mar 2009 15:22:41 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Wietse Venema
> Sent: Thursday, March 26, 2009 3:19 PM
> To: [email-masked]
> Subject: Re: [ietf-dkim] what is a standard, was errata revision:
Assessor
> pleased

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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 15:38:04 -0400

> 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

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Mar 2009 15:42:09 -0400

> The logic being that it doesn't affect what we do or don't say in

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

---

From: Paul Russell <[email-masked]>
Date: Thu, 26 Mar 2009 12:18:41 -0700

...

> Anyway, the point is MOST SMTP vendors are in the business of provide 

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

---

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

Siegel, Ellen wrote:
>>>>>>          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
>>     

Me too.

-Jim

---

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

+1

-- 
Jeff Macdonald
[email-masked]

---

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

>> address.  They might want that tidbid of information as well.  How,
  [ . . . ]
> about DKIM, don't think about IP addresses.

Speaking as an assessor (does anyone else here do that?), and as someone who 
has put a lot of thought into assessing the reputation of authenticated 
domains...I couldn't agree more.  That way madness lies.

Yet even so, assessors are going to use whatever data we think is relevant, 
no matter what the RFCs say.  The bad guys don't care about standards, so 
when we're assessing badness we MUST look for non-compliant behavior -- and 
most assessors exempt behavior which may be non-compliant, but still 
extremely common.  When assessing goodness we still look for non-compliant 
behavior, for basically the same reasons -- and often warn those good guys 
that they've screwed up somewhere.

Concern about assessors thinking we can't use data just because the DKIM 
spec doesn't explicitly say we can, or vice versa, is a non-issue.