Dave CROCKER wrote:
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for
the specification to suggest dealing with it.
At least, please show working group rough consensus support for doing
what you suggest.
Dave,
All I am trying to do is show the inconsistencies in RFC4871bbis not
matching current implementation needs and it is incomplete in what
RFC5585 describes.
I didn't write RFC5585 but if I did, I would not have added the
Checking Signing Practice and titled it as "DKIM Service Architecture"
because the concept was removed from DKIM. But you did and the
Deployment Guide has an entire section on ADSP. The archive is my
evidence, I have stated if you don't want ADSP then don't reference it
any DKIM related document.
But it was done in in the Deployments Guide and explicitly added as
part of the DKIM Service Architecture, not stated it is an "Extension"
or any one shown to be not part of the architecture. Its right there
as a large part of the software engineering design. What do you
expect people to think?
So I suggest reasonable people taking this documents will clearly see
policy, signing practice, adsp or whatever you wish to call, its part
of the DKIM design and architectural consideration and RFC4871bis does
not prepare anyone for that DKIM architecture design.
IETF BIS work should be, at least I thought it was, about codifying
current implementation and they match RFC5585, not RFC4871bis. Is
that a problem? I think so. You seem to think not.
All I am saying is with the window of opportunity we have now, connect
the dots and be consistent with the RFC described DKIM Service
architecture.
Finally, you keep saying:
"DKIM has nothing to do with the rfc5321.From field"
(Well, I think you meant RFC5322.From. Right?)
This is not technically correct.
1) It is the only single requirement for binding to the signature and
there again, the archive evidence will show where I have stated on
many occasions if we want the above statement to be true, then we need
to relax the specs to remove this single mandatory binding signature
requirement.
2) The binding of 5322.From is inherently associated with the SDID
responsibility claim for the bits that are signed. So for anyone to
use SDID trust, it is to both technically and ergonomically (UI) claim
the author is trusted whether or not the signer had any association
with the author or not.
Again, its about protocol consistency. So maybe I should ask the
chairs for:
"Consensus needs to be reevaluated"
--
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