[ietf-dkim] Output summary

[Hector Santos]

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@mipassoc.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