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