Dave CROCKER wrote:
On 5/8/2011 7:03 AM, Barry Leiba wrote:
I proposes the following:
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This identity
MAY be considered as an output communicated to an advanced
Identity Assessor module.
I don't like making up a new name for what we already have. I'd
rather just call it "the domain part of the 'From' address."
We might want to consider the benefits of consistency with
existing documentation.
Email Arch (RFC 5598):
Section 2.1.1: Author - responsible for creating the message
Section 2.2.1: Originator - ensures that a message is valid for
posting and then submits it to a Relay
Section 4.1.4: From: Author
Sender: Originator
So what, exactly, are the semantics intended by this new term.
See RFC5585, RFC4686 and RFC5863. Which by the way has nothing to do
with the author but the author domain (ODID).
We have long established the only single anchor we have in RFC5322 and
one we must protect is the RFC5322.FROM and that is why is it the
single only DKIM requirement for burning it into the signature.
Since the DKIM has nothing to say regarding missing signers, the
security is lost and is thus an unsecured protocol design to now allow
the ODID to be checked per RFC5016, RFC5617, RFC5585, RFC4686 and RFC5863.
Adding a new term to refer to a portion of the From: field implies
that there is an important need for the DKIM Signing specification
to make that reference.
And it does in section 1.1 with the advisement for readers to be familiar:
1.1. DKIM Architecture Documents
Readers are advised to be familiar with the material in [RFC4686],
[RFC5585] and [RFC5863], which respectively provide the background
for the development of DKIM, an overview of the service, and
deployment and operations guidance and advice.
This feeds the confusion about the role of a DKIM signature.
Too late. The existing confusion is to create (1) functional
specifications and requirements and then ignore it in your (2)
technical specifications, thus confusing (3) implementors, making (4)
testing payoffs much harder to achieve and (5) maintenance even worst
to contain - your five phases of Software Engineering.
That's not benignly "unnecessary". That's actively
counter-productive.
See above.
--
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