Murray S. Kucherawy 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:
DKIM Security Assessment (RFC4686)
DKIM Service Architecture (RFC5585)
DKIM Deployment Guideline (RFC5863)
DKIM Signing Practices (RFC5617)
DKIM Reporting using A-R (RFC5451)
Please show me any citation in RFC5451 that demonstrates your claim.
Sorry, correction, it would be the RFC5451 extension for DKIM
DKIM Reporting using A-R (RFC6008)
http://www.rfc-editor.org/rfc/rfc6008.txt
And we're not. To use your analogy: DKIM returns a status
and "d="; extended DKIM (whatever that means) can return that and
more. We're updating the specification of DKIM here, not
declaring what extended DKIM might be.
It works just fine.
I agree, for current implementors.
Not for a fresh reader just reading RFC4871bis. I was hoping the
analog was obvious. It would be like reading only SMTP (RFC821)
today, designing your software around this model only knowing full
well there are for Extended SMTP operations and design needs. You will
read those relevant documents starting with RFC5321.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html