ietf-dkim
[Top] [All Lists]

[ietf-dkim] Reputation vs SSP

2006-09-11 22:17:30
----- Original Message -----
From: "Steve Atkins" <steve(_at_)blighty(_dot_)com>

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

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.

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.

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





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

<Prev in Thread] Current Thread [Next in Thread>