[ietf-dkim] broken signature is no signature, was NO DKIM "POLICY"
hsantos at santronics.com
Sun Feb 22 01:06:18 PST 2009
Olivier MJ Crepin-Leblond wrote:
>> I sent a message to my gmail account with a broken signature, and
>> gmail noted the bad signature and delivered it just fine. Evidently
>> there's something else wrong with your mail.
> You're right: Gmail's probably "whitelisting" the emails with correct
> signature whilst pushing the ones with broken signature through their
> spam filters. If the filters don't detect Spam, gmail will deliver the
That would make sense, if indeed the message were spam hence
explaining why it wasn't finally posted. But that is not what was
Look, the lesson here is that DKIM does nothing for legacy mail (Mail
without DKIM signatures).
There is no protection unless the implementator ignores the "Broken
Signature Is No Signature" inherent policy in DKIM.
The failed signature will be recorded and passed to classification
routines as GMAIL has shown.
If John believes that is an implementator fault, not the spec. Well, I
see it as the spec had it wrong.
I believe this mandate was born from the original original DKIM + SSP
framework, where SSP had policies to deal with this. Hence if a
broken signature was promoted to no signature status, the "Always
Sign" policy would handle this case.
But without SSP, the semantics are no longer valid.
In fact, I would suggest there are conflicts with this 4.2 statement
with what is described in 6.2 and 6.3
Verifiers SHOULD ignore failed signatures as though they were not
present in the message. Verifiers SHOULD continue to check
signatures until a signature successfully verifies to the
satisfaction of the verifier. To limit potential denial-of-service
attacks, verifiers MAY limit the total number of signatures they
will attempt to verify.
6.2. Communicate Verification Results
Verifiers wishing to communicate the results of verification to
other parts of the mail system may do so in whatever manner they
6.3 Interpret Results/Apply Local Policy
While the symptoms of a failed verification are obvious -- the
signature doesn't verify -- establishing the exact cause can be
more difficult. If a selector cannot be found, is that because the
selector has been removed, or was the value changed somehow in
transit? If the signature line is missing, is that because it was
never there, or was it removed by an overzealous filter? For
diagnostic purposes, the exact reason why the verification fails
SHOULD be made available to the policy module and possibly recorded
in the system logs. If the email cannot be verified, then it
SHOULD be rendered the same as all unverified email regardless of
whether or not it looks like it was signed.
4.2 only make sense if POLICY was still in place as an available
technology as it was when DKIM was first written.
More information about the ietf-dkim