Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have to strongly disagree with many of the things said here. I am
one of the original authors and designers, and while I don't speak
for the other authors and designers, I believe that I can reasonably
authoritatively say something about DKIM's original intent.
>
> ...
>
My policy is that an authenticated user can "forge" senders. If that
policy turns out to be unwise, it's my problem. It is the intent of
DKIM that the administrative domain has the right to be stupid.
Nonetheless, a DKIM signature means that I accept responsibility for
a message I (meaning one of my authenticated users) put into the mail
stream.
And let me say Jon, thanks for helping put it together.
My only issue is the term "responsibility."
In my opinion, you are are always inherently responsible for your system
regardless of DKIM.
So are we now saying there is a even a greater "responsibility" once you
sign with DKIM?
What about the domain with the optional signing policy (default)? Are
they responsible for the own domains they sign and not responsible for
their own domains they don't sign?
To me, what we are really talking about is "authenticating ownership"
not of the author's message content but of the transaction.
For example, a DOMAIN, example.com, has a "I sometime sign" SSP.
For some reason, his system signs some but not all, so a receiver can
potentially get four types of messages purported from example.com:
1S) signed by example.com (REALLY FROM EXAMPLE.COM)
1U) unsigned by example.com (REALLY FROM EXAMPLE.COM)
2S) signed by example.com (REALLY FROM BAD GUY)
2U) unsigned by example.com (REALLY FROM BAD GUY)
SSP will not help much here, other than tell the receiver that some mail
can be signed.
In theory, the resultant classification (not related to whether a
message is ultimately rejected or accepted) is:
1S) VALID
1U) INVALID DUE TO DKIM SPECIFICATION (NO SIGNATURE)
2S) INVALID DUE TO DKIM SPECIFICATION (BAD HASH)
2U) INVALID DUE TO DKIM SPECIFICATION (NO SIGNATURE)
Never mind the predicament this puts the receiver in, which messages are
you responsible for?
According to DKIM, you are responsible for 1S and 2S - the ones that
were signed, including the forge or spoofed DKIM message. Conversely,
according to DKIM semantics, you are NOT responsible for 1U - the one
really from you and 2U the one from the bad guy.
From a receiver standpoint, it will know the difference between 1U and
2U unsigned transactions. It also tells me that you have a 75% chance
of adding a negative classification weight for the default "I something
sign" policies.
One reason I think the "Ignore if invalid signature" DKIM rule is a
terrible idea is because its an untruthful state in an automated
transaction world.
In 2S, there was an obvious intent to signing. But it failed. So this
SHOULD have a higher negative classification weight.
If one was to use a neuron network or Bayes like based decision tree,
this is the type of information that is needed. But if we follow the
DKIM "IGNORE IF FAILURE" rule, one can say the classification would be:
1S) +1
1U) -.25 (following DKIM)
2S) -.25 (following DKIM INVALID IS NO SIGNATURE)
2U) -.25 (following DKIM)
See the problem? 1U, 2S and 2U can potentially have the same weight.
If we include the true failure fact of 2S, the weight might be:
1S) +1
1U) -.25 (following DKIM)
2S) -.50 (following DKIM INVALID IS NO SIGNATURE)
2U) -.25 (following DKIM)
So we really can't ignore the invalid signature attempts.
Ultimately, DKIM or no DKIM, you are responsible for all of this.
So to me, DKIM is about taken ownership with signed transactions, the
added DKIM "tokens" provide new attributes that is typically missing in
normal email.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html