Subject: Re: [ietf-dkim] user level ssp

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Sep 2006 11:26 -0400

On Thu, 7 Sep 2006 13:31:56 -0700 Steve Atkins <[email-masked]> wrote:

>The impression I'm getting, from several people, is that "I always  
>sign" is already
>being written off as likely to be ignored by recipients and that  
>there needs to be
>a "No, I really mean it!" modifier?

Or, to put it slightly differently...

It's all signed when it leaves my MTA(s), but:

1.  I know stuff will get broken along the way or come from other MTAs, so 
please be gentle.

2.  I don't care about the breakage and I'd prefer you reject unsigned mail.

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 08 Sep 2006 09:05:36 -0700

On Fri, 2006-09-08 at 11:26 -0400, Scott Kitterman wrote:
> > sign" is already being written off as likely to be ignored by
> > recipients and that there needs to be a "No, I really mean it!"
> > modifier?
> 
> 1.  I know stuff will get broken along the way or come from other
>     MTAs, so please be gentle.
> 

Agreed. "This domain uses non-complaint services." 

This policy could be surgically applied when it is possible to have
separate policies for specific email-addresses (those used for
transactional messages).  This would allow for different annotations AND
different treatments based upon a few critical email-address.

-Doug

---

From: John Levine <[email-masked]>
Date: 8 Sep 2006 16:48:41 -0000

>2.  I don't care about the breakage and I'd prefer you reject unsigned mail.

Not to put too fine a point on it, but the fundamental question here
is why should the recipient care what the sender claims he prefers?

Anytime you send e-mail to someone, you're basically asking them to do
you a large favor by investing the effort to accept and deliver it.
Senders don't get to set rules about what recipients can do.

It's fine if senders can offer advice to recipients that the
recipients find useful to do what they want to do, which is presumably
to deliver mail that their own users want, but "because I said so"
doesn't make advice useful.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 08 Sep 2006 09:55:58 -0700

> Senders don't get to set rules about what recipients can do.

or will do or should do.

bang on, John!

discussion on the list continues to use a perspective that sounds like 
the sender gets to dictate things, rather than that the receiver has the 
option of using information.

at every turn we should start by asking how a feature will benefit the 
receive-side and what our basis is for believing that they will *see* 
that benefit (and hence be motivated to use it)?

d/

-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Sep 2006 10:09:42 -0700

On Sep 8, 2006, at 9:48 AM, John Levine wrote:

> Not to put too fine a point on it, but the fundamental question  
> here is why should the recipient care what the sender claims he  
> prefers?
>
> Anytime you send e-mail to someone, you're basically asking them to  
> do you a large favor by investing the effort to accept and deliver  
> it. Senders don't get to set rules about what recipients can do.
>
> recipients find useful to do what they want to do, which is  
> presumably to deliver mail that their own users want, but "because  
> I said so" doesn't make advice useful.

You are right.  Scott's statement was poorly worded as a request to  
the verifier.  It should have been a simple statement about the  
domain's intended practices.  "This email-address represents messages  
of a transactional nature" and "All other email-addresses may employ  
non-compliant services that might damage their signature."  When you  
have decided to accept this domain's messages, the policy statement  
might help reduce support calls due to valid undelivered messages as  
well as preventing potential spoofing by enabling stronger  
annotations in these exceptional cases.  It should not take long for  
recipient to expect to see these annotations on messages of this nature.

-Doug

---

From: Damon <[email-masked]>
Date: Fri, 8 Sep 2006 13:20:46 -0400

> that benefit (and hence be motivated to use it)?

Innovator: Hey I got a great idea, how about we slice the bread first
before we sell it.

A: (from this group) How do we know the customer will benefit from it?
What about people that like thick bread? You know.. we will have to
change all the toasters to accept our new slice width. How do we know
how thick to slice it?

I don't think there is an argument for what the receiver should do
with the message. The sender is offering a suggested course of action
(take 2 call me in the morning) I hope that we are not going to go
down the road of "What will the receiver do with it?" and have a
zillion threads on this. Waste of breath or digit strength.
I think that it would be OK to say that the sender is going to suggest
of course of action for the receiver. It is not a dictation, much like
the suggested dosage of exlax- Ignore at your own peril.

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 8 Sep 2006 14:11:40 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
Sent: Friday, September 08, 2006 12:48 PM
Subject: Re: [ietf-dkim] The basic problem with SSP

> Senders don't get to set rules about what recipients can do.

If thats the case, than explain why should receivers should bother
processing DKIM signature mail?

Whats the purpose?

Why should it handle GOOD signatures differently than BAD signatures? and
vice versa?  Where is the payoff?

Are we just looking for the "GOOD needle in the Haystack?"  What about the
rest of the non-complain DKIM junk?

Why should EVERYONE be required do required non-standard reputations
batteries to work with DKIM-BASE?  Whose batteries should we use?  Yours?
Some other?

As it is now, 99.99% of the systems out there ignore DOMAINKEYS messages.
What is it about DKIM that will change this and make a wide adoption begin
to process DKIM?  Again, where and what is the payoff?

If it isn't about SPAM, then what it is for?

