Charles Lindsey wrote:
And every list will be diferent, so we need to look at real examples. And
by a strange coincidence, we have just seen a concrete example on a list
well-known to all of us.
Yup, I am going to enjoy reading this thread.:-)
Speaking as a commercial List Server product manufacturer, its simple:
The only time a list server should resign is when it broke an original
valid signature for the purpose of restoring the mail integrity of the
original domain message owner and author with an original DOMAIN intent
to sign mail. It should never sign a message that a DOMAIN never
expected to be sign or knew nothing of it and It should NEVER, EVER,
NEVER resign a broken DKIM message.
The basic overall problem is we are trying to make something with an
POLICY framework. It won't work well, just don't see it.
And the 4871 flaw of promoting FAILURE to never sign status complicates
the handling issues. The only time that FLAW makes sense is when you
have POLICY and since SSP was an integral part of DKIM, you can see
the great logic in the BROKEN=NEVER SIGNED mandate in the specification.
But when don't have POLICY than that mandate is FLAWED - period.
You need a policy framework to help disseminate what was expected and
what was not expected. You are left with a guessing game - is this
FACEBOOK message a spam or a message vouched by Dave's server? Should
people trust it because Dave's broadcasting server signed it? Did the
message have a valid signature and Dave stripped it or was a invalid and
he stripped and replaced it anywa? It speaks volumes to the lack of a
POLICY based framework. It should NEVER be a source of new SIGNING
when it was never there to begin with and/or expected to be there by the
original domain - bad guys will no doubt exploit this as you just
seen. I thought his FACEBOOK think was legitimate for a second, that
someone here was putting together a DKIM social network. Can imagine
the layman user? Is he not a RISK?
IMO, The list server should NOT sign unless the mail was valid with a
DKIM signature and its going to break it, thus the need to restore a
DKIM message - not create one.
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html