ietf-dkim
[Top] [All Lists]

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

2007-06-08 02:49:54
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

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>