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