Dave CROCKER wrote: > > > On 4/28/2011 12:49 PM, Hector Santos wrote: >> To illustrate this in RFC5585 by labeling the inputs required: >> >> >> | >> |- RFC5322 Message >> V >> +--------------------------------+ >> | Message Signed? | >> +-----+--------------------+-----+ >> |yes |no >> | | >> |SDID/AUID |AUID >> | | >> V | >> +-------------+ SDID/AUID | >> | Verify +---------+ | >> | Signature | | | >> +------+------+ | | >> pass| fail| | >> |SDID | | >> V | | >> +-------------+ | | >> | Assessments | | | >> | | V V >> +--------+----+ +-------+ >> | | / Check \ >> | +--SDID-->/ Signing \ >> | / Practices \ >> | +-------+-------+ >> | | >> V V >> >> >> As you can see, per RFC5585, both SDID and AUID are mandatory DKIM >> outputs. > > > You are confusing DKIM requirements with ADSP requirements.
Please respect there is no intent to do this. 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: DKIM Security Assessment (RFC4686) DKIM Service Architecture (RFC5585) DKIM Deployment Guideline (RFC5863) DKIM Signing Practices (RFC5617) DKIM Reporting using A-R (RFC5451) Here is a way to view the old vs new design dilemma: SMTP vs ESMTP (Extended SMTP) We have decades of engineering foresight to not repeat completing a protocol design with an outdated limited output scope especially when extensions are already available. While I am in no way suggesting RFC4871Bis should be updated as an EDKIM (Extended DKIM) standard, we should recognized that DKIM-BASE has limited usefulness with its limit outputs requirements. As we know today, AUID should not be excluded from the output summary. -- Hector Santos, CTO http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html