[ietf-dkim] list expanders (was Re: chained signatures, was l= summary)
MH Michael Hammer (5304)
MHammer at ag.com
Mon Jun 15 09:59:53 PDT 2009
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of hector
> Sent: Monday, June 15, 2009 7:38 AM
> To: Charles Lindsey
> Cc: DKIM
> Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures,
> l= summary)
> Charles Lindsey wrote:
> > And every list will be diferent, so we need to look at real
> > by a strange coincidence, we have just seen a concrete example on a
> > well-known to all of us.
> Yup, I am going to enjoy reading this thread.:-)
Me too. Popcorn in hand (figuratively speaking).
> 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
> 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.
So you are absolutely against 3rd party signatures unless the 3rd party
broke a first party signature?
My understanding has always been that anyone who handles a message can
sign and thereby take responsibility (whatever that might mean) for the
message they are signing.
> The basic overall problem is we are trying to make something with
> POLICY framework. It won't work well, just don't see it.
> And the 4871 flaw of promoting FAILURE to never sign status
> the handling issues. The only time that FLAW makes sense is when
> 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
I have to disagree Hector. For better or for worse, SSP was never an
integral part of DKIM. It is layered on top of DKIM. Those that wish to
publish a policy (whether it was SSP or ADSP) can do so. Those that wish
to check and act against a published policy may do so. Others may choose
to ignore SSP/ADSP whether as a potential publisher or a potential
verifier. While I am a firm believer in the need for organizations to
have the option of publishing policy, I do not view it as "an integral
part of DKIM". To do so would require one to advocate publishing policy
as "MUST" rather than "SHOULD" or "MAY".
> But when don't have POLICY than that mandate is FLAWED - period.
BROKEN=NEVER SIGNED mandate in the specification. If an organization
chooses to assert they sign all messages and BROKEN=NEVER SIGNED then
the logical conclusion is obvious.
> 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?
It appears to be a spam vouched for by Dave's server.
> people trust it because Dave's broadcasting server signed it?
What does trust have to do with it? All I know is that Dave's server
signed it and Dave thereby takes responsibility for it. So Dave.....
what does your taking responsibility for it mean?
> message have a valid signature and Dave stripped it or was a invalid
> 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
> 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
> the layman user? Is he not a RISK?
I'm surprised Hector. It really took you a second to decide it wasn't
> 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.
Au contraire. What you describe leaves a vector for attack a mile wide.
Break a signature from the original domain and then sign with some
random domain. You cannot accept one signature as a substitute for
another (broken) signature. Each signer stands on their own merits (or
More information about the ietf-dkim