Re: [ietf-dkim] Reading the entrails, was Moving to consensus

John,

I think you are mixing up various models of Black/White listing.

The one we are familar with and the one widely used een when many are
not 100% happy with it is the 3rd party Lookup IP Black List - DNSRBL.

Here, many have put their trust in a 3rd party negative reputation
assessment.  Currently this is based on IP - an inherent anchor
(input)  that is always there.  DNSRBL is, like it or not, a BCP many
use - a pseudo standard.

For white list, thus far there is no wide adoption for a 3rd party
assessment and even if there was, trusting a 3rd party good reputation
assessment is hard to accept. Even if someone was going to trust a 3rd
party assessment, the problem here, is what "anchor" or data do you
pass to the 3rd party to evaluate it.

WIth DKIM, its a different model. Now we have extra potential
information to pass to an 3rd party assessor.

However, to me, the "disconnect" to me, is at the fundamental protocol
consistency level.

You want to make this purely a WHITE LIST concept.   However, DKIM
whitelisting idea would be fundamentally inconsistent if the opposite
is not considred.

In other words, if this extra information is now used for Good
Reputation Assessment, then to ignore the condition when the extra
information is not there, it would create a loophole and high
potential to further confuse users.

Just consider, if having no extra information in the mail is not
important, when it is expected to be there by the domain, then without
a doubt, the bad guys will have a special solution to DKIM - don't
bother to sign or fake it because non-compliant DKIM mail will is
ignored.

It all goes back to Whats Expected by verifiers when they sees a DKIM
signature or lack there of.   You simply can not look for only the
golden needle (good signatures) in a hay stack of abusive mail,
finding two messages with the same domain, one is signed the other is
not and then treat the signed with some higher classificaton while
doing nothing about the unsigned.

To me, it is illogical from an engineering standpoint to ignore
failure.  It runs the risk of creating a confusing consideration for
users.

This mail is ok because it was signed, valid and stamped.  What do I
do when mail is received from the same author but its not signed or
worst, signed and broken?  I'm afraid the user will learn to ignore
the whole ieda and thats defeats the purpose of DKIM in my opinion.

While it may help DMA people who want to white list their
distributions with DKIM to help push the mail to users,  they need to
also understand that fraud from the same domains can't be ignore under
the same DKIM considerations.   The DMA might not care about that.
But the DOMAIN owner will.









On 3/23/09, John R. Levine <johnl(_at_)iecc(_dot_)com> wrote:
> > > I see no benefit whatsoever in using DKIM for blacklists.  But we need
> > > to be careful to avoid automatically carrying the habits of blacklist
> > > filtering into whitelist filtering.
> > This on its face seems like a very fair statement, and I agree with you
> > that
> > we clearly have been living in a blacklist world.  But I am not convinced
> > that there is a white list world out there at this time.  There are too
> > many
> > virii and too many vulnerabilities to flip a good guy to a bad guy
> > extremely
> > quickly.
> You're quite right that we're unlikely to have static whitelists any time
> soon.  But I was thinking more of simple questions like "is this message
> whitelisted" versus "is this message blacklisted?"
>
> Since bad guys are trying to disguise their identities to dodge
> blacklists, blacklisting is necessarily fuzzy and heuristic, along the
> lines of Spamassassin, and even yes/no blacklists like DNSBLs have
> heuristics about how big an IP range to list if you see a cluster of
> reports from a group of IPs.
>
> But good guys want you to recognize them, so if we offer clear
> instructions to make a message meet whitelisting rules, senders will
> follow them.  The more options they have, the less clear it is what to do,
> and the more work everyone's going to have to do to sort out the results.
>
> The reason that l= was a bad idea is that it changes the answer to the
> question of whether a message is signed from "yes" to "sort of".  The less
> sort-of, the better.
>
> R's,
> John
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html

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