Douglas Otis wrote: > 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.
In this case, a national store chain was being asked to delegate a sub-domain for signing by their bulk mailer vendor. The concern was the potential harm to their principle domain and wanted to make sure there was a mechanism in place to help avoid DKIM outside the request and usage by their professional spammer. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
