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