[ietf-dkim] Re: Collection of use cases for SSP requirements

[Hector Santos]

My 2 cents:

The first thing that needs to be work out which is what I find fundamentally 
flawed in DKIM is that idea of separating VALID vs NON-VALID conditions.

The fundamental idea is simple:

   - No Good system is will have NON-VALID conditions!

By GOOD I don't mean reputation.  I mean operations wise - it is the FIRST 
condition that must be met.    Violate this and you must as well throw DKIM 
into the waste basket - "with full force."

All rules or any applied FUZZY logic, including repuation must be based on 
this.

Otherwise, you get into nonsense ideas that a GOOD system MAY infact have 
invalid conditions and you might as well OVERRIDE this with some other 
undefined, non-standard processing.  At that point, we are back to square 
one where there is no consistency nor expectation for consistency.  It 
doesn't matter what DKIM says.  Something else will override it.

In any case, I am not too excited any more with the direction DKIM has taken 
with placing hope on Reputations systems to solve its issues.  Its defeats 
the purpose in my view.

---
HLS



----- Original Message ----- 
From: "Douglas Otis" <dotis at mail-abuse.org>
To: "Charles Lindsey" <chl at clerew.man.ac.uk>
Cc: <ietf-dkim at mipassoc.org>
Sent: Friday, November 17, 2006 4:44 PM
Subject: Re: [ietf-dkim] Re: Collection of use cases for SSP requirements


>
> On Nov 17, 2006, at 1:16 PM, Charles Lindsey wrote:
>
>> Reputation information cannot come from SSP. All SSP can tell you  is 
>> what the owner of each domain chooses to tell you. Reputation 
>> information will come from third parties, so you have to decide  which 
>> third parties to believe.
>
> Reputation, good or bad, can not come from the DKIM signature either.
>
> DKIM only indicates who signed the content of the message, not who 
> addressed the envelope and sent the message.  Reputation information 
> seldom depends upon the message's content for asserting a bad  reputation. 
> Only when the content is perhaps criminal in nature  could content alone 
> provide enough information for asserting a  negative reputation.  A good 
> reputation is equally problematic.   Reporting that example.com has a 
> "good" reputation will likely invite  spammers to this domain.  Spammers 
> would then send themselves  messages signed by example.com.  These 
> messages can then be  immediately replayed from all parts unknown.  Saying 
> anything bad  about a domain will be problematic, as will saying anything 
> good.
>
> Being able to associate the signing domain with that of the SMTP  client 
> safely allows white-listing which protects the "good"  assertion from 
> being abused.  This technique could also be used to  associate the various 
> email-address fields with that of the signing  domain as well.  An 
> association technique would allow email-address  domain owners to freely 
> select their providers.  Domain owners would  not need to coordinate the 
> exchange of private keys, zone  delegations, or allowing them to create 
> your private keys and  referencing their public key using a CNAME record. 
> The providers  would also have abuse feedback directed to them.
>
> Security is improved by providing an association scheme. The cost of  the 
> email service is reduced, and there would be greater consumer  freedom. 
> The converse of sharing your domain zone or provide keys  with these 
> providers does not enhance anyone's freedom.  A message  signed by a large 
> domain is no better than that signed by a smaller  domain.  When a smaller 
> domain is known to be good, the smaller  domain has the advantage. 
> Clearly allowing signing domain  designation would be beneficial to the 
> smaller entities.
>
> -Doug
>
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>