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