By world wide industry measurements, 80% of the transactions are
non-compliant.

Is DKIM going to reduce this, increase this?

And even if BIGBANK.COM or ANYBRAND.COM finds that DKIM+DAC works for its
exclusive social network,  how will BIGBANK.COM protect itself against
domains that don't subscribe to DKIM+DAC?

You are 100%.  You can't dictate how receivers are going to behave but you
talking a big game about how systems should work with MUCH LESS using only
just DKIM-BASE plus some other non-standard idea what as invented by TWO
people, not put thru any IETF process.

I have absolutely NO reason whatsoever to support DKIM-BASE to PROCESS the
GOOD.  But I have good reason to process the non-COMPLIANT and that includes
DKIM-BASE if I see that it will be become exploited which based on our
product history in the mail market for a WIDE range of customers from SMB to
LARGE, I see DKIM-BASE only with open-ended 3rd party APPLIANCE signings
opening a lot of  can of worms.

SSP to me is about Failure and Non-Compliance of the DKIM-BASE signature
process - an AUTHORIZATION concept.  Mail that passes the test is still
untrusted and can be further processed using traditional AVS tools.

But if you can eliminate a population of new world order of NON-LEGACY
transactions based on non-compliance, than that is what I will be
implementing into our software.

SSP is about mail filtering by DKIM Policy Osmosis.

---
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
Wildcat! Interactive Net Server

---

From: Steve Atkins <[email-masked]>
Date: Fri, 8 Sep 2006 11:21:17 -0700

> processing DKIM signature mail?

The purpose is that the recipient knows who is responsible
for the mail.

If the signature is good, then the recipient can A) send feedback
to the right place and B) use the senders reputation to make decisions
about delivery

If the mail is unsigned then we're at status-quo.

That's it.

SSP is a different matter. The cynic in me says that the sole purpose
of SSP is to affect the deployment of DKIM.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Sep 2006 11:32:31 -0700

On Sep 8, 2006, at 11:11 AM, Hector Santos wrote:
>>
>> Anytime you send e-mail to someone, you're basically asking them  
>> to do you a large favor by investing the effort to accept and  
>> deliver it. Senders don't get to set rules about what recipients  
>> can do.
>

  - DKIM related MUA annotations protect recipients from spoofing.

  - DKIM identified bulk-senders might bypass message filtering.

  - DKIM indicates where abuse can be reported.

  - DKIM policy should allow MUA annotations to apply to a larger  
percentage of messages.

  - DKIM policy should allow selective handling of critical  
(transactional) messages.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 8 Sep 2006 14:50:55 -0400

> option of using information.

OK, then quit griping and make a suggestion.  Trust me, I completely 
understand that the sender doesn't dictate.  If it seems like I don't 
understand that, then that means I didn't get the words right.  I'm open to 
suggestions on how to word things better.

Viewed alternatively, that might mean that it doesn't matter how proscriptive 
the language pretends to be.  In the end, receiver policy will dictate, so 
why waste all the calories over wordsmithing that pretty well amounts to 
arguing over how many angels can dance on the head of a pin.

> that benefit (and hence be motivated to use it)?
OK.  If my bank published such a strong policy, as a receiver, I'd use it.

Scott K

---

From: [email-masked] (Wietse Venema)
Date: Fri, 8 Sep 2006 14:52:28 -0400 (EDT)

> processing DKIM signature mail?

The purpose of a valid DKIM signature is to identify the party that
signed the message. Whether this is a first-party or third-party
signature is largely irrelevant. It's about accountability.

> untrusted and can be further processed using traditional AVS tools.

It is a mistake to believe that you have any control over what
recipients do with their email. It is the persistence in this
mistaken belief that distracts from the potential that DKIM has.

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 8 Sep 2006 15:34:33 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>

> The purpose is that the recipient knows who is responsible

And you honestly believe there is no product liabilities here?  I really
don't care who is responsible as long as its not me for incorrectly passing
on potentially harmful mail to users.  That is not my business.  However,
what I am interested in is eliminating the non-compliant transactions!!

> If the signature is good, then the recipient can A) send
> feedback to the right place and B) use the senders reputation
> to make decisions about delivery

But where was the acceptance criteria in the first place?  That it passed
the DKIM test?

> If the mail is unsigned then we're at status-quo.

I disagree (and so does SSP, DSAP, etc). Absolutely not.  It is no longer a
Legacy Mail operation once DKIM is a presumed default behavior.  I see
product liabilities issues such as neglect and malpractice if an user was
harm because a protected domain was passed as a unsigned MAIL by a
DKIM-READY receiver to her end-users.

Sorry. I am not really to take on that product liability.

> That's it.

If it was really that simple.

> SSP is a different matter. The cynic in me says that the
> sole purpose of SSP is to affect the deployment of DKIM.

That's funny because one would naturally think it is the other way around.
SSP would of been done along time ago if it was wasn't original proof of
concept by a group promoting a concept that is written in stone to be out of
scope.

This is our product installation and usage opinion:

As I mentioned to you last year, you would be better off not even supporting
DKIM because you risk harm to your mail broadcasting business (domains) when
receivers begin to see the increase abuse but this time, an abuse with odd
and strange "DKIM" fingerprints.

