On Feb 20, 2009, at 11:43 AM, Hector Santos wrote: > 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.
Socially engineered attacks are rising. The chartered goal of DKIM was to allow the detection of spoofing of known domains to help counter these attacks. When an email appears to be from @ads.example.com signed by ads.example.com, or example.com where i=ads.example.com might be used, the intended goal is met. When an email is from @example.com signed by ads.example.com, this defeats DKIM's intended goal. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
