I have a huge fear that I am beating a dead horse down a rathole. I
also fear that I no longer understand what's being discussed.
However, I want to make a cryptographic observation.
If you create a suitably-sized RSA key, throw away the private key,
and put the public key in a DKIM selector, you have made a selector
that can't have mail signed from it (or if you want to be really
anal, forging a signature for that selector is equivalent to breaking
that key).
If you then say, "I sign all mail" for any domain pointing to that
selector, you've effectively made a cryptographically enforced no-
mail, no-use, etc. domain using the existing Tinkertoys.
In short -- saying "I sign everything" with a non-existent or bogus
key is the same thing as saying, "You'll never see a valid one of
these."
Jon
Jon,
Horse of a different color that has already been hammered down another hole.
A message with a broken sig - while less tasty - is still valid message.
In general, verifiers SHOULD NOT reject messages solely on the basis
of a lack of signature or an unverifiable signature; such rejection
would cause severe interoperability problems. However, if the
verifier does opt to reject such messages (for example, when
communicating with a peer who, by prior agreement, agrees to only
send signed messages), and the verifier runs synchronously with the
SMTP session and a signature is missing or does not verify, the MTA
SHOULD use a 550/5.7.x reply code.
If it is not possible to fetch the public key, perhaps because the
key server is not available, a temporary failure message MAY be
generated using a 451/4.7.5 reply code, such as:
451 4.7.5 Unable to verify signature - key server unavailable
Temporary failures such as inability to access the key server or
other external service are the only conditions that SHOULD use a 4xx
SMTP reply code. In particular, cryptographic signature verification
failures MUST NOT return 4xx SMTP replies.
Once the signature has been verified, that information MUST be
conveyed to higher-level systems (such as explicit allow/whitelists
and reputation systems) and/or to the end user. If the message is
signed on behalf of any address other than that in the From: header
field, the mail system SHOULD take pains to ensure that the actual
signing identity is clear to the reader.
The verifier MAY treat unsigned header fields with extreme
skepticism, including marking them as untrusted or even deleting them
before display to the end user.
-Also-
8.7. Intentionally Malformed Key Records
It is possible for an attacker to publish key records in DNS that are
intentionally malformed, with the intent of causing a denial-of-
service attack on a non-robust verifier implementation. The attacker
could then cause a verifier to read the malformed key record by
sending a message to one of its users referencing the malformed
record in a (not necessarily valid) signature. Verifiers MUST
thoroughly verify all key records retrieved from the DNS and be
robust against intentionally as well as unintentionally malformed key
records.
8.8. Intentionally Malformed DKIM-Signature Header Fields
Verifiers MUST be prepared to receive messages with malformed DKIM-
Signature header fields, and thoroughly verify the header field
before depending on any of its contents.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html