Dave CROCKER wrote:
?> In Section 5.8:
"DKIM-aware authoring MLMs MUST sign the mail they send according to
the regular signing guidelines given in [DKIM].
One concern is that having an MLM apply its signature to unsigned
mail might cause some verifiers or receivers to interpret the
signature as conferring more authority or authenticity to the message
content than is defined by [DKIM]. This is an issue beyond MLMs and
primarily entails receive-side processing outside of the scope of
[DKIM]. It is nevertheless worth noting here."
Removing the MUST and saying:
DKIM-aware authoring MLMs signs the messages they send according to
the regular signing guidelines given in [DKIM]
gives more weight to the last two paragraphs, especially with the
note about the concern.
Not really. The latter paragraph merely notes that there are receivers
that do not understand what a DKIM signature means.
Something is amiss if after 6 years of development, after countless
repeated explanations and messages over the years, it still seems very
a difficult feat to describe in one or two sentences to the layman
what DKIM is suppose to do for them, today or in the some distance future.
The fact is DKIM has many conflictive semantics. While the above says
its out of scope, it says the opposite in RFC 46751bis 6.3:
Once the signature has been verified, that information MUST be
conveyed to the Identity Assessor (such as an explicit allow/
whitelist and reputation system) and/or to the end user. If the SDID
is not the same as the address in the From: header field, the mail
system SHOULD take pains to ensure that the actual SDID is clear to
the reader.
See the SHOULD? See the technical association highlighted between the
signer domain (SDID) and the the originating, copyright holder/author
of the Message?
Now, look at the conflict in the Abstract and repeated again in
Section 1.2 defining the Signing Identity:
DKIM separates the question of the identity of the signer of the
message from the purported author of the message.
What question is that? RFC4871 never quite clearly defined thee
"question."
Lets think about what that question may be. Answer this:
Do Electronic Mail Author Domains have any security
rights and controls over who DKIM signs their mail?
Be nice for someone to answer that question.
Then of course, we have augmented RFC productions, such as RFC5585
that describes the "DKIM Service Architecture" and the illustration
has that Author Domain "Checking Signing Practices" process component
displayed in the diagram:
|- RFC5322 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +...>| Sign Message with SDID |
| Store | +---------------+----------------+
+--------+ |
(paired) [Internet]
+--------+ | +-----------+
| Public | +--------------------------------+ | Remote |
| Key | | RELAYING OR DELIVERING ADMD | | Sender |
| Store | | Message Signed? | | Practices |
+----+---+ +-----+--------------------+-----+ +-----+-----+
. |yes |no .
. V | .
. +-------------+ | .
+.......>| Verify +--------+ | .
| Signature | | | .
+------+------+ | | .
pass| fail| | .
V | | .
+-------------+ | | .
| | | | .
+.......>| Assessments | | | .
. | | V V .
. +-----+--+----+ +-------+ .
. | | / Check \<............+
. | +-------->/ Signing \
. | / Practices \<..........+
. | +-------+-------+ .
. | | .
. | V .
+----+--------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info |
|Accreditation| +----------->| Filtering | | on Sender |
|Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+
Figure 1: DKIM Service Architecture
Then you have the RFC5863 Development guide with a few dedicated
sections, but not the only sections:
7.3. Author Domain Signing Practices
7.3.2. A Few Definitions
7.3.3. Some ADSP Examples
Then finally, you have the crux of the problem with this RFC5017
section 5.3 item #10 statement:
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
So on the one hand you have functional specifications across multiple
RFC which recommends receivers to honor author domain signing
practices as a security measure to help product DKIM domains, but then
we have miscellaneous peppered injections of statement that conflicts
with these goals by telling receivers they MUST (not a MAY) to mind
their own bee's wax if they see an unexpected, unsolicited, unknown,
unauthorized non-first party DKIM signed mail when the author domain
may have a policy that says "Thats a NO NO"
Dave, you got receivers all twisted up in knots!
--
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