By supporting DKIM, you are in a new non-legacy mail transaction
considerations. You have evolved to a new level of expectation where
NON-COMPLIANCY and FAILURE will not be tolerated.

The mail market is already plaque with a multi-billion industry wide abusive
spam problem primarily based on the exploitation of a legacy mode of
operation.

Without a doubt, the direction is to be proactive and pre-emptive which
means there is a HUGE payoff by eliminating the bad as soon as possible in
the transport process. The obvious dissemination is among the extremely high
rate of malicious transactions. Unfortunately, this was not really possible
in the legacy market - hence the world-wide problem.

What was missing is moving the mail transaction into a new level of
expectations where new strict TRANSPORT and/or PAYLOAD rules can apply.

Once you step up to DKIM, you are now putting on a brand new suit where you
better tie the bow right, put the socks and suspenders on correctly.

So no, it is not a status quo. There are new rules, new legal mode of mail
operations.

DKIM processing is not cheap and anyone who says its a "plug and play"
solution simply doesn't know what they are talking about.  There is an big
investment and any "overview" who says otherwise is simply not correct.

But for the majority of the world market encompassing mostly SMB, for a wide
adoption to accept DKIM processing, there has to be a payoff and looking for
only for the GOOD needle in the haystack simply isn't going to cut it in the
SMB market.

Finally, lets not forget DKIM needs to fit into a framework on currently
solutions.  Most people are not going to eliminate these working solutions
for a vague idea based on DKIM-BASE that promoters are having a hell of a
time selling to anyone now.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 8 Sep 2006 15:53:27 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 08, 2006 2:52 PM
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

> signature is largely irrelevant. It's about accountability.

If you are going to selectively answer only one of 20 questions, then it
doesn't help the process.

Again, WHERE is the PAYOFF if PROCESS DKIM and Just Looking for the "GOOD
needle in the haystack?"

> recipients do with their email.

And you are wrong to PUT words into my much. I never said Receivers can be
controlled.  However, the market environment is to ELIMINATE the bad
transactions and the market direction is being in this direction.

> It is the persistence in this

Sorry, you are incorrect.  You are trying to force feed a meaning of what
DKIM is suppose to do and I keep repeating I DON'T CARE what it suppose to
do as long as you do it right and the signature protocol is consistent
without introducing MORE harm and higher overhead in the process of
supporting it.

If you need an analogy, think HELO/EHLO client domain or literals and MAIL
FROM returned paths.   The problem we have today is 100% based on the
relaxation of no enforcing this states.

We can't do much about these two entities beause of the 20+ years of legacy
operations but there is no doubt, the smarter, better AVS ready SMTP systems
in the market do something about these old issuses.  They are not completely
ignored anymore.

Now with DKIM, we are NO longer talking about legacy operations at the
PAYLOAD level.  There is new expectation for new headers, new DNS records,
etc.

That is a recipe for high detection of failure based on non-compliancy and
unauthorized signatures.

So sorry, you are wrong and really wish you stop saying people they are
"Mistaken" so you can get a "+1" from your compadres because I could on to
say the same thing about how mistaken you are too.

The point is and always has been I really don't care what you think DKIM is
suppose to mean.  Its a Digital Message Signature method and it is about
Protocol Consistency.  Just blindly signing and broadcasting this junk to
receivers without a payoff of eliminating the bad is not going to be
tolerated in the wider market and quite frankly, I have a hard time
believing a high value domain is going to blindly sign mail with a "cross
your fingers, hope it makes" concept while at the SAME time assuming
"responsibility" for it.  That doesn't make sense.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 08 Sep 2006 12:57:28 -0700

> signature is largely irrelevant. It's about accountability.

It is interesting how vigorously and persistently this continues to be 
misunderstood.

d/

-- 

   Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 8 Sep 2006 16:59:19 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
Subject: Re: [ietf-dkim] SSP = FAILURE DETECTION

> It is interesting how vigorously and persistently this continues to be

Dave, it is NOT and NEVER WAS misunderstood!!

Although I have major concerns about the conflicts with this new
accountability and responsibility which undoubtedly leave itself open to
legal scrutiny,  the difference is that DKIM-BASE creates a new level of
expectations
and SSP is about the detection of failure and non-compliancy with the
protocol consistency.

At some point, this "accountability" has to have some redeemable value.

You want receivers to play dumb and just return a VALID or INVALID state
which still acceptable the mail.

What I am telling you is that this regardless of what the SIGNATURE means,
its failure will not be tolerated in wide adoption.

So lets assume there is no SSP and we just have a pure DKIM-BASE verifier,
what do you want us to do with the two possible end-results?

   - INVALID signature
   - VALID signature

Do you want us to present 'something' to users and if so, how do you present
this to the different users types?

  - ONLINE mail users?
  - OFFLINE mail pickup users?

For the online users, our hosting software can present "something"

   -WARNING: something wrong with this message?
   -NOTE: This message seems to be ok!

But how do you pass this information for the offline mail pickup users?

Are you expecting them to be DKIM-READY to display this information
themselves?

