Steve, The engineering issues are three folds:
1) Domains who use ADSP in open middle ware environments. We all agreed since day one with similar SSP exclusive policies it would not be a good idea for these domains to do this. It is their responsibility to make sure they know what they are doing. 2) Resigners (e.g. list servers) are not respecting the DKIM augmented technology on the table - RFC 5617 3) Receivers in a general implementation of these new suite of DKIM technologies do support RFC 5617. So its not just a matter of domains doing the wrong thing, but resigners not even considering the potential the new DKIM augmented technology is CAN be implemented, in such an intentionally neglectful way understand it can be both a) conflictive with RFC 5617, and b) create a real problem for downlink distribution. If the framers of RFC 5617 do not believe it will work, then I propose the re-chartering consider the deprecation of RFC 5617. I don't think we can just work on the "Cross our fingers" premise that no one will support RFC 5617 - a concept that will ALWAYS be a thorn on a side for wide DKIM adoption. So either resigners support it or we get rid of it. -- HLS Steve Atkins wrote: > On Oct 10, 2009, at 12:43 PM, hector wrote: > >> My position is now is to agree with you IFF the modus operandi is to >> allow for resigners with no mandate or recommendation to use RFC 5617. >> If this is the recommendation, then we need to get rid of it or fine >> tune the specification to spell out the issues with receivers who >> begin to support it. > > It's potentially of value to a subset of senders. That subset does > not include any sender who sends mail to a third party mailing list. > > That subset of senders is probably strictly a subset of bulk mailers. > > Whether the real value to them is worth the complexity for recipients > is a whole other question, but anyone concerned about the problems > with sending mail from ADSP using domains through third party > mailing lists is way off in the weeds. > > Cheers, > Steve > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
