I find it amazing how many different ways there are to criticize DKIM for not doing something it was never intended to do. DKIM is a small building block that enables new functionality, but such functionality is beyond the scope of DKIM. DKIM does one thing, and one thing only: It uses a cryptographic signature to associate a domain with a message. By doing so, it creates strong evidence that the message passed through that domain at some point and has not been significantly modified since. Whether that domain is good guys or bad guys, senders or resenders, Coke or Pepsi, is completely irrelevant. It is a small nugget of evidence to provide an anchor point for forensics stronger than what have come before. It tells us that the named domain considered the message reasonable to send or resend, for its own reasons -- its own forensic evidence, its nefarious intent, or the phase of the moon. With such an anchor, we can begin to build stronger and more robust systems for analyzing the desirability of messages, as we are now trying to do in the REPUTE work, because it allows us to push our forensic analysis upstream a bit. It does not relieve downstream software of the need to decide how to feel about the signing domain, whether it's a spammer, a copy-cat, or anyone else. If, for example, the IETF mailing list software only allows posting by list members, but itself trusts the sender's header fields, then an IETF DKIM signature tells me only that the IETF servers think a message passed that test. That's obviously not perfect, but it's slightly stronger than what came before -- it is still possible to forge a message before sending it to the list, but much harder to forge a message to look as if it came from the list exploder. That is progress -- very very small, slow, progress. If, at some point, the list exploder starts only passing through messages that themselves have valid DKIM signatures, it will be significantly more progress, but it won't do anything to stop a spammer from subscribing to the IETF list and DKIM-authenticating himself. For that we'll need reputation information -- another small step, which we're trying to initiate with REPUTE. We've had a long history of grand plans for user authentication on the Internet. Those plans have largely failed. I think an incremental approach like DKIM has a better chance, but it is obviously vulnerable to being dismissed by those who see a small improvement as not worth bothering with. The best is the enemy of the good. -- Nathaniel On Jul 31, 2011, at 6:12 AM, Hector Santos wrote: > You continue to not comprehend (or rather ignore) what continues to plaque DKIM - the lack of fault detection. Its why it continues to have a hard time and have people who actually believe in this promising protocol "bitch" about it. If these "big email" providers (or anyone for that matter) begin to make assertions about what is good about their mail then they better be ready for the violations of such assertions to be rejected. You can't have it just one way and mandate this is the only way to process this overhead - looking for good mail only and ignoring all the violations and illogically treating it like it was never signed or compromised or attempted to be compromised. > > The overall difficulty is that originality is lost - the original author or dkim signer has lost or lacks any protocol guidance to tell resigners that the mail they are about the process might be bad - according to the original author domain. > > If the resigner is going to intentionally and neglectfully ignore all original claims about the original domain signing practice, then how do you expect the anonymous "copy-cat" abuse to be controlled? > > > Murray S. Kucherawy wrote: >>> -----Original Message----- >>> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of t.petch >>> Sent: Saturday, July 30, 2011 3:26 AM >>> To: Barry Leiba >>> Cc: ietf >>> Subject: Re: DKIM Signatures now being applied to IETF Email >>> >>> Sadly, I do not see it being used in the mailing lists where an >>> organisation is sending me directly data I would like to be able to rely on >>> - which I think fits the applicability well - and instead, I see it >>> being used on a mailing list such as those in the IETF where I >>> believe that the costs outweigh the benefits - and I have no choice >>> about that:-(. >> There has been some post-DKIM talk recently about the idea of "transient trust", wherein (to use this example) ietf.org would verify the signature on an arriving list submission, attach an RFC5451 header field that indicates the results of that verification, then send the message out to the list with that added field and a new ietf.org signature that "covered" it. Then, if you decide to believe ietf.org's claims about the original signature, you know more than you would otherwise. >> This hasn't been widely deployed yet, but some big email providers are currently playing with the idea. >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > -- > Hector Santos, CTO > http://www.santronics.com > http://santronics.blogspot.com > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf