Daniel Black wrote:
So I suggest we update the DKIM MLM draft to take out all the stuff about
signatures surviving lists, and just say that if it's important for your
signature to survive,
The DKIM standard has gone a long way to ensure interoperatibility and the
ability to survive canonicalisation changes, header field additions and is
careful about which header fields are recommended for signing purely based on
survivability. Taking an approach saying we don't care if DKIM survives MLMs
is a step in the opposite direction. This is not a proposal I support.
I know this is background noise, but I have no interest in restoring
broken signatures or passing on ones we broke.
Aren't people tired of dealing with iffy iffy mail? If so, why
contribute to it with even more iffy iffy mail?
Maybe we should come up with a new idea called DKIM Amplifiers
(DKIM-AMP) whose purpose is to restore the signal strength of DKIM
signatures from hop to hop, from resigner to resigner.
Maybe we should have a new DKIM-PREDICT, whose purpose it allow the
source point to create a PREDICTED PATH header on how mail will
travel. DKIM-PREDICT learns by looking at Received lines and sending
feedback to the source point, providing tips on the ORCP (OBSERVED
RECEIVED COMMON PATH).
Maybe we should have a new DKIM-FUZZY, whose purpose is to allow for
non TRUE or FALSE conditions or MAYBES, wait, we already have a
DKIM-FUZZY framework. :)
Seriously, this stuff is really complex - anyone who says this is easy
stuff to implement, well ............ Sure it is easy to sign - if
you don't care what was there to be begin with. Sure it is also easy
to verify - but what is the end result of that? A continuation of
iffy iffy mail world with the biggest beneficiaries - the BAD GUYS who
will continue to do nothing to remain in a iffy iffy mail world.
Again, just background noise. :)
--
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