ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting

2011-05-04 07:59:05
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