[ietf-dkim] Output summary
hsantos at isdg.net
Fri Apr 29 18:15:58 PDT 2011
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:
> 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
More information about the ietf-dkim