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
email.
That would make sense, if indeed the message were spam hence
explaining why it wasn't finally posted. But that is not what was
observed.
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
4.2. Interpretation
...
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
see fit.
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.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html