Murray S. Kucherawy wrote: >> Hector Wrote: >> But its not clear on the other outputs appropriate for the receiver to >> consider. > > And who gets to define "appropriate"?
Well, who gets to define "Output Requirements?" I will suggest it is both appropriate and required per RFC5585, RFC4686, RFC5017 and RFC5617. > It's already been pointed out that we could list every > current tag's value and a pile of other stuff to pass on > to the next layer, which may or may not find it useful, > but that would make for an extremely messy protocol. But that is not being requested. You need to extract all the primary consideration that were discussed, developed, implemented over the years. We have four RFCs, actually seven RFCs thats relates to DKIM rfc4686 Analysis of Threats Motivating DKIM rfc5016 Requirements for a DKIM Signing Practices Protocol rfc5518 Vouch By Reference rfc5585 DKIM Service Architecture rfc5617 DKIM Author Domain Signing Practices (ADSP) rfc5863 DKIM Development, Deployment, and Operations rfc5965 An Extensible Format for Email Feedback Reports But in my opinion RFC5585 is the key document because, well, it has pretty pictures! :) Ideally, you should list all of the above in section 1.1, but that is not being request - just the minimal extracts for receiver security and trust evaluations. > Protocols need to be kept simple. .... and secured and useful without losing your hair extracting this information for all receivers to consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html