On Feb 19, 2009, at 2:27 PM, John Levine wrote:
What is the current recommended method to establish or expose that
a DOMAIN should not be signed, is not expected to be signed and
that any DKIM supportive receiver seeing a message with a signature
from a purported domain should be rejected with full confidence?
That's easy: don't publish any key records. If a verifier tries to
look up a key record for a signature that doesn't exist, it should
get the hint.
By design, a broken signature is equivalent to no signature.
Agreed. However, treating a signing domain as just a reputation token
is likely to result in slack handling.
Rather than utilizing i= values, when sub-domains are used to isolate
reputation assessments, a strategy that employs a sub-domain
relationship to override anti-spoofing checks is taking a considerable
risk from a control standpoint. There is nothing wrong with using i=
values to isolate reputation streams within a DKIM domain. Those
checking reputations need to limit the number of unacceptable i=
values reported before declaring the entire domain unacceptable. This
same limit is needed for sub-domains.
Currently, DKIM offers anti-spoofing protection for some 10 billion
messages daily. My brief use of an email-address on the IETF mailing
list quickly resulted in spam spoofing this address. If this email-
address happened to have represented that of a financial institution,
anti-spoofing protections would have been nearly automatic. While
some messages sent through a DKIM signing provider may receive just a
third-party signature assure their acceptance, they would not enjoy
the anti-spoofing benefits as defined in the charter. Although for
many this will not matter, for some it is critically important.
In Hector's case, depending upon how prevalent sub-domain reputation
segregation becomes, a need to ensure no keys can be published within
some sub-domain might become crucial. The use of ADSP does not
foreclose sub-domain spoofing, such as accounts.big-bank.com. Not
treating the d= value as opaque helps ensure DKIM remains safer to use.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html