If so, why should the MTA even bother to do DKIM-PROCESS and just let the
offline MUA do the DKIM processing?

The bottom line is that you still need to "FILTER" something at some level
even if you don't use SSP at the MTA and I can assure you that without SSP,
I am less willing to assume product liability issues by wasting time doing a
ACCOUNTABILITY check at the MTA that has no payoff of eliminating mail.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 8 Sep 2006 17:29:40 -0700

> Are you expecting them to be DKIM-READY to display this information  

Unless the MDA modifies the message, DKIM can be verified at the MUA  
or even the web client for that matter.  DKIM working in conjunction  
with MUA  annotations provides for many of the human factors needed  
to thwart much of the fraud.  Look-alike attacks should prove far  
less successful, for example.

> If so, why should the MTA even bother to do DKIM-PROCESS and just  
> let the offline MUA do the DKIM processing?

One advantage would be an ability to safely bypass filters for bulk  
senders where prior arrangements have been made.  The other might be  
to reduce a filter's false positive rate, minimize defanging  
operations, and improve abuse reporting.

> The bottom line is that you still need to "FILTER" something at  
> some level even if you don't use SSP at the MTA and I can assure  
> you that without SSP, I am less willing to assume product liability  
> issues by wasting time doing a ACCOUNTABILITY check at the MTA that  
> has no payoff of eliminating mail.

The "bottom line" could be annotations applied that benefit the  
recipient without filtering beyond what is normally done already.   
DKIM should improve the performance of this filtering process as  
well.  A reduction in spam might be expected by reducing the revenue  
sustained by successful fraud in the way of identity thief, and the  
introduction of malware.  Of course, it might also mean bad actors  
redouble their efforts.  The real "bottom line" is that DKIM can not  
prevent spam.  Contrary to Dave's opinion, when DKIM is coupled with  
an intelligent MUA, it should reduce the success rate for much of the  
fraud, and improve the open rates for valid messages.

To support an intelligent MUA, only email-addresses "assured" valid  
are safely annotated.  The percentage of email-addresses protected by  
DKIM can be improved through the use of policy records by:

  - extending a signing domain's ability to assure the validity of an  
email-address.

  - limiting assurances to selected email-addresses, when annotation  
are based upon a trusted-domain list.

-Doug

---

From: <[email-masked]>
Date: Sat, 9 Sep 2006 10:48:43 -0400

judging by what shows up at my MTA's 80% of the market has a sharp disagreement with you.

"  However, the market environment is to ELIMINATE the bad
transactions and the market direction is being in this direction."

If you switch market to "receivers market" I'll agree
thanks,
Bill

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Sep 2006 12:43:52 -0700

> But where was the acceptance criteria in the first place?  That it passed

The acceptance criteria is completely external to DKIM -- Steve labeled 
it as "B" in the portion you quoted above.

Why is this such a difficult concept?

> Legacy Mail operation once DKIM is a presumed default behavior.

By the time DKIM is "a presumed default behavior," we'll understand the 
real-world use cases for both BASE and SSP a lot better than anyone does 
today.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 16:09:17 -0400

----- Original Message -----
From: "J.D. Falk" <[email-masked]>
To: "IETF-DKIM" <[email-masked]>

>> But where was the acceptance criteria in the first place?
>> That it passed the DKIM test?
>
> The acceptance criteria is completely external to DKIM -- Steve
> labeled it as "B" in the portion you quoted above.
>

Nothing at all, but reputation is out of scope.  Or is it?  Where is the
specification?  Whose reputation database are we suppose to use?   Yours?
John's?  The other system I just heard about with its own "DAC" concept or
even the one that Santronics might invest in producing?

I honestly wish that we are can be "men" enough here to admit what is the
precise debate going here.  We have a reputation out of scope WG mandate,
yet, we have a group that is winking their eye, saying "Sure, right!"

As I always said, reputation will be among us. Everyone has a White/Black
and many even use Grey now.  But we don't need DKIM to have this explicit
list of the good or bad.  Its a different level.

What SSP focuses on its the mechanics of the DKIM protocol, not a subjective
"Member only" concept, that a) isn't standardized and run the risk of having
different results based on what service bureaus you subscribe to, paid, free
or otherwise.

I think it is unrealistic to believe the wider market of receivers, not just
the selected high value few, are going to accept and tolerate DKIM abuse
that requires extra batters using non-standard methods and a requirement to
participate in one or more 3rd party databases to find out, purely based on
the 3rd party vouching system, if the mail is good.

I would rather add logic to my SMTP system to disseminate the non-compliant
bad first which by far has reached atleast 80% and just pass on the
indeterministic remainder to the administrator and users to decide what they
want.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Sep 2006 13:30:12 -0700

> even the one that Santronics might invest in producing?

Yahoo! will use Yahoo!'s internal systems to make our own internal 
decisions about each message.  AOL will, I'm sure, use AOL's.  Everyone 
will make their own decision in their own way, just like today -- 
perhaps with a 3rd party's input, perhaps not.  It's up to them.

A DKIM verification result is just one more input.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 20:05:17 -0400

----- Original Message -----

