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
