Dave CROCKER wrote: > On 4/28/2011 3:23 PM, Hector Santos wrote: >> Rather I am highlighting the limited DKIM output requirements is >> outdated and insufficient to support today's (extended) DKIM mail >> integration and security needs outlined by WG consensus-built RFC documents: >
> What part of "that's ADSP, not DKIM (signing)" did you not understand? When asked this way, I don't understand "not DKIM (signing)." Per DKIM, since AUID is a mandatory input for signing via the required From: binding to the signature, with engineering reason, it should be included in the output summary. What is done with it is not the question. I believe you are trying to infer perhaps the Output Summary section should have an initial introduction: A trust assessment final output is the only DKIM final output requirement. If so, there has never been any confusion over this limited DKIM goal and IMO, the proposed new section would be redundant. I'm saying no one in their right mind is only going solely read RFC4871bis but also your other fine overview documents. If they did, they will design code that is functionally incapable to support anything but a trust model only and to develop any new assessment engines (probably because they read the overview and deployment guides), they will need to change their software. The practical world will not design their code with only a RFC4871bis limited scope because the experiences already exist - as your overview and deployment guides show. So its more about how one can sneak in some verbiage without conflicting with RFC4871bis final production, if all possible. Can that be done? -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html