Douglas Otis wrote:
Once SMTP clients find they might be blocked for having issued too many
invalid DKIM signatures, they might remove invalid DKIM signatures
beforehand. Although this is in conflict with the base specification,
at least this measure ensures SMTP clients are not associated with bad
behaviours related to bogus DKIM signatures.
Not so.
If the SMTP client is going to strip signatures, then the verifier is
now in the 100% non-repudiated state of NO signature and will label the
message SUSPICIOUS for DKIM=ALL/STRICT policies.
The question is how or when can this happen.
Well, of course, this is not an original source because if a SMTP client
is seeing bad signatures, you are assuming it itself did not honor
DKIM-BASE or SSP when it first received the message and decided to
redistribute or relay the mail.
So all you really highlighting here is the need for the middle ware to
be protocol consistent as well.
For example, if Mailman is ignorant of SSP and the domain's strict
policy, and it strips the signatures, then the final verifier will have
no problem marking this transaction as SUSPICIOUS per SSP-01.
On the other hand, if Mailman left it alone, the verifier will be left
in a limbo state which can only be rectified with a HARD requirement
that STRICT means STRICT and broken also means the message is
SUSPICIOUS. DKIM-BASE will justified this hard SSP requirement because
of its broken to no-signature promotion mandate.
If, or when, DKIM signature hygiene does becomes a common practice, as
perhaps it should, then any invalid DKIM signature would be fairly
indicative of either older systems already listed as being DKIM
unfriendly, or newer and perhaps questionable systems behaving badly.
So who is at fault here?
1) The user who didn't follow company policy and use a
company property outside its business interest?
2) Mailman or any other similar middle-ware who may not be
DKIM and/or DKIM/SSP compliant and allowed the user
to submit unauthorized messages?
3) Mailman or any other similar middleware who will strip
and/or strip/replace a redistribution because it has
altered the mail integrity?
Weighing an invalid DKIM signature as 'implying' a message is likely to
have originated from some domain invites bad behaviour that wastes
valuable resources.
No dispute there. I always said that.
Although an invalid signature should be considered
equal to no signature (as also specified in the base specification),
from the responses on this list, expect many will bet on initial
statistics and get this wrong.
I find this funny because I do seem to recall that you and others were
against restrictive policies because it was believe will restrict and
promote false positives in valid roaming users situations.
The problem as I see it that these same people did not want to give SSP
the light of day in lieu of using A/R heuristics to address the issue of
valid vs broken signatures.
> This does not bode well, and could
represent a sizeable loss of receiver resources.
Your point is clear and for me, it was well long understood as a problem.
But you need to see SSP is not the problem here. It is DKIM-BASE with
its broken signature semantics. SSP is fine when following the
DKIM-BASE broken signature to No Signature status. But you do introduce
FALSE POSITIVES into SSP because of it. As the SSP boundary table
showed, the GREY area is when the signature is DKIM-BASE signature is
truly broken.
These can be a GOOD or BAD intention message.
Some systems may want to take the high road and clearly label these as
bad and outright reject them and it will justified by the DKIM-BASE bad
to no signature mandate.
Some system may just wish to pass it on to a A/R concept.
Some system may just REJECT them for a TRUE no signature, and pass on
the bad signature to a A/R concept to learn more about it.
The problem is this:
Talking for myself here, I don't want to implement something that will
have a history of high false positives. I want something that is 100%
deterministic and believe SSP does that in the non gray DKIM-BASE areas.
It is conceivable we can have a switch that says:
[X] Promote Bad Signatures to No Signatures (default)
If this turns out be a high false positive area, then something has go
to give. We might add additional sub-options:
[X] Promote Bad Signatures to No Signatures (default)
[X] For ALL and STRICT policies only.
And this might help in minimizing the issue because as we all know, a
major problem with DKIM is its optional and relax provisions and in this
case, we might treat it just like any other message. That might suggest
that in a broken signature situation where a domain might have an
optional signing policy (DKIM=UNKNOWN), "filters" might not want to
ignore the fact that it was a broken signature so it can be used to
learn from.
I don't have a problem with true no-signatures and I don't have a
problem with "virtual" no-signature as well when the domain policy is
restrictive.
Also remember the domain has the HANDLING= option so, overall, it might
not be an issue for restrictive setups.
--
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