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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf