but it can come from @example.com signed by @test.com
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Sent: Saturday, 21 February, 2009 8:10:00 AM (GMT+1200) Auto-Detected
Subject: Re: [ietf-dkim] NO DKIM "POLICY"
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html