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

[J.D. Falk]

John Levine wrote:

>> 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?
  [ . . . ]
> 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.

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.

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

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

[Paul Russell]

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

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

...

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

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

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

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

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

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

[Hector Santos]

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

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

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[Hector Santos]

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

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

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

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[MH Michael Hammer (5304)]

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


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

Mike

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

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

[Wietse Venema]

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

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

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

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

[Stephen Farrell]

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

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

Stephen.

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

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

[Hector Santos]

Murray S. Kucherawy wrote:

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

Of course.

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

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

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

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

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

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

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

> But please stop speaking for all SMTP vendors, 

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

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

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

> Perhaps some other vendors would like to weigh in.

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

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

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

Are you not in that business?


-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[Murray S. Kucherawy]

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

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

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

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

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

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

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

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

[Hector Santos]

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

Just to make sure of the specifics my comments addressed:

  > Levine stated:

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

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

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

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

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

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[Murray S. Kucherawy]

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

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

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

[Dave CROCKER]

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


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

DomainKeys Identified Mail (DKIM) Development, Deployment and Operations



d/
-- 

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

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

[Eliot Lear]

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


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

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

[Hector Santos]

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

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

Model 1:

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

Model 2:

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

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

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

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

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

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

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

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

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

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

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[John R. Levine]

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

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

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

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

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

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

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

[Eliot Lear]

John,

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

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

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



Or, put in other terms:

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

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


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

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

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

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

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

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

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

[Hector Santos]

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

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

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

-- 
Sincerely

Hector Santos
http://www.santronics.com


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

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

[John Levine]

>> The reason for saying DKIM, here, was to make sure the reader knows 
>> it's ok for other DKIM-Sig values to be delivered.  Without the DKIM 
>> reference, the sentence would seem to be so broad as to have truly 
>> nothing to do with DKIM.
>
>My concern is this: what do identity assessors use today?  An IP 
>address.  They might want that tidbid of information as well.  How, 
>then, not to exclude it?

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

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

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

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