[ietf-dkim] Re: Collection of use cases for SSP requirements
hsantos at santronics.com
Fri Nov 17 14:14:07 PST 2006
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
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.
----- 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
> 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.
> NOTE WELL: This list operates according to
More information about the ietf-dkim