-----Original Message-----
From: dkim-ops-bounces(_at_)mipassoc(_dot_)org
[mailto:dkim-ops-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Monday, September 13, 2010 2:56 PM
To: dkim-ops(_at_)mipassoc(_dot_)org
Subject: Re: [dkim-ops] hammering with a soldering iron, was subdomain vs.
cousin domain
Has that been shown yet to be important at receivers? Are
there any current implementations with data to show that this
is a useful thing to track?
I'm happy to believe that it is important, but so far all I've
seen is a lot of argument over theory and not much real data.
What more data do you need about who is the signer?
I know who the signer is, but that's the wrong question. The question is: Does
anyone actually care if the "d=" domain and the From: domain don't match? That
is, have people implemented systems that check that and then take action? If
so, how have those data been applied to filtering? Is it fairly accurate for
identifying suspect content that should be handled specially?
There are all kinds of theories floating around that people should check,
people should care, it should make a difference, there should be a way to
confer authorization, people want this. But they're theories. There's no data
yet (that I've seen). That's really the best way to justify the work.
I'm hoping to do those correlations with OpenDKIM's stats results, but I'd like
to get more reporter feeding us data before I can make any assertions.
In this particular
fiber, you described a DNS provisioning regarding authorizing a 3rd
party signer creating a 1st party signature (5322.from == DKIM.d).
According the 4871, the Signer is the "responsible" domain and 4871bis
is trying very hard to break the author domain association.
I'm saying that's what RFC4871 directly supports, yes.
Actually engineering intuition was all that is needed.
That's not data, and obviously from the traffic on all the DKIM lists lately,
that intuition is not universal.
http://blogs.cisco.com/news/comments/growth_in_dkim_signing_continues
As DKIM deployment grows, so does the ability to use signatures as
the basis for domain-based reputation. This is a double-
edged sword: a good reputation can enhance deliverability, but
domains that send (and sign) messages that are considered
undesirable by recipients can quickly tarnish that reputation and
have much the opposite effect
How does this say anything at all about third-party signatures and whether
they're better or not? And of what, specifically, is this evidence?
Dkim-reputation.org has an extensive writing on the negatives as well.
http://www.dkim-reputation.org/mission/
[...]
That's one implementation with an admittedly small data set. Do you take it as
gospel?
Do you think this is indeterminate enough?
I sure do, and that's the problem.
RFC 4871 was considered by many fast tracked and rubber stamped
without any real supportive data. We all know why too, but it
certainly wasn't for the betterment for network wide adoption. It had
very limited scope with a morphing of out of scope unproven wide
reputation model, including allowing list operations to diminish the
proof of concepts with Policy.
Hmm. I must've been in a different working group than you.
We don't need more DATA to see there is a problem and a wide spread of
indeterminate situations. Engineering intuition tells us we need a
solid deterministic backbone design and protocol protection layer for
DKIM again, and let the rest be based on that.
My own engineering intuition is that it's foolhardy to proceed toward
specification, design and implementation without predicating it on something
that has been observed to (a) actually work, (b) actually provide a useful
result, and (c) actually scale.
Have you (or has anyone) coded up DSAP, TPA or something else and run it in
production between even a tiny set of independent senders and receivers thus
demonstrating the value of such systems? If so, where's that data?
DKIM had that in the form of several implementations that were operating and
evolving as the specifications evolved. We had data about what worked at the
time, even though the full-blown interoperability event came a little later.
These other things don't have that, and ADSP never went through that sort of
rigor either.
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops