> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Hector Santos > Sent: Monday, September 13, 2010 2:56 PM > To: [email protected] > 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 [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
