Subject: Re: [ietf-dkim] A few SSP axioms

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 23:10:06 -0700

On Mon, 2006-07-31 at 23:25 -0400, Scott Kitterman wrote:
> On Monday 31 July 2006 21:22, John Levine wrote:
> >> I think this is the key issue then and we ought to focus on it.  In
> >> my view almost the entire point of a signing policy is constraining
> >> whose signatures are considered authorized by the domain owner.
> >
> > I'm assuming that when you say authorized, you mean authoritative.
> > (English definitely has its shortcomings.)
> 
> I meant authorized, as I think the SSP concept is about authorization.
> I can see where authoritative fits better as I wrote it.  I'm not sure
> there is a distinction between the two worth arguing about.

The last time policy was reviewed before starting to the base draft, the
conclusion was that policy is not an authorization function, rather
policy indicates what the identity uses or does.  With that in mind,
John's terminology of "authoritative" better reflects that view.

Assume that the 2822.From domain indicates both the use of designated
domains and non-designated domains.  Assume also that by definition
designated domains MUST employ DKIM, but that non-designated domains MAY
employ DKIM.  A designated domain might also be defined as being
"authoritative" when it comes to concerns related whether the message is
being replayed or whether the identity header is valid.  The same policy
may also indicate use of non-designated domains that are defined as "not
authoritative."

Your Authorization terminology is easily confused with what might be
implied by "authoritative."  For either the designated or non-designated
domains, their indicated use might imply an "authorization of use" when
viewing policy as an authorization function.  It seems better to avoid
referring to policy as "authorization" to keep the terminology
consistent and what is being indicated clear.

-Doug

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 02:14:11 -0400

> consistent and what is being indicated clear.

I don't recall that conclusion, but I'll stick with what I said the first 

> > there is a distinction between the two worth arguing about.

I'm leaving on vacationthis afternoon, so I'll leave you and the rest of the 
WG to figure it out while I'm gone.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 10:12:39 +0100

Scott Kitterman wrote:

>> Message from A, signed by A and B; does SSP matter? (I hope not.)
> 
> In my book it's the same as A signed by A.  The only concern I would have is 
> if B added content, what to do about that, I'm not sure.  I expect that's 
> probably a question for receiver policy and unlikely to be standardized.
>> Message from A, signed by C; SSP says nothing about C.
> 
> Yes.  Then how to treat this would be a question of what A's SSP says (is the 
> list exclusive or not) and the receiver policy.  

I still don't understand why we care if someone adds a signature and
does nothing else.

If B adds a signature covering a header not covered by A's signature,
then I can imagine that the verifier might want to treat that header
differently from those signed by A. But ignore that for now - if both
A and B sign exactly the same headers+content, then what bad thing
can happen? (That would cause A to want a countermeasure.)

> I think that the matrix that Hector did back at (or possibly just before) the 
> working group started was a good one.

Agreed. Tables can call out less-obvious cases like where B adds another
field as above. (Note: I'm not saying I agree with the table content,
but I did like the approach.)

S.

PS: Have a nice vacation!
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 07:37:11 -0400

On Tuesday 01 August 2006 05:12, Stephen Farrell wrote:
> > In my book it's the same as A signed by A.  The only concern I would have
> > is if B added content, what to do about that, I'm not sure.  I expect
> > that's probably a question for receiver policy and unlikely to be
> > standardized.
> >
> > Yes.  Then how to treat this would be a question of what A's SSP says (is
> > the list exclusive or not) and the receiver policy.
>
Agreed, but in the multiple signature case my caveat was limited to the case 
of the second signer adding content.  If B adds a signature, but does not 
modify the content of the message, then I don't think the verifier would 
treat them differently.

As I read the later case, the only signature present (C's) is not one that is 
included in A's SSP.  In this case we have a message with a signature that is 
outside the scope what A has said is authorized (or not included in A's 
authoritative list).  If A is a high profile phishing target and signs all of 
it's mail, then it would be useful (I think) for receivers to recognize that 
the message has been signed by someone other than who A said it would.

I believe it's that distinction that gives DKIM the potential to be a useful 
(not a panacea, but useful) anti-phishing technology without having to layer 
a non-standard reputation system on top of it.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 12:57:35 +0100

> modify the content of the message, then I don't think the verifier would 

I do think the verifier might treat them differently, but the point is
that B's additional signature isn't harmful in any way, which would
imply that there's no need to express the following in SSP: "Only
these signers are supposed to sign my mail". (We may or may not want
to be able to say "One of these signers must sign my mail", but
that's different.)

I guess, if agreed, that'd suggest a potential non-requirement for SSP,
"no need to specify who's not supposed to sign".

> the message has been signed by someone other than who A said it would.

In that case its the absence of A's signature that is the problem and
not the presence of C's signature, so to me it seems like the same case
really. But I suspect we agree about this.

Cheers,
S.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 08:25:37 -0400

On Tuesday 01 August 2006 07:57, Stephen Farrell wrote:
> >>> In my book it's the same as A signed by A.  The only concern I would
> >>> have is if B added content, what to do about that, I'm not sure.  I
> >>> expect that's probably a question for receiver policy and unlikely to
> >>> be standardized.
> >>>
> >>> Yes.  Then how to treat this would be a question of what A's SSP says
> >>> (is the list exclusive or not) and the receiver policy.
> >>
> > Agreed, but in the multiple signature case my caveat was limited to the
> > case of the second signer adding content.  If B adds a signature, but
> > does not modify the content of the message, then I don't think the
> > verifier would treat them differently.
>
I can see that.

> > As I read the later case, the only signature present (C's) is not one
> > that is included in A's SSP.  In this case we have a message with a
> > signature that is outside the scope what A has said is authorized (or not
> > included in A's authoritative list).  If A is a high profile phishing
> > target and signs all of it's mail, then it would be useful (I think) for
> > receivers to recognize that the message has been signed by someone other
> > than who A said it would.
>
Yes.  Agreed.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 10:02:21 -0400

On Tuesday 01 August 2006 09:57, John Levine wrote:
> >> have is if B added content, what to do about that, I'm not sure.
>
> I'd appreciate a concrete example where B adds and signs content without
> breaking A's signature.
>
> There's a few scenarios that have come up:
>
> * The first signature has l= and B adds stuff at the end.
>
> * The first signature didn't have MIME headers and B adds them,
> perhaps making a lot of the original message invisible in a newly
> defined MIME part.
>
> Note that these two are easy to defend against: always sign MIME headers,
> even if there aren't any, and don't use l=.
>
> If people think there are other scenarios where a second signer can
> make signficant changes to a message without breaking an existing
> signature, we have worse problems than SSP.
>
No, those are the things I was thinking about.  Probably not a significant 
issue, but I thought it worth mentioning.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 1 Aug 2006 10:05:42 -0400

On Tuesday 01 August 2006 10:00, John Levine wrote:
> >As I read the later case, the only signature present (C's) is not one that
> > is included in A's SSP.  In this case we have a message with a signature
> > that is outside the scope what A has said is authorized (or not included
> > in A's authoritative list).  If A is a high profile phishing target and
> > signs all of it's mail, then it would be useful (I think) for receivers
> > to recognize that the message has been signed by someone other than who A
> > said it would.
>
> Why do you want to prevent people from forwarding genuine, unmodified
> messages?  That's a feature, not a bug.
>
In this scenario, A has said that it signs all it's messages and it's 
signature is not verifiably present.  I don't want to prevent people from 
forwarding genuine unmodified messages.  This is a case where a signature 
that the SSP of A has said is to be expected is missing, not standard 
forwarding.

> If ebay sends a message with a valid ebay signature, how can any chain
> of forwarding and added signatures change the fact that it's a real
> ebay message?  Let's assume that ebay has enough sense to sign its
> MIME headers and not to use l=, so the message that's delivered is the
> same one that was sent.
>
Agreed.  As Stephen pointed out, it's the absence of A's signature that is the 
real point I'm driving at.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 07:37:03 -0700

> "no need to specify who's not supposed to sign".

+1, and added.

       Mike

---

From: Damon <[email-masked]>
Date: Tue, 1 Aug 2006 11:06:11 -0400

I was having this discussion with someone off-list but...

Where I live, I am serviced by only one ISP. I get a discount by having my
services (business, home, cell, internet, etc) bundled by this one provider
and they sign all my messages. Choosing another provider etc. may not
be financially agreeable. I also know that there are spammers or bots on
this provider that take enjoyment out of using my name. So I want to say-
Trust my signature but expressly distrust my providers signature if not
also signed by me. Both messages, mine and the spammers are genuine and
unchanged, signed by my provider, but only my signed messages are valid.
 I see this as a feature.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 08:11:49 -0700

Damon wrote:

> Where I live, I am serviced by only one ISP. I get a discount by 
> having my services (business, home, cell, internet, etc) bundled by 
> this one provider and they sign all my messages. Choosing another 
> provider etc. may not be financially agreeable. I also know that 
> there are spammers or bots on this provider that take enjoyment out 
> of using my name. So I want to say- Trust my signature but expressly 
> distrust my providers signature if not also signed by me. Both 
> messages, mine and the spammers are genuine and unchanged, signed by 
> my provider, but only my signed messages are valid.
>  I see this as a feature.

I think this reduces down to the 1st party scenario: you sign your mail,
and it may in transit collect some other signatures (your ISP). So long as
you have a policy which is, say, "I sign everything", the addition of other
signatures shouldn't cause any trouble -- the policy is about the 1st party,
not the third party.

There has been suggestion in the past of the desire for a policy for "I sign
everything, don't accept a message with *any* third party signatures". I've
yet to see why anybody would want to set such a policy in real life though.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 16:11:37 +0100

Hi,

Damon wrote:
> Where I live, I am serviced by only one ISP. I get a discount by having 
> my services (business, home, cell, internet, etc) bundled by this one 
> provider and they sign all my messages. Choosing another provider etc. 
> may not be financially agreeable. I also know that there are spammers or 
> bots on this provider that take enjoyment out of using my name. So I 
> want to say- Trust my signature but expressly distrust my providers 
> signature if not also signed by me. Both messages, mine and the spammers 
> are genuine and unchanged, signed by my provider, but only my signed 
> messages are valid.
>  I see this as a feature.

I don't understand what the provider's signature is bringing to the
party in this case. Why is:
	your signature plus a please-distrust-this-provider signature
better than
	your signature alone?

Stephen.

---

From: <[email-masked]>
Date: Tue, 1 Aug 2006 11:21:30 -0400

Perhaps his provider signs all outgoing mail regardless without having
to parse a list of who signs their own mail locally. Daemon is also
right, spam from bots inside his ISP space will be sending mail that is
signed by the provider until they are stopped by the abuse department.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, August 01, 2006 11:12 AM
To: Damon
Cc: [email-masked]
Subject: Re: [ietf-dkim] A few SSP axioms

Hi,

> Where I live, I am serviced by only one ISP. I get a discount by
having 

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Aug 2006 08:30:17 -0700

Damon wrote:
> ...So I

SSP is not about "trust".  SSP does not provide instructions to recipients.

SSP makes declarations about the practices by the sender.

In the specific scenario you describe, the trustworthiness of your operator is
something that will be assessed by the receive-side component that uses the
validated signature(s).

d/
-- 

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

---

From: John Levine <[email-masked]>
Date: 1 Aug 2006 15:48:00 -0000

>Agreed.  As Stephen pointed out, it's the absence of A's signature
>that is the real point I'm driving at.

OK.  So would A's SSP say I sign all my mail, or something else?

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Aug 2006 12:52:10 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Damon" <[email-masked]>

> There has been suggestion in the past of the desire for a policy
> for "I sign everything, don't accept a message with *any*
> third party signatures". I've yet to see why anybody would
> want to set such a policy in real life though.

hmmm, Isn't this "highly exclusive" policy just happens to be the most
powerful protection the DKIM protocol has to offer?

If made available, the highest protection, will be the most likely policy
used... in real life.

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

---

From: John Levine <[email-masked]>
Date: 1 Aug 2006 14:00:04 -0000

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 18:13:16 +0100

Hector,

> powerful protection the DKIM protocol has to offer?

So, you're saying that...

"A says he signs everything"

     ...is "weaker" than....

"A says he signs everything and no-one else is allowed to sign A's mail"

What's the benefit for the signer/originator or the verifier? I just
don't see one.

Stephen.

---

From: Damon <[email-masked]>
Date: Tue, 1 Aug 2006 13:26:02 -0400

I understand that it is not a reputation service, however, I am now at the
mercy of my ISP's reputation and not mine. In fact, they are full of bots
and spammers.

 Consider:
 I never sign email coming from Holiday Inn where 50% on my workforce lives
out of suitcases but Holiday Inn does sign (inconsequential)
 I always sign email coming from the home office in Walla Walla.
 Therefore my rule says that I sometimes sign. But what good did that do me?
My ISP is the issue, not Holiday Inn. So, if I was able to say I sometimes
sign my email and I always sign from the home office, it would be too much
of a DNS load to describe where I might sometimes sign. It would be better
if I could specifically just distrust my ISP.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Tue, 01 Aug 2006 10:34:43 -0700

I believe that the basic disconnect here is that the protocol "protects" 
anything.
The running assumption that I've seen the most support for is that the 
protocol
*informs" other entities of the way the domain behaves, and the protocol 
consumer
may or may not use that information in conjunction with other 
information to
"protect" their incoming mail feed. Thus requirements that presumes that the
sender knows the mail transit topology seem rather incongruous with an
information service about the sender itself.

       Mike

Damon wrote:

> I understand that it is not a reputation service, however, I am now at 
> the mercy of my ISP's reputation and not mine. In fact, they are full 
> of bots and spammers.
>  
>  Consider:
>  I never sign email coming from Holiday Inn where 50% on my workforce 
> lives out of suitcases but Holiday Inn does sign (inconsequential)
>  Therefore my rule says that I sometimes sign. But what good did that 
> do me? My ISP is the issue, not Holiday Inn. So, if I was able to say 
> I sometimes sign my email and I always sign from the home office, it 
> would be too much of a DNS load to describe where I might sometimes 
> sign. It would be better if I could specifically just distrust my ISP.
>  
> Regards,
> Damon Sauer
>
>  
> On 8/1/06, *Hector Santos* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     From: "Michael Thomas" <[email-masked] <mailto:[email-masked]>>
>     To: "Damon" <[email-masked] <mailto:[email-masked]>>
>
>
>
>     http://www.santronics.com <http://www.santronics.com>
>
>
>
>
>
>     <http://mipassoc.org/dkim/ietf-list-rules.html>
>
>

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Aug 2006 13:34:24 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> "A says he signs everything and no-one else is allowed to sign A's mail"

Yes. I say that would be a weaker policy.

>From a security standpoint, the highest protection is the "Greedy One", the
one with high exclusivity with absolutely no expectation for tampering, gain
of new information, unknown finger prints, etc.  This yields the highest
confidence for the DKIM protocol.

All other policies begin relaxed deviations of the highest protection
possible.

However, this does not exclude the possibility of a service bureau who
operates and provides a service as a transparent 3rd party signer in behalf
of the original party.  This is also a highly possible scenario for mail
servers who are locally hosting domains and is providing a "Complete DKIM
Signing Service Plan(s)" for this hosted domains.

  Plan 1 - Host signs as 3rd party for domain  - $.10 per msg
  Plan 2 - Host signs as 1st party for domain  - $.25 per msg

etc, in Plan 2, the host will basically create the keys for the domain or he
might allow the domain to create it.

This level of possible host/domain service contracts was discussed in quite
detail in the old list among myself, Earl Hood, Jim and a few others.  Earl
Hood, as you probably now, is/was the chief architect for the GoodMail
system that touched base with much of what we are discussing here.  Probably
doesn't hand around for NDA reasons now.

---

From: Damon <[email-masked]>
Date: Tue, 1 Aug 2006 13:39:22 -0400

I agree with everything you just said. My only point is that it would be
more useful given the ability to distrust. Just another tool.

I should have said in my last message that Walla Walla has an SPF record
that points to their ISP. Given the ability to distrust, it would plug this
hole.

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Aug 2006 18:43:57 +0100

Damon wrote:
> the mercy of my ISP's reputation and not mine. In fact, they are full of 
> bots and spammers.

But if you use that ISP, then arguably you should be affected by
whatever reputation services think of the ISP. You just need your
sparkling rep to outshine their dull one:-)

And since reputation services are out of scope for the WG, I would
have thought that statements like "ignore my ISP's signature since
he's got a bad reputation" would therefore be out of scope for ssp.
Perhaps you could make a case that "please ignore all signatures
but mine" is in-scope for ssp, but I'd have to be convinced since
its not at all apparent to me now that that's a useful thing to
say.

(Note: that's not a WG-chair statement, just how I understand
this at first glance.)

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Aug 2006 14:01:22 -0400

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

> I believe that the basic disconnect here is that the protocol
> "protects" anything.  The running assumption that I've seen the
> most support for is that the protocol *informs" other entities
> of the way the domain behaves, and the protocol  consumer
> information to "protect" their incoming mail feed. Thus
> requirements that presumes that the sender knows the mail
> transit topology seem rather incongruous with an

I agree Mike, But I don't think there has been any suggestion, not in SSP,
not in DSAP and definitely not by me, to suggest a signer has control of
verifier local policies.  However, I would suggest it its in the best
interest of both parties that each are consistent with the protocol
expectations.  The verifier does not want to receive junk as much as the
signer doesn't want the verifier to get unauthorized domain mail.

To me, DKIM-BASE defines your 1st vs. 3rd policy requirements and there is
fix limited number of them based on the possible 1st vs. 3rd party
arrangements.

There are 10 of them.  These 10 policies defined in DSAP has covered every
discussion so far required 1st vs. 3rd party.  It would be seem to me that
these 10 policies be analyzed and to determine if we want to water them down
because they don't fit some requirement.

Unless I missed some, there are only 10 possible policies:

   o  Original Party Signatures (OP)

      *  never expected
      *  always expected
      *  optional

   o  3rd Party Signatures (3P)

      *  never expected
      *  always expected
      *  optional

 When the two signature types are combines, the possible policies are
 listed in this following table:

 +=================================================================+
 | op=         | 3p=        | Domain Policy Semantics              |
 |=================================================================|
 | empty       | empty      | No mail expected                     |
 |-----------------------------------------------------------------|
 | never       | never      | No signing expected                  |
 | never       | always     | Only 3P signing expected             |
 | never       | optional   | Only 3P signing optional             |
 |-----------------------------------------------------------------|
 | always      | never      | OP signature expected                |
 | always      | always     | Both parties expected                |
 | always      | optional   | OP expected, 3P may sign             |
 |-----------------------------------------------------------------|
 | optional    | never      | Only OP signing expected             |
 | optional    | always     | OP expected, 3P expected             |
 | optional    | optional   | Both parties may sign.               |
 +-----------------------------------------------------------------+

Again, some of these may not make sense and we can water it down to fit some
"real life" requirements.  But you can't generate anything more than the
above.  The above are the SSP Axioms.

Anyway, that's what I think.

---

From: John Levine <[email-masked]>
Date: 1 Aug 2006 13:57:01 -0000

>> is if B added content, what to do about that, I'm not sure.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Aug 2006 12:27:56 -0700

Michael Thomas wrote:
> anything. The running assumption that I've seen the most support for is that
> the protocol *informs" other entities of the way the domain behaves, and the
> protocol consumer may or may not use that information in conjunction with
> other information to "protect" their incoming mail feed. 

I like your phrasing quite a lot.  I think it describes what DKIM does and does
not do quite well.

d/
-- 

  Dave Crocker

---

From: Damon <[email-masked]>
Date: Tue, 1 Aug 2006 15:45:35 -0400

I have a German Shepard, his purpose was not for protection but for
companionship.
Never once did I tell the pet store that I wanted a guard dog or that I
needed a pet for protection.
The really amazing thing is that... even though I did not specify it in any
way - he will keep you out of my house.
 I think if it is useful in "protecting", regardless of how it was intended
or mandated, it will be used that way. Unless you specifically design the
inherent protection out of it.

Regards,
Damon Sauer

---

From: <[email-masked]>
Date: Tue, 1 Aug 2006 22:11:00 -0400

All,

As an ISP there are 2 things I will require to implement SSP or another
DKIM policy methodology

A. I only sign 3rd party

B. I sign exclusively any other sigs make mine broken

There can be other policies but I require those two and am wondering why
there seems to be a tremendous pushback on this. 

Thanks,

Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Aug 2006 22:47:58 -0400

----- Original Message -----
From: <[email-masked]>

> There can be other policies but I require those two and am
> wondering why there seems to be a tremendous pushback on this.

+1.

I do have these points though:

For the "A. I only sign 3rd party" policy:

In the SSP draft, there is no semantics for this type of 3rd party policy.

The DSAP draft, provides all policy types, including this one:

    OP=NEVER; 3P=ALWAYS

However, and this probably needs you to confirm what you mean depending if
your ISP business is hosting local domains, are you going to allow other
locally hosted domains signed mail as well?

If so, then it would seem to me that your operations policy will dictate
that your hosted local domains would have to define an OP=ALWAYS policy with
thier own DSAP record.

For example, you are hosting ABC.COM for us, based on your operation always
signing outbound mail,  if I wanted to always signed mail with Doug's new
MUA DKIM plug-ins, then I would have to create (or you create) a DSAP policy
of:

     OP=ALWAYS; 3P=ALWAYS;

But in general, because you always sign the outbound mail regardless of the
hosted domain policy, you would have to instruct/setup your customers to
have one of the following:

     OP=NEVER; 3P=ALWAYS;
     OP=ALWAYS; 3P=ALWAYS;
     OP=OPTIONAL; 3P=ALWAYS;

The DKIM-DSAP verifier will honor all these conditions.

Make sense?

---

From: <[email-masked]>
Date: Tue, 1 Aug 2006 23:08:47 -0400

If I understand this right, a local domain that relays thru my 3rd party
MTA may have its own signing policy. I then sign as 3rd party, an ssp
lookup on example.com sees the third party only policy and also a
foo.example.com shows a relaxed signing policy. Both sigs decrypt as
valid. That is a good receiver policy indicator.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: Hector Santos [mailto:[email-masked]] 
Sent: Tuesday, August 01, 2006 10:48 PM
To: Oxley, Bill (CCI-Atlanta); [email-masked]
Subject: Re: [ietf-dkim] A few SSP axioms

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

+1.

In the SSP draft, there is no semantics for this type of 3rd party
policy.

    OP=NEVER; 3P=ALWAYS

However, and this probably needs you to confirm what you mean depending
if
your ISP business is hosting local domains, are you going to allow other
locally hosted domains signed mail as well?

If so, then it would seem to me that your operations policy will dictate
that your hosted local domains would have to define an OP=ALWAYS policy
with
thier own DSAP record.

For example, you are hosting ABC.COM for us, based on your operation
always
signing outbound mail,  if I wanted to always signed mail with Doug's
new
MUA DKIM plug-ins, then I would have to create (or you create) a DSAP
policy
of:

     OP=ALWAYS; 3P=ALWAYS;

But in general, because you always sign the outbound mail regardless of
the
hosted domain policy, you would have to instruct/setup your customers to
have one of the following:

     OP=NEVER; 3P=ALWAYS;
     OP=ALWAYS; 3P=ALWAYS;
     OP=OPTIONAL; 3P=ALWAYS;

Make sense?

---

From: John Levine <[email-masked]>
Date: 2 Aug 2006 03:30:50 -0000

>there seems to be a tremendous pushback on this. 

You must have a very different model of SSP use from the rest of us.

Neither of these assertions are useful to a recipient, so there's no
point in publishing either for recipients to look up.  You really need
to provide some concrete scenarios that show how receivers will use
your policy info to manage their mail processing.

>A. I only sign 3rd party

Scenario A1: message from you arrives with no signature, or with
someone else's signature.  What would a recipient do with this SSP
info?  How would it differ from what the recipient would do anyway?
It wouldn't.

Scenario A2: message from you arrives with your signature.  We now know
that your SSP is wrong, which is not interesting to anyone other than
you. Same question, how would a recipient's mail handling change with
this SSP info?

Scenario A3: message from someone else arrives with your signature.
Same question again, how would a recipient's mail handling change with
this SSP info?

>B. I sign exclusively any other sigs make mine broken

This one's simple, we don't believe you.  

My wife gets all her mail relayed through an alumni account at
Cornell, and at some point Cornell will sign the mail they relay as it
passes through.  So we're going to accept lots of mail with Cornell
signatures, and if you insist that we not do so, all you will
accomplish is to persuade us that that you are being silly.  If a
message has your signature, it's your message.  If it also has a
hundred other signatures, it's still your message.

If you disagree, you really have to provide a concrete scenario where
an added signature turns a valid message into an invalid one, keeping
in mind that the existing message headers and the messge body did not
change at all, since the original signature is still good.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 12:29:55 +0100

> change at all, since the original signature is still good.

Sorry to keep hammering on about this, but I'd really like to see this
answered. So far it hasn't been and I believe the WG wouldn't be wise
to adopt requirements where we've only got claims of utility but no
demonstrations of utility.

S.

PS: Just wondering. Is this a case where people are thinking that
just because a signature is a positive thing, that there must exist
a meaningful opposite - an anti-signature or something? Well, this
isn't particle physics (luckily!) and afaik there is no such
construct as a negative signature. (Yes a signature can be over a
negative statement, but DKIM-base signatures sign mail, not policy
assertions.) So a policy/practice statement that even implies that
some signatures are anti-signatures makes no sense. (At least in
my Universe:-)

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Aug 2006 08:22:42 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "John Levine" <[email-masked]>

> demonstrations of utility.

The demonstation of utility is a digital mail signature model based on some
c14n and hashing of mail - a concept that deals directly with mail integrity
issues.

John wants to know how a 2nd signature could invalid an already valid
message.  This is really based on a "Good Citizen" model where everything is
done correctly.

He prepared all process conditions so that there is no integrity issues. So
no harm is done.  Everything works fine.

But what happens when all or some conditions are not set?  There is a change
in the body? The original signature was stripped?  Or just about anything we
don't know, but the OA did not expect any of this to happen?

Thats the challenge here.

> a meaningful opposite - an anti-signature or something?

HA! <g>

Why not try the reverse the question? Show when it doesn't cause in harm?
John told us. When the universe is perfect. :-)

> Well, this

The "grass" is indeed greener over the pond. <g>

The perfect DKIM universe is wonderful. I think  this is why people are
excited about. The potential is high for success among all parties, the
small and the large, the ISP, ESP and the users, etc.

But in my view, the perfect DKIM universe is not reality. There are going to
be attempt to break john's perfect message scenario.

If we have history to work with here, there is a strong indication that the
DKIM universe will not always be perfect.

The question is how do you handle imperfection. Is it worth handling it?

So as you know, for me, DSAP was done as a concern about the security
concerns of the core DKIM-BASE protocol when the universe is not so perfect:

  "The main objective of DSAP is to establish a
  protocol consistency between all client types and to use the
  deviation from the consistency as part of a failure detection system."

I think that trying to define requirements does requires an understanding of
what the signature security concerns for DKIM-BASE protocol.  It begins
there, in my view.  What are the possible signature security problems?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 14:09:08 +0100

Hector,

Yet another claim of utility with no demonstration!

I do agree that we have to cater for an imperfect world,
but you have yet to demonstrate a case where that makes
it bad to add signatures to a signed message (from a
bank or whatever).

Why don't you(*) just show me the benefit? If its because
you think this should be useful but aren't sure exactly
how, then that's fine, just say so and the WG can take
that into account when evaluating which requirements to
adopt.

(*) By "you" I don't mean just you personally, but all
the folks on the list that are arguing for this.

Cheers,
S.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Aug 2006 10:00:48 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> Yet another claim of utility with no demonstration!

Are we referring to a "useful scenario?"  Does it matter if is past or
preesent?

As far as I am concern until all this is proven, it is all claims

What seens to be the most common difference here is one side says that
secondary signatures causes no harm.  Isn't that a claim?  Where is the
demostration that it does not?  The other side says "We don't expect anyone
to message with mail."  You're asking for demo as to why it useful.

I just having a hard time understanding what is fundamental difference.

Lets use John's example:

   My wife gets all her mail relayed through an alumni
   account at cornell, and at some point Cornell will sign
   the mail they relay as it passes through.  So we're
   going to accept lots of mail with Cornell signatures,
   and if you insist that we not do so, all you will
   accomplish is to persuade us that that you are being silly.
   If a message has your signature, it's your message.  If it
   also has a hundred other signatures, it's still your message.

Is this is demonstration or a claim?  Until he can proven that there is no
harm in this process, it is claim.  There is no demontration that there is
no harm here.

Now, the point i am saying is that is more risky. How much? Don't know, but
certainly more than an expectation not having multiple signatures.  So if a
domain does not want them, why the push back to avoid this policy?  I don't
get it.

> it bad to add signatures to a signed message (from a

I believe I have Stephen.  I think its just a matter of difference of
opinion in usefulness.

I didn't say it makes it bad, what I said, that it may be desirable by a
domain, including myself as a developer and consumer of such mail goods, to
have 100% exclusivity in my mail transactions.

Is the disagreement is that this desirability is unrealistic?

> Why don't you(*) just show me the benefit?

In all honesty, and hang in there with me because there is certainly people
who agree with this because for some odd reasons choose to only say it to
me, and not in public, we don't understand the "push back" or what is so
hard to grasp about a domain wanting to have full control of his domain and
his mail is moving thru the system.

There is a very fundamental practice in SMTP operations to minimize any mail
tampering. There is very limit exceptions to this and you can count them in
your hand where are current useful applications that mail break mail
integrity (i.e. List Server).

Digital signatures has inherent understanding of integrity. So if a domain
"chooses" to prepare his transactions with with a desire that the mail is
not touched or worked on, why we would be so resistence to this?

Is it because we don't believe it will work?  I mean, if this is the reason,
then that means exclusive policies fails on its technical merits and if that
is the case, then we kill it and move on.

But if its not a concept that fails on its technical merits, there are a few
of us that believe exclusive policies "can" be very useful.

> If its because you think this should be useful but aren't
> sure exactly how, then that's fine, just say so and the WG
> can take that into account when evaluating which requirements to
> adopt.

I don't have a problem understanding its usefulness, Stephen. Not at all. In
fact, I stated since day one, since the old list, how exclusive signing
options is very restrictive and deemed highly useful for domains what
require that level of consideration.

If I posted DSAP description for exclusive policy, is this still a claim or
demonstation? (Note: I did not write this section. 3rd party input)

5.5.  Only Original Party Signature Expected

   *Policy: op=always; 3p=never;*

   If this policy is defined, then a DKIM signature MUST exist and it
   must be signed by the original domain only.  If no signature is found
   or a 3rd party signature is found, the verifier SHOULD honor the
   domain policy request to negatively classify the message.

   This policy is considered to be an exclusive signing practice by the
   original domain only and is expected to be used by organizations that
   never send any email to mail lists or through 3rd parties and always
   expect to communicate directly with recipient.  Such organizations
   are those providing data of very sensitive nature (such as personal
   financial information) and using strong internal security policies.
   These organizations are often highly concerned about inappropriate
   and fraudulent uses of their domain (such as cases of "phishing") and
   want to make sure that only emails directly from their system are
   accepted as valid by recipient.

   Here is an example of such policy record used by an imaginary Bank
   with domain bank.example.  Please note tags are separate per line for
   illustrative purposes only:

   _dsap._domainkey.bank.example.  IN TXT
         "v=dsap1.0; a=rsa-sha256; op=always; 3p=never;
          n=We only send DKIM signed email, do not trust anything else
            such as notices allegedly from [email-masked]. Please
            report all such abuse to;
          r=[email-masked];"

   Note: The above comment in "n" tag is very long and given only to
   help illustrate this example.  Whenever possible shorter text should
   be used in DSAP records.

Again, the technology doesn't exist yet. It is still vaporware. So I can
image it being labeled as a claim of usefulness with no real demonstration
of usefulness.  All semantics, but it isn't very hard for some of us to see
the real practical usefulness of this strong policy. I didn't write the
above.

PS: Maybe it would be a good idea for the WG to officially announce the
availability of the DSAP I-D draft.

---

From: John L <[email-masked]>
Date: Wed, 2 Aug 2006 10:51:50 -0400 (EDT)

> message.  This is really based on a "Good Citizen" model where everything is

Actually, it's based on the model in draft-ietf-dkim-base-04.txt.

As always, concrete scenarios would be a great help to understand the 
problems you believe exist.  In particular, a concrete example of a second 
signature invalidating a message without breaking the first signature 
would be extremely useful since it would point out a major flaw in 
dkim-base that nobody else is aware of.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 17:31:16 +0100

> availability of the DSAP I-D draft.

Sure. But since of course its not an official WG document I'm
only informally announcing it here:-)

Hector's written up an individual submission with his ideas
on how an ssp-like thing might work. Its at [1] and, as an individual
submission is something the WG might, or might not, adopt in whole or
in part, once we've gotten done with requirements. (And thanks for
taking the time to do that Hector.)

People can always check the full list of dkim-related I-Ds using
the I-D tracker [2]. Generally (and currently) only those whose
names start with draft-ietf-dkim and which are not expired
are the "official" WG documents (which are also linked from the
DKIM charter page [3]).

Stephen.

[1] http://www.ietf.org/internet-drafts/draft-santos-dkim-dsap-00.txt
[2] 
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=dkim&search_rfcnumber=&search_area_acronym=&search_button=SEARCH

[3] http://www.ietf.org/html.charters/dkim-charter.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 17:39:26 +0100

Hector,

I don't plan to engage in verbal jousting about what's a claim
vs. what's a demonstration. I've seen use-cases that satisfy me
about the utility of e.g. the "I always sign everything" statement,
(and some variants) but I've not seen anything I find at all
convincing for the "I want my stuff signed only be me" statement
(and variants).

Others may of course disagree and we'll establish what the WG
thinks over the next weeks/month-or-so. (But there's no need for
us to debate what I think about what I've read:-)

Hector Santos wrote:
>    ...and

Aha! Possible sound of penny dropping...

Is it a mail routing policy you want to express and nothing
except incidentally to do with signatures? That may be entirely
reasonable, but is IMO at least reasonably likely to fall outside
the scope of SSP (on the basis that it says nothing about
signatures, same as "I send no mail").

Stephen.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 02 Aug 2006 12:54:26 -0400

Once nice thing about the IETF Tools WG page
http://tools.ietf.org/wg/dkim/ is that it lists both Official working
group and "Related active" documents. To be included in the latter list,
you just need to include "-dkim-" somewhere in the I-D name.

	Tony Hansen
	[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Aug 2006 14:19:39 -0400

----- Original Message -----
From: "John L" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> message.  This is really based on a "Good Citizen" model where
>> everything is done correctly.
>

First, this is why I suggested the requirement: SSP Must Follow DKIM-BASE,
because there is going to be alot of revisiting here based on what
requirements are set or excluded.

Second, I don't think you can find an example because you provided a perfect
scenario where everything was done right with a mindset where we have a very
loose interpretation of multiple signatures.

Third, Not so John.  Many were aware of the multiple signature issues. You
probably missed this discussions.

Eric, Jim, myself and others, were very aware of the problems because it was
discussed in quite detail that help shape the loose semantics of Multiple
Signatures as altered in base-01.  The semantics were changed because of the
vague issues of multiple signatures.

In base-04 it says:

   4.  Semantics of Multiple Signatures

   ...

   Signers should be cognizant that signing DKIM-Signature headers may
   result in signature failures with intermediaries that do not
   recognize that DKIM-Signatures are trace headers and unwittingly
   reorder them.

It also says:

   ..... As with messages with a single signature,
   verifiers are at liberty to use the presence of valid signatures as
   an input to local policy; likewise, the interpretation of multiple
   valid signatures in combination is a local policy decision of the
   verifier.

Do we have a consistent set of local policies for everyone?

I also had a problem with this statement:

   Signers SHOULD NOT remove any DKIM-Signature header fields from
   messages they are signing, even if they know that the signatures
   cannot be verified.

Because this prohibits (limits) the list server from having fun in the DKIM
sand box. It didn't help my list server change designs. It makes things
harder and to ignore it does not help address survibility issues.

But it is also flawed because it presents a high potential for failure for
the verifier to question.  This we can demonstrate with Domainkeys in the
wild. Nearly all of this coming from what seem to be mailing list, fail.

You really need to read that interesting thread where multi-sigs discussed
in quite detailed with pseudo-code illustrations.

Also consider this:

6.1  Extract Signatures from the Message

   A verifier SHOULD NOT treat a message that has one or more bad
   signatures and no good signatures differently from a message with no
   signature at all; such treatment is a matter of local policy and is
   beyond the scope of this document.

   When a signature successfully verifies, a verifier will either stop
   processing or attempt to verify any other signatures, at the
   discretion of the implementation.

Again, Local policies questions.  No clear behavior on how to handle
multiple signatures and its possble failures.

John, the whole point here is that you presented the result where the
message was 'perfect' but it was based on ignoring if the 2nd signer itself
violated any SSP policy.  Was it suppose to resign?

Excluding the possibility of exclusivity to help define policies that local
system may follow in order to help and/or increase the survibility of the
DKIM signed message is not a very good idea.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Aug 2006 14:37:26 -0400

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

> signatures, same as "I send no mail").

Hmmmmmm, unknown router and transient issues wasn't obvious?

Having 2nd or more signatures implies there are middle wares in the picture.

Interesting, I guess if we want to cover all grounds:

 1) Define policies all compliant software on path from Point A to Point Z
    to follow (which is what I was hoping to model),

 2) To maybe a new consideration that would alter the routing behavior
    of a compliant DKIM-SSP MTA.  DKIM-Least-Resistance-Path?

I guess, if an implementation performing #2 is what it takes for the
compliant software in order to increase the survivability of the message,
than
I guess that is ok.

That might be what is needed for optimal survivability - reduce transport
path.

But overall, I was shooting for a protocol that everyone will follow, even
for multiple hop situations.

No, I don't have a interest in debating semantics of claims vs. demos, but
someone has to speak up for SSP concepts publicly!!!  No one said it was
going to be an easy solution, and hopefully major benefits will emerge once
we get over the "Who moved my cheese?" syndrome. <g>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 19:47:28 +0100

> Hmmmmmm, unknown router and transient issues wasn't obvious?

It wasn't obvious that that was your concern. And if it is
your concern then I guess you never meant that the additional
signature was a negative, you were saying that any additional
trace field is a negative - a statement that has nothing much
to do with crypto.

> Having 2nd or more signatures implies there are middle wares in the picture.

So would a bunch of Received headers though, wouldn't they?
What's special about DKIM-Signature fields that you want to
control their numbers but not other trace headers?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 20:23:22 +0100

Damon wrote:
> Does the DKIM verifier give a hoot about the other Recieved headers?

No (Assuming they're not signed, and the signer didn't prevent their
addition using the existing scheme in base.)

But so far verifiers don't care about whether there're one or two
or however many signatures either. My question was why additional
signatures are seen as so bad that you want to tell the verifier
to dislike them, but other trace headers are not bad enough to
need that.

Basically, my concern is that this is extending SSP to cover
something (mail routing) that's not really part of DKIM.

Stephen.

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 15:36:32 -0400

> to dislike them, but other trace headers are not bad enough to

As the sender whom signed the message, I want to tell the receiver to trust
mine and ignore (or dislike) the rest. I don't want anyone else to sign in
my place if I am the one signing.
Right? (forgive me I have just been able to follow the DKIM list as of very
lately.)

> something (mail routing) that's not really part of DKIM.

I think the danger is in explicitly saying so. If it has an added benefit, I
wouldn't be trying to avoid bettering the inherent benefits if it does no
harm to the base.

Stephen.

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 15:53:43 -0400

On 8/2/06, Stephen Farrell <[email-masked]> wrote:
>
>
>
> Damon wrote:
> > As the sender whom signed the message, I want to tell the receiver to
> > trust mine and ignore (or dislike) the rest. I don't want anyone else to
> > sign in my place if I am the one signing.
> > Right?
>
> That's exactly where we started:-) Some people (incl. me) don't
> see any benefit in disliking additional signatures. (And of course
> there's no point is telling a receiver to trust you:-)

Then why have mulitple sigs at all. Stop at the first signer.
If there are multiple then I would want to dislike them... even treat them
with higher scores.

Regards,
Damon

---

From: Michael Thomas <[email-masked]>
Date: Wed, 02 Aug 2006 13:11:38 -0700

Damon wrote:

> On 8/2/06, *Stephen Farrell* <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     Damon wrote:

We're not talking about people signing in an unauthorized way. DKIM
allows signatures to be appended which are not necessarily on behalf
of the 2822.from domain. In fact, it's only SSP that makes a correlation
between 2822.from and the signature. So the mere fact that there's more
than one signature is nothing to be alarmed about.

> If there are multiple then I would want to dislike them... even treat 
> them with higher scores.

I think you two are talking past each other. There's nothing inherently
suspicious in the mail architecture about relays, which is what this all
really boils down to. Trying to judge the topological route a message
will take from the standpoint of the sender is a risky if not futile 
endevor.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 2 Aug 2006 16:59:19 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
Sent: Wednesday, August 02, 2006 2:47 PM
Subject: Re: [ietf-dkim] A few SSP axioms

> trace field is a negative - a statement that has nothing much

I think we might clearer now, but I do want to say so,  I have consistently
held the position since day one, that exclusivity offers among the highest
level of protection for local domain policies.  It was the same position I
held during SPF development.   As easily predicted, the neutral or relaxed
SPF policies was empirically shown to be abusive and more and sites are
using exclusive (hard pass/fail) policies along with argument forwarding
solutions.

DKIM was attractive because it offered a way to resolve the IP forwarding
problem and also offer strong, exclusive policies.  So since day one, I
repeated the same mantra here, with no reason to believe history will not
repeat itself:

      DKIM relax policies are weaker than exclusive policies

and thus are the most exploitable policies.

But what DKIM also had was SSP in its initial proof of concept and it helped
to resolve many of the exploitations possible.  Unfortunately, it
deemphasized, and now watered down. :-(  Hopefully, it will all work out.

So if we want to bring this back to need for Exclusivity, only a technical
merit question that can be brought up is level of survivability.

Look at it this way: We have the multiple policies just like we have
multiple c14 methods; one is stronger with less survivability, and one is
weaker with higher survivability.

Its the same concept.

Anyway, I think if we exclude this policy, it weakens the possibilities for
DKIM.

Enuf with this. :-)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Aug 2006 15:31:06 -0700

On Aug 2, 2006, at 1:59 PM, Hector Santos wrote:

>
> DKIM was attractive because it offered a way to resolve the IP  
> forwarding problem and also offer strong, exclusive policies.  So  
> since day one, I repeated the same mantra here, with no reason to  
> believe history will not repeat itself:
>

I do not agree.  It really depends how DKIM is used.  When DKIM is  
used as a means of recognition, where policy provides information  
related to what is "authoritative", then those messages that are not  
recognized will receive appropriate levels of scrutiny.  DKIM can not  
prevent someone from sending unsolicited bulk email using their  
"domain of the day" from a list of previously owned domains acquired  
years ago.

Those wanting to send in bulk will attempt to publish policy that  
they expect will make them appear reputable.  An abusive sender of  
bulk email will not care whether these policies break common  
services, such as mailing lists.  While there are exceptional cases  
where transactional messages in commerce are being heavily phished,  
an expectation that exclusive policies will halt phishing is  
unfortunately flawed, as noted in the Threat draft. : (

The retention of authoritative DKIM information at the MUA can be  
used to apply annotations that will meet the expectations of  
effectively thwarting the current spat of phishing attacks, without  
breaking common services or relying upon reputation services. : )

When email is used to send more than just bulk messages, claims of  
exclusivity remain problematic.  Unlike SPF, a non-exclusive policy  
will not change an invalid into a valid signature.   While it may be  
true there was a shift in the population of "exclusive" SPF records,  
this likely relates to how these records are now being used.  AOL  
required these records for white-listing of bulk senders.  Worried  
about other clients impinging upon their reputation, exclusivity  
blocks other clients from also referencing their white-listed  
records.  This exclusivity however has a significant downside, just  
as it does for DKIM, even though with different services.

Here a possible cause for the drop of adoption has been attributed to  
problems created by exclusive records:
http://hxr.us/blojsom/blog/grumpops/computers/anti-spam/? 
permalink=SPF_Adoption_Nosedives.txt

Authoritative information will allow broader adoption of DKIM with  
simpler autonomous management schemes.  Exclusivity assertions will  
likely represent a short-term stop-gap measure.  Not asserting  
exclusivity by those being phished likely depends upon greater  
adoption of MUAs intelligently making use of DKIM related  
information.  This stop-gap measure, if nothing more than to prove  
its eventual futility, should be just a flag that claims exclusive  
use of designated signing domains.  The other setting in your scheme  
seem overly complex and unnecessary.

-Doug

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 15:16:14 -0400

Damon

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 20:47:28 +0100

Closest I've come to understanding this is where Hector said he
wanted to place restrictions on the route the message takes (e.g.
in terms of number of hops or signatures or maybe even something
else) which may be reasonable but is arguably not for the DKIM
verifier.

S.