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