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(_dot_)org>
To: "Charles Lindsey" <chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html