> decisions about each message.  AOL will, I'm sure, use AOL's.
> Everyone will make their own decision in their own way, just
> like today -- perhaps with a 3rd party's input, perhaps not.  It's
> up to them.

No doubt. Just like today.

> A DKIM verification result is just one more input.

In what way?

If there a consistent ACCEPT, DENY and DELIVERY DECISIONS method so that
when XYZ.COM sends signed mail to users at YAHOO.COM and AOL.COM, you don't
get inconsistent results?

There are so many issues with this DKIM-BASE + LOCAL POLICY UNKNOWN that I
find it hard to see how it justifies the risk of signing.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 17:22:40 -0700

On Sep 11, 2006, at 5:05 PM, Hector Santos wrote:

> There are so many issues with this DKIM-BASE + LOCAL POLICY UNKNOWN  
> that I find it hard to see how it justifies the risk of signing.

What issues and risks do you refer to with respect to signing?

How does policy ameliorate these issues and risks with signing?

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 20:50:39 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "IETF-DKIM" <[email-masked]>
Sent: Monday, September 11, 2006 8:22 PM
Subject: Re: accept, deny, or other delivery decisions (was Re: [ietf-dkim]
SSP= FAILURE DETECTION)

>> There are so many issues with this DKIM-BASE + LOCAL
>> POLICY UNKNOWN that I find it hard to see how it justifies
>> the risk of signing.
>

- Inconsistent results.
- Fake it to you make it.
- 3rd party signatures
- Bad Actors remain in legacy operations HOPING for unknowns.
- Good Actors remain in legacy operations FEARING the unknowns.
- Receivers requiring to support multiple "batteries."

and so on and so on.

> How does policy ameliorate these issues and risks with signing?

See

http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 11 Sep 2006 18:29:52 -0700

>> A DKIM verification result is just one more input.

IP address is an input.  Each URL in the message is an input.  Virus 
scanning results on attachments are an input.  Filtering hasn't been 
binary for years.

> get inconsistent results?

Could you rephrase the question?

> find it hard to see how it justifies the risk of signing.

Good thing signing is optional, then, huh?

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 18:49:50 -0700

On Sep 11, 2006, at 5:50 PM, Hector Santos wrote:
>>> There are so many issues with this DKIM-BASE + LOCAL POLICY  
>>> UNKNOWN that I find it hard to see how it justifies the risk of  
>>> signing.
>>

DKIM results are not visible to the recipient without either  
annotation or 100% blocking of unsigned email-addresses.

When the operation of DKIM does not expect all messages containing a  
specific email-address to be blocked, one should assume annotation is  
how a recipient is aware of valid DKIM signatures.

> - Inconsistent results.

Either the signature is valid or it is not.  This does not depend  
upon policy.

The message can be annotated as having the following:
  - A valid signature with a matching email-address domain.
  - A valid signature with an associated email-address domain.
  - An assured email-address comparing with a retained email-address.

These annotations do not depend upon policy for consistent results.   
When policy does not assure an email-address is initially signed with  
only compliant services subsequently used, only annotations offer  
recipients any consistent information.  Invalid signatures with such  
an email-address are consistently _not_ blocked.  Of course blocking  
breaks existing uses of email, and does not offer much in the way of  
anti-spoofing protection anyway.

Can you be a bit more specific about what do you mean by inconsistent  
results?

> - Fake it to you make it.

An assured email-address comparing with a retained email-address can  
provide comprehensive protections from spoofing.  Again, this  
protection does not depend upon email-address policy.

> - 3rd party signatures

When a signature can be associated with the email-address, this email- 
address can be annotated.  Here policy can offer requisite email- 
address associations.  If not, then no annotations and no resulting  
issues either.

> - Bad Actors remain in legacy operations HOPING for unknowns.

They never receive the requisite annotations!

> - Good Actors remain in legacy operations FEARING the unknowns.

What is there to fear?

> - Receivers requiring to support multiple "batteries."

The MUA already has an address-book.  No batteries required.

What is your concern?  Blocking messages that happen to have invalid  
signatures breaks email.  As this blocking can only hope to provide  
minor protections, why not adopt a system that provides substantially  
better protections from spoofing and retains email delivery  
integrity?  Policy is needed for associations to increase DKIM's  
coverage.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 21:54:29 -0400

----- Original Message -----

> IP address is an input.  Each URL in the message is an input.
> Virus scanning results on attachments are an input.
> Filtering hasn't been binary for years.

Not sure of the "binary" relationship, but these are are different ideas.
A) its not part the scope, and neither is reputation, b) some of the ideas
above is based on BAD filtering, not GOOD.

But what I was looking for is how it relates to the DKIM-BASE specification.

     result1 = Yahoo(DKIM-BASE,LOCAL_POLICY_UNKNOWS)
     result2 = Aol(DKIM-BASE,LOCAL_POLICY_UNKNOWS)
     ...
     resultN = TheWorld(DKIM-BASE,LOCAL_POLICY_UNKNOWS)

You now have the potential for varying results.

Since DKIM-BASE has a IGNORE FAILURE mandate, you are left with a GOOD
acceptance concept. Not bad.

In short, you would be ignore all the most obvious loopholes that are
possible with DKIM-BASE failures.

