MX dot was (Re: [ietf-dkim] TXT wildcards SSP issues
hsantos at santronics.com
Fri Jun 8 02:44:21 PDT 2007
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
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
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.
Hector Santos, CTO
More information about the ietf-dkim