Barry Leiba wrote:
That's not what RFC5617 says.
� �Meaning: �No valid Author Domain Signature was found on the message
� � � � � � �and the published ADSP was "unknown".
Can't that be read as meaning a non-Author Domain Signature was not
expected?
No, not at all. I can't think of any interpretation of that sentence
that would give that meaning.
"No valid Author Domain Signature was found" says nothing about
anything else that might or might not have been found.
"If it rains, then I won't play baseball," says nothing about what
I'll do if it doesn't rain.
This is part of the semantics clarification we seek. You are probably
catching up, but the text descriptions for DKIM=UNKNOWN are found in
ADSP Section 4.2.1 and 5.4:
unknown The domain might sign some or all email.
Meaning: No valid Author Domain Signature was found on the message
and the published ADSP was "unknown".
Think of the software:
First, No ADSP record is found.
In this case, there is absolutely no policy semantics regarding DKIM
the verifier can make for the author domain. No sig, double, triple,
mixed 1st, 3rd, some valid, some broken, whatever, the verifier can
not make any ADSP interpretation other than dkim-adsp=none.
But now we have an explicit DKIM=UNKNOWN;
The semantic and also part of the WG conflicts is the absence of a
valid Author Domain signature and includes the presence of a valid 3rd
party signature.
In other words, should the verifier?
#1 - ignore signatures where SDID != ODID, and
#2 - only look for signatures where SDID == ODID
The problem Barry, and this was a long term issue with ADSP, is that
it lacks an explicit semantic or definition where it says:
mail can be signed by anyone
or
ignore mail that have 3rd party signatures
This conflict begins in RFC5017 (Requirements for Signing Practice) in
most debated item in section 5.3, Item #10:
5.3. Practice and Expectation Requirements
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.
Refs: Deployment Consideration, Section 4.3.
Base on this, its implies to me we should ignore 3rd party signatures,
but that is conflicts with ADSP and even the fundamental idea behind
RFC5017 - check for author policies and policy violations.
So I can understand that if there are no explicit record, then the
receiver can not make any presumptions about the signatures in the
message. But if there is a record, then its negates what item 10# is
saying for the verifier with a local policy to support ADSP to mind
its bee's wax with the presence of a non-first party signature.
Do you see the conflict?
Just consider when an explicit ADSP record is found with:
DKIM=DISCARDABLE
DKIM=ALL
Does these also come an item #10 ignore 3rd party signature concept
even with the receiver is willing to honor ADSP and author domain
policies?
--
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