Ian Eiloart wrote:
--On 14 October 2009 15:39:12 -0400 hector
<gmail(_dot_)sant9442(_at_)winserver(_dot_)com>
wrote:
It may never be. But, it's relatively new, so it doesn't surprise me that
it's not in use. However, It's also not surprising that people who may use
the RFCs wish to understand the implications, and explore the problems
before implementing.
I couldn't agree more.
But I think the current advisement is not to use it, so R&D,
exploration, experimentation, and developing corrective measures is
next to nil. Under such conditions most systems won't bother or can't
afford to deal with alpha ware in a production environment. So to me,
it shouldn't be a surprise that there is little support, even thought
that might be high interest.
Its not very hard to create a DKIM simulation based on establishing
your boundary conditions for this process with the current specifications.
ADSP has three possible boundary conditions:
unknown
all
discardable
DKIM-BASE has five possible boundary conditions:
not signed
signed by 1st party - valid
signed by 1st party - invalid
signed by 3rd party - valid
signed by 3rd party - invalid
when can be reduced to three using the RFC 4871 semantics that
promotes/demotes an invalid signature to no signature (never signed)
status:
not signed
signed by 1st party - valid
signed by 3rd party - valid
Therefore you have nine theoretical possible outcomes:
ADSP RECORD
+=============================================+
| | UNKNOWN | ALL | DISCARDABLE |
|=============================================|
D | NONE | pass | discard? | discard |
K |-------+-----------+----------+--------------|
I | 1PS | pass | pass | pass |
M |-------+-----------+----------+--------------|
| 3PS | pass | discard? | discard |
+=============================================+
IMO, we have seven high confidence deterministic possibilities. For
the DISCARD? results, as you said, DKIM=ALL is open-ended with no
semantics (by design) so its left to ambiguous interpretation and
local policy.
Now, consider the following:
IMV, I think the RFC 4871 semantics for promoting/demoting a broken
signature to no signature is somewhat flawed. IMV, it was not when
policy was a major consideration of the DKIM specification and such a
semantic naturally fit the valid signature requirement policies.
But when you separate POLICY from DKIM-BASE, "data" was now lost for
augmented technologies to learn, explore, etc. In other words, when
the WG decided to separate the two developments, it invalidated this
semantic. It should of been removed IMO. The reason is because we lost
intent.
In the NONE/DKIM=ALL cell, this could be the result of two different
mail scenarios:
NO (REAL) SIGNATURE
INVALID SIGNATURE
To me, that is two different classification or weights.
I don't have the answer, but I believe it begins with the question,
which message do you trust more, one that didn't have a signature or
one that was broken?
For the former (Missing), one can argue it is a genuine spoof or a
roaming user using the domain address from some 3rd party service
(i.e. hotel). One can also say the roaming user is a thing of the
pass as most users now have direct internet access to their main
hosting service from anywhere in the world.
For the latter (broken), one can argue there was malicious intent but
it could be some relay that innocently broke the integrity.
So the RFC 4871 promotion (or demotion depending on your POV) of
Broken to no signature status hides intent. This can become important
if we are going to be looking at other evidence, headers, scoring or
classification concept.
Anyway, my 2 pennies.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html