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