Murray S. Kucherawy wrote:
-----Original Message-----
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
Please show me any citation in RFC6008 that demonstrates your claim.
Hmm, what specific claim you think is being made? What are you
driving at? That A-R is not a fundamental part of Today's DKIM
architecture? Its is all over the place tieing DKIM to A-R,
including in RFC4871bis. A google search will show all this. [1]
Do you have an RFC5451 "extension" I-D specific for DKIM A-R reporting?
I don't recall whether you do or not but I followed some DKIM A-R
examples out there to produce A-R to include DKIM, ADSP reporting. As
an implementor, I needed all the extra output and had to modify
existing code to get that extra information not spelled out by DKIM.
The point is you need these extra documents to get it right. You need
A-R today because its the only "BCP" around for DKIM and if anyone who
dares to claim it not needed and even tries to compete with it, well,
you, I and probably many others will contest that claim as well.
--
Hector Santos, CTO
http://www.santronics.com
[1] http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
Signature verification failure does not force rejection of the
message. Instead, the precise reasons why the authenticity of the
message could not be proven should be made available to downstream and
upstream processes. Methods for doing so may include sending back an
FBL message, or adding an Authentication-Results header to the message
as described in RFC 5451.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html