Michael Thomas wrote:
Rolf E. Sonneveld wrote:
Don't get me wrong, I just wanted to demonstrate that, IF we follow the
logic of not crossing protocol boundaries strictly, THEN communicating
the d= payload /without additional information/, we
* either enforce upper layers to violate layers or
* in advance we discourage in advance the design and development of
a number of useful applications that otherwise could have been
built on top of DKIM.
In the archives I found exactly this same concern and discussion, see
for example the contribution of Jim:
http://www.mail-archive.com/ietf-dkim(_at_)mipassoc(_dot_)org/msg11105.html
Indeed, the chickens have come to roost. This was ill-conceived at the
time of the errata, and it is ill-conceived here. It is yet another reason
why I believe that the protocol described in 4871bis only bears passing
resemblance to 4871 and interoperation will be purely coincidental.
What gets me is that I thought IETF bis work were suppose to help
codify existing implementations - bring it up-to-date. That was
burned into me by Hansen and Klensin. All implementations go beyond
what RFC4871 and RFC4871bis is not really learning from those
DKIM-years deployment experiences. Older APIs had to be changed to
include A-R. Policy was always part of the API and never removed. Just
modified from SSP to ADSP.
RFC4871bis is like someone reading RFC821/RFC822 today knowing full
well it is out of date for today SMTP mail hosting requirements. You
won't, you will need to combine all the DKIM documents which was what
we had to do with I considered the "holy bible" for internet hosting -
RFC1123. Twelve years later RFC2821 made RFC1123 obsolete.
--
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