Steve Atkins wrote:
On Aug 24, 2010, at 6:35 PM, John R. Levine wrote:
may I suggest we stop here for a moment and get back to the original
question, which in essence was: should a 1st signer DKIM signature be
preserved 'co�te que co�te' when a message is handled by a MLM, or not.
It shouldn't, at least not if it means the MLM has to modify
it's behaviour significantly. Subject line tags, unsubscription
footers, that sort of thing are all useful features that shouldn't
be sacrificed at the altar of theoretical ADSP corner cases.
I don't think anyone suggested or take seriously any suggestion to
change the MLM long history and accepted practice of altering the
original integrity of list message submissions.
We are saying that to for an MLM to implement DKIM (something new) it
will need to also look at issues regarding the destruction of such new
mail and one way to do this is to not do it by supporting a companion
WG proposed standard and hint called policy (ADSP) which tells the MLM
it is about to break a new type of secured and protected domain
message by ignoring the policy hint. It is telling the MLM the message
wasn't expected to be in the MLM environment in the first place. The
MLM is allowed to throw it away.
But if there is no policy, the domain didn't care and the MLM can do
what it normally does, including adding a new signature and removing
broken ones so it can perhaps taste like a good clean dkim message again.
I don't see anything wrong with implementing this logic in software.
I see no down side other than do a low cost DNS lookup for the message
submission author domain ADSP record.
The only engineering argument one can have is that this will be
redundant wasted overhead on the highly non-engineering subjective
presumption that no one will ever support ADSP. Well, if the WG
truly believes, then why do we continue wasting time on a WG working
documents called ADSP and MLM? Get rid of it.
But while it is still on the WG table, I don't think it is logical to
be telling engineers to ignore it (Look but don't touch) and expect
things will work flawlessly based on unproven statistics and
probability of non-support.
I personally believe strongly POLICY will well received for outside
list usage once we can get the key people writing the docs to finally
stop against it and accept it as a DKIM technology and allow
developers to begin add it to there APIs once again, just like the two
original open source DKIM API had built-in support for SSP and there
were R&D domains exploring it before ADSP stripped down SSP and
created a "wait and see" attitude. The problem? Its no fun adding
software with a WG standard that won't be followed at the suggestion
of its authors.
--
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