And on a product manager to product manager basis, since you are now
introducing an external DKIM variable about "Domain Responsible" into your
scoring, you now have a new level of possible product liability issues at
the receiver level.  Now you have to be more careful about displaying a
"Star or Good DKIM Mail Seal". I would suggest to run it by your chief
council again.

>> If there a consistent ACCEPT, DENY and DELIVERY DECISIONS method
>> so that when XYZ.COM sends signed mail to users at YAHOO.COM and
>> AOL.COM, you don't get inconsistent results?

> Could you rephrase the question?

Sorry, that should of started with "Is there...."

In short, what I wrote above with a domain achieving different DKIM-BASE
results depending on which DKIM-BASE only systems it sends its mail to.

> Good thing signing is optional, then, huh?

You would think.

But it is really optional with the 3rd party DKIM appliance boxes and 3rd
party service bureaus and ISP/ASP/ESP blinding signing mail?

What is the input value when Yahoo receives a 3rd party signed mail from
domains that only expects its own signature?  Does that say the DOMAIN is ok
if the 3rd party signature passes?

Don't get me wrong.  Reputations is always a good idea for receivers but I
see that as completely different and it doesn't address the DKIM protocol
consistency problems.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 22:07:36 -0400

----- Original Message -----

> upon policy
> Can you be a bit more specific about what do you mean by
> inconsistent  results?

I was referrering to the "Dark Secret" model that Mr. Falk and Mr. Akins was
thinking about such as:

    Result = DKIM-BASE + REPUTATION

This has the potential to be different depending on which receiver and its
non-standard reputation layer.  Also DKIM-BASE mandates a:

    Ignore Failure as it was never signed

so therefore, this model can only apply to a GOOD CITIZEN model.  All
failures are ignored including the most obviuous of DKIM domain abuse,
direct or indirect.

> protection does not depend upon email-address policy.

Doug, you keep introducing something that is NOT part of the current model
everyone is considerating.  Even then, you are ignoring the failures too
(i.e, when the retained email addresss "Address Book" does not exist or you
are dealing with an anonymous sender).

> address associations.  If not, then no annotations and no resulting

Again, same answer.

> The MUA already has an address-book.  No batteries required.

It does?  What if its not populated?  And if it was, are you going to sure
your address box with others?  And whose MUA are you going to support?
Your's?  Outlook?  How about the others?

Again, you are not dealing correctly with the #1 abuse - anonymous senders
at the HOSTING level.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 19:38:29 -0700

On Sep 11, 2006, at 7:07 PM, Hector Santos wrote:

> non-standard reputation layer.

You seem to be deeply confused as to what "reputation" is. Every
receiving MTA, and possibly every recipient will have a different
view of a signers reputation.

Given that, expecting everyone to have exactly the same result
when they apply their reputation model to an email that's authenticated
from a given author is obviously nonsensical.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Sep 2006 23:06:47 -0400

> scanning results on attachments are an input.  Filtering hasn't been

While that's true, I think part of the point is to limit the need to filter.  
For example, mail to my domains is scanned pre-queue and rejected if it 
contains a virus or is from a client on certain reasonable safe RBL lists.  
That's binary and it's not filtering, so it isn't at all counter to your 
point.

What's left goes into a filtering process that is, as you say, not binary.

I'd like to get rid of a larger fraction of the 'bad' mail in the rejection 
stage and deal with less of it in the filtering stage.  Accept/reject 
criteria that can be used add to the reliability and consistency of the 
e-mail system.  

I do think that the SSP idea has potential to add value within the filtering 
regime too.  I would imagine that a message from a 2822.From domain with no 
signature and no SSP and a message from a 2822.From domain with a 'sign-all' 
SSP and no signature would be weighed differently during the scoring process.  
Even if you are just in the filtering business and not in the rejection 
business, SSP gives you another piece of information to add to the matrix.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Sep 2006 23:08:31 -0400

> from a given author is obviously nonsensical.
OK, then I'm confused because I think that you and Hector are saying 
essentially the same thing in your message and his that you replied to.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 11 Sep 2006 23:10:34 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: "IETF-DKIM" <[email-masked]>

>> I was referrering to the "Dark Secret" model that Mr. Falk
>> and Mr. Akins was thinking about such as:
>>
>> This has the potential to be different depending on which
>> receiver and its non-standard reputation layer.

> You seem to be deeply confused as to what "reputation" is.

Cheap shot.

> Every receiving MTA, and possibly every recipient will have
> a different view of a signers reputation.

Exactly.  There is no confusion about the potential to have varying results
based on a reputation model.

> when they apply their reputation model to an email that's
> authenticated from a given author is obviously nonsensical.

Of cause, so if its so fuzzy and subjective why did you start this thread by
answering the question "what is the purpose? indicating it will be part of
some out of scope reputation test?

I don't expect the same result with reputations - thats the point.  Its a
subjective concept and it really has nothing to do with the mechanics and
physical attributes of the DKIM protocol.

What if the DKIM message is not signed?  How does reputation play a role
now?  Are you thinking everyone is going to use some common DKIM related
reputation system like DAC with some inherent "No Signature" reputation
rule?

 no sign + domain part of DKIM reputation database ====> failure

Sounds like a SSP concept to me?  Oh I see. Just the wrong one.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 05:24:07 +0200

Hector Santos wrote:
 
> lets assume there is no SSP and we just have a pure DKIM-BASE
> verifier, what do you want us to do with the two possible
> end-results?
 
>    - VALID signature

The overview document has to answer that question in plain and
simple English.

> how do you pass this information for the offline mail pickup
> users?

Put it in an x-header field, add a comment to your timestamp
line, allow users to define white lists and a separate IMAP
folder for valid white-listed signatures (?).

Frank

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 20:36:52 -0700

On Sep 11, 2006, at 8:08 PM, Scott Kitterman wrote:

>> authenticated

Hector asserts that "inconsistent results" is a risk with respect to  
signing.

His reasoning behind that is that because every recipient decides
whether to acccept or reject mail is based on several factors, including
the senders reputation, and that that reputation will vary.

That has nothing to do with whether the mail is signed or not (though
reputation based-filtering is likely to drastically more accurate with
mail that is signed). Unsigned mail is also going to be delivered, or
not, depending on many things, including the reputation of the sender.

So describing "inconsistent results" as a "risk of signing" seems
something of a non-sequitur. Or possibly I'm misunderstanding,
in which case I'm sure Hector will expand on the issue, with a
clearer explanation of what he means and some concrete
examples.

Cheers,
   Steve

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 05:42:47 +0200

Steve Atkins wrote:

> The cynic in me says that the sole purpose of SSP is to
> affect the deployment of DKIM.

And the sole purpose of DKIM is to accelerate SpamCop's report
generation... <gd&r>

---

From: Steve Atkins <[email-masked]>
Date: Mon, 11 Sep 2006 20:48:46 -0700

> And the sole purpose of DKIM is to accelerate SpamCop's report

Or at least make it more accurate. That is _one_ of the
goals of DKIM, and one it's likely to fulfill, I think. Similarly for
feedback loops from some large ISPs.

Note, though, that I didn't say whether SSP would affect DKIM
deployment positively or negatively - I suspect views on that
would differ wildly. :)

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 12 Sep 2006 04:46:15 -0000

>scanning results on attachments are an input.  Filtering hasn't been 

It still is where Hector lives.

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 12 Sep 2006 01:13:32 -0400

----- Original Message -----

> clearer explanation of what he means and some concrete

I'm not sure how much clearer I can make it but I will try.

This was in regards to the usage of non-standard reputation systems - local
database or shared with 3rd party DKIM-REPUTATION service bureaus.

You mentioned the purpose of DKIM is to use reputation as the basis for
acceptance.

If you presume all systems use the same DKIM-REP system, there is less
concern about inconsistent results.

But if that is not the case, you have the potential for inconsistent
results.

The issue is that there is no standard on how to combine DKIM plus
reputation.

With SSP, we are talking about a single standards effort, where the results
will be consistent against all systems.

The example is the broadcast of signed or unsigned messages to 1000 systems
with DKIM-REP vs 1000 systems with DKIM-SSP.

Do you expect consistency with DKIM-SSP?  I hope so.

Do you expect consistency with DKIM-REP?  I don't see how unless they are
using the same reputation system.

Because of this inconsistency,  there is a risk of signing because bad
actors can do the same thing and broadcast spoofed mail to these 1000
DKIM-REP systems and there is a good chance many will make it thru.

Also, as I mentioned, the verifiers themselves has to now consider multiple
DKIM-REP ideas.  So we end up with a DNSRBL like concept whether each system
has there own list of RBL sites to check.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 12 Sep 2006 07:05:27 +0200

>> And the sole purpose of DKIM is to accelerate SpamCop's
>> report generation... <gd&r>

> goals of DKIM, and one it's likely to fulfill, I think.

Yes, I can't tell if SC already uses DKIM for this purpose.

> Similarly for feedback loops from some large ISPs.

And with less complications.

> deployment positively or negatively - I suspect views on that

I'll wait until I see more drafts with an "approved" stamp.  If
DKIM boils down to "use crypto to protect your timestamp line",
is it just another way to emulate reverse paths without using
reverse paths ?

Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Sep 2006 23:56:10 -0700

On Mon, 2006-09-11 at 22:07 -0400, Hector Santos wrote:
> I was referring to the "Dark Secret" model that Mr. Falk and Mr. Akins
> was thinking about such as:
> 
> failures are ignored including the most obvious of DKIM domain abuse,
> direct or indirect.

DKIM Reputation lists, due a potentially devastating impact and related
replay problems, may be just a list of known identities rather than the
classical spam reputation lists.  Nevertheless such lists still offer
protections from spoofing.  As such DKIM might be viewed as the Okay
Citizen model.  

DKIM identifies senders, improves reporting, and filtering, but does not
prevent spam.  Done right, DKIM can be the best thing since sliced
pizza. 

> Doug, you keep introducing something that is NOT part of the current
> model everyone is considering.  Even then, you are ignoring the
> failures too (i.e, when the retained email addresses "Address Book"
> does not exist or you are dealing with an anonymous sender).

Reputation is not part of the model either, yet it will be used.
Compartmentalizing a design effort does not need to ignore how results
might be used.  In this case, perhaps the retained annotation strategy
is the only way DKIM truly offers protection.

The assured/retained email-address comparison (ARC) annotation is not
much different that going to a web site that offers HTTPS security with
valid Certs and a lock-icon.  Without an ARC annotation, not trusting
the message should be a typical reaction.  Not every web page must use
HTTPS with a valid Cert, and not every email must obtain ARC annotations
for security to be retained.  People simply need to act
accordingly.     

> > address associations.  If not, then no annotations and no resulting

I am lost.  Again, what is the problem?

> It does?  What if its not populated?

The recipient may not be able to see functional links, attachments, or
pictures either.  The address-book is already commonly part of a
security strategy.  It is fairly common to see senders request
recipients to add them to the address-book for this very reason.  If
they also want ARCA annotations, add them to the address-book.

> And if it was, are you going to sure your address box with others?

Huh?  Do you mean third-party lists?  

> And whose MUA are you going to support?

Any that handle standard interfaces.

> Your's?  Outlook?  How about the others?

As they said in the movie the Graduate... Plugins. : )

> Again, you are not dealing correctly with the #1 abuse - anonymous
> senders at the HOSTING level.

What do you mean?  Any transactional email likely starts with a visit to
a web site.  In addition to asking for details related to the recipient,
also ask for a picture or phrase so the recipient can later recognize
your initial message.  When they do, they can safely add this to their
address-book.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 12 Sep 2006 11:54:19 -0700

> results depending on which DKIM-BASE only systems it sends its mail to.

So, you're concerned that senders won't be able to know beforehand how 
their mail will be received?  DKIM seems like a very poor tool to affect 
that particular common complaint.

Also you're still thinking only as a sender, not as a receiver or an 
intermediary.  SMTP (and everything built on top of it) is a 
conversation, not an announcement.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 13 Sep 2006 01:49:48 -0400

----- Original Message -----

> conversation, not an announcement.

Mr. Falk, I think it is safe to say, I am on record for the last 1.5 years
actively involved as a WG participant for this project, with concerns across
the board, the repercussions and victims for DKIM-BASE only environments,
which include the harm to the domain itself, but more importantly the
potential abuse against innocent receivers and possible users.   The
receiver concerns were significant enough for me to write a IETF DRAFT:

Anyway, I don't think you interpreted the concern incorrectly.

It is because of that inconsistent DKIM reception handling unknowns between
different systems, we risk encouraging DKIM bad actors to proliferate
against the new creation of different potential targets.

In summary, the concern is that there is a risk when you don't have a common
DKIM-BASE handling concept.

Thanks for the exchange.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Sep 2006 01:23:46 -0700

On Wed, 2006-09-13 at 01:49 -0400, Hector Santos wrote:
> It is because of that inconsistent DKIM reception handling unknowns
> between different systems, we risk encouraging DKIM bad actors to
> proliferate against the new creation of different potential targets.
> 
> In summary, the concern is that there is a risk when you don't have a
> common DKIM-BASE handling concept.

Could you give a simple example of this risk?  Please be brief.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 13 Sep 2006 07:35:27 -0400

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Could you give a simple example of this risk?  Please be brief.

Real world example - DNSRBL

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Sep 2006 10:16:37 -0700

On Sep 13, 2006, at 4:35 AM, Hector Santos wrote:

>>> It is because of that inconsistent DKIM reception handling  
>>> unknowns between different systems, we risk encouraging DKIM bad  
>>> actors to proliferate against the new creation of different  
>>> potential targets.
>>>
>>> In summary, the concern is that there is a risk when you don't  
>>> have a common DKIM-BASE handling concept.
>>

A bit too brief. : )

I assume you mean RHS-Block-lists based upon the DKIM signing domain?

Whether bad actors use DKIM or not does not appear to represent any  
added risk.

The limitations in a DKIM signing domain assessment will be exploited  
by bad actors.  DKIM has a rather major limitation requiring a  
message envelope to be considered independently from that of the  
signing domain.  This means there _are_ substantial risks for the RHS- 
Block-List operator.  This limitation requires stronger evidence of  
behavior approaching that of a criminal nature.  This requirement is  
well beyond what is normally adequate for listings in IP address  
block-lists.

Could you clarify your concern with simple example that illustrates  
what you want to see changed.  Again please be brief, but do provide  
the example.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Sep 2006 11:21:29 -0700

> Anyway, I don't think you interpreted the concern incorrectly.

Certainly possible.  I hope we see a wider variety of real-world 
implementations soon so that we can figure out what's actually going to 
happen, rather than just guessing (whether those guesses are educated or 
not.)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 13 Sep 2006 12:24:13 -0700

On Sep 13, 2006, at 11:21 AM, J.D. Falk wrote:

> I hope we see a wider variety of real-world implementations soon so  
> that we can figure out what's actually going to happen, rather than  
> just guessing (whether those guesses are educated or not.)

You seem to be suggesting the WG should conclude and wait for  
industry leaders?  Will this result in open or proprietary solutions?

-Doug