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