MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues

[Hector Santos]

Jon Callas wrote:

>> Sure, but unless I am missing a changing of philosophy, this goes 
>> against DKIM-BASE "ignore failures" design.
>>
>> I was under the impression, the whole point of the SSP layer is to 
>> give DKIM domains and verifiers some authority to handle the DKIM 
>> signature expectation violations.
>>
>> Is that what we want? change the semantics of DKIM-BASE?
> 
> It doesn't change any semantics at all. DKIM-BASE does recommend 
> ignoring failures. But the whole point of SSP is to consider the case 
> where we don't want to ignore failures. We want a missing/broken/etc. 
> signature to have meaning.

I believe that is what I said above.

> The hack I describe is merely setting up your DKIM parameters so that 
> any signature on a message must be erroneous; the receiver then does 
> whatever they want, including using SSP.

I believe the question you inherently raised was if SSP needed a NOMAIL 
concept - hence why it was deemed to be a REDUNDANT concept and removed 
from the requirements.

I am merely pointing out that the idea of using a bogus key to signal a 
failure concept was well established, but that without a NOMAIL policy 
concept, that key failure only would not be enough to handle the 
transaction for rejection from a domain complete expectation point of 
view -

       I don't expect mail from this domain - kill it, don't
       tag it or mark it as bad for user's to see, kill it,
       don't pass it on. Its not ours!  - If you do, it is
       no longer our responsibility as DKIM-BASE suggest it
       is."

So it is not a redundant.  SSP requires a NOMAIL concept.  The bogus key 
may assure am invalid signature from a technical standpoint, the SSP 
NOMAIL declaration assures a rejection from a policy standpoint.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com