Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
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. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
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
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
On 03.05.2011 15:28, Hector Santos wrote: Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org (unauthorized signer); The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; Would that be a reasonable valid A-R reporting for ADSP based on my interpretation of explicit vs implicit DKIM=UNKNOWN setting? I don't think so. The only difference between setting unsigned and letting it be derived by default should be the ability to control the expiration of such value. As for ATPS, I will happily mention mipassoc.org as authorized signer, and I'll possibly authorize more domains, but then I'll also forget some. That's what happened when I enabled ADSP promising to myself to whitelist each and every MLM, and failing to keep it. IMHO, MLMs should tell authors' servers about subscriptions, as that would solve a number of problems. Until they continue not doing that, this particular problem remains among the unsolved ones. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
Alessandro Vesely wrote: The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; Would that be a reasonable valid A-R reporting for ADSP based on my interpretation of explicit vs implicit DKIM=UNKNOWN setting? I don't think so. The only difference between setting unsigned and letting it be derived by default should be the ability to control the expiration of such value. Can you rephrase this so I can better understand your thinking? I am merely thinking of terms of intent. With no ADSP record, then I view that as a conscience operational decision to allow any signer to exist (for your messages). But if have an explicit ADSP record, that is a conscience operational decision to assert a policy declaration, one that comes with an author domain expectation (See RFC5017) for a valid signing practice. When the policy is violated, it is very important to know that in order to get a payoff value. I would like to point out there is a long term philosophical mindset conflict in regards to what is expected in receiver local policies: Accept all, Let Users decide, the DMA (Marketers) Cat's Meow. vs Deterministically Filter all the bad first, controlling receiver (and thus users) abuse. So depending on what side one is on or lean towards, the design considerations vary greatly. So only as an rhetorical example, what was tana.it intent by declaring DKIM=UNKNOWN? Per 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. To me that means when a message is signed, it MUST be a valid 1st party. When only a 3rd party signature is found, it is a policy violation. But thus we have the root of the conflict: See RFC5017, section 5.4 item #10. 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. This was a very controversial item and you can see the sensitivity of it by the words used to mandate a MUST NOT! On the way one hand, it wants receivers to mind their own bee's wax in regard to 3rd party signers but excluded the idea that receivers may want to honor author policies as part of their local policies. Item #10 was the central conflict that created ADSP in an attempt to get receivers to ignore the existence of 3rd party signatures and just use ADSP to look for the author domain non-signed messages. If the 3rd party signature exist, ignore it. Thats a engineering flaw when you have explicit policy declarations telling receivers what is expected. As for ATPS, I will happily mention mipassoc.org as authorized signer, and I'll possibly authorize more domains, but then I'll also forget some. Right, but does that means others would not a have definitive operational understanding of how their mail will be signed or expected to be signed? I think receivers can only work with DKIM on a basic idea to give the domain the benefit of the doubt. If you declare a policy, that helps alot. Otherwise, the domain really doesn't care, but the receiver will still care when it becomes abusive. That's what happened when I enabled ADSP promising to myself to whitelist each and every MLM, and failing to keep it. IMHO, MLMs should tell authors' servers about subscriptions, as that would solve a number of problems. Until they continue not doing that, this particular problem remains among the unsolved ones. +1. I think we can correct ADSP if it semantics can covers the ideas: ALWAYS SIGNED: By ME By any signer By MLM signer ALWAYS SIGNED with Authorization using Extensions By ME By any Authorized signer By any Authorized MLM signer I am not sure if we need to distinguish list signers but if we want to separate private vs public mail streams, maybe it can help. -- 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
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
On 04.05.2011 14:56, Hector Santos wrote: Alessandro Vesely wrote: The only difference between setting unsigned and letting it be derived by default should be the ability to control the expiration of such value. Can you rephrase this so I can better understand your thinking? ATPS wasn't visible when I set that record. The only reason I put it there was to state a decent TTL, which makes sense since the design of the DNS is such that replying not found never costs less than directly stating that it will stay unknown at least for the whole day. I am merely thinking of terms of intent. [...] So only as an rhetorical example, what was tana.it intent by declaring DKIM=UNKNOWN? Hm... I'm not sure how layer logic applies to that reasoning. A default is a value; discriminating whether it was explicitly given or assumed resembles Terrell's ternary logic, holding that a bit has three values http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
RFC5617 has for this tag value: dkim= Outbound Signing Practices for the domain (plain-text; REQUIRED). Possible values are as follows: unknown The domain might sign some or all email. For my A-R reporting if there an explicit DKIM=UNKNOWN record, I took this declaration to mean the domain only allows it to sign sometimes and no one else. There is no failure handling semantics unlike DKIM=DISCARDABLE, so no verifier action is done other than A-R record it. For example, this is such a reporting for a list message posted here by Alessandro with its tana.it domain. Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org (unauthorized signer); The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; Would that be a reasonable valid A-R reporting for ADSP based on my interpretation of explicit vs implicit DKIM=UNKNOWN setting? Of course, it should been labeled as DKIM=OPTIONAL because if someone went to extent to declare a record, it wouldn't be unknown what he intended. -- 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
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Tuesday, May 03, 2011 6:29 AM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting RFC5617 has for this tag value: dkim= Outbound Signing Practices for the domain (plain-text; REQUIRED). Possible values are as follows: unknown The domain might sign some or all email. For my A-R reporting if there an explicit DKIM=UNKNOWN record, I took this declaration to mean the domain only allows it to sign sometimes and no one else. That's not what RFC5617 says. For example, this is such a reporting for a list message posted here by Alessandro with its tana.it domain. Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org (unauthorized signer); The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. Reporting a fail against dkim=unknown is technically impossible. You should use unknown. See Section 5.4. Also, it should be dkim-adsp, not adsp. See Section 5.3. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; none doesn't appear in the registry. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
Murray S. Kucherawy wrote: For my A-R reporting if there an explicit DKIM=UNKNOWN record, I took this declaration to mean the domain only allows it to sign sometimes and no one else. 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. Authentication-Results: dkim.winserver.com; dkim=pass header.i=mipassoc.org header.d=mipassoc.org header.s=k1; adsp=fail policy=unknown author.d=tana.it signer.d=mipassoc.org (unauthorized signer); The (unauthorized signer) was added because it was an explicit DKIM=UKKNOWN DNS record declaration. Reporting a fail against dkim=unknown is technically impossible. I don't quite read it that way Murry. But it says No Author Domain Signature, it would be a failed. See below why I used adsp= instead. You should use unknown. See Section 5.4. Also, it should be dkim-adsp, not adsp. See Section 5.3. If there was no ADSP record, the adsp= info would look like this: adsp=none author.d=tana.it signer.d=mipassoc.org; none doesn't appear in the registry. I am also reporting ADSP/ATPS/ASL reporting and wanted to fold it into one line. The adsp= tag is for handler PASS|FAIL|NONE status for our internal MAIL API consumption only. I needed a different simpler namespace to not step over the two line dkim-adsp, dkim-atps. adsp=HANDLER status [policy=explicit-dkim=value] Anyway. My Reading is: No DNS record - no consideration for ADSP whatsoever. No (NONE) assumptions can be made, so you can't default to an UNKNOWN because it was known to the author and verifier - it wasn't defined (NONE) DKIM=UNKNOWN - it describes it as an optional expectation and its defines it as Author Domain, not just any signature. To me, there is diagnostic value between a real no signature (NONE) and an invalid one (FAIL). I don't wish to combine those as UNKNOWN. In short the combinations of inputs and outputs allows for all states to exist. Note, these are all part of the semantics ambiguities discussed in the past regarding ADSP. I hope we can fix it. -- 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
