[ietf-dkim] Collection of use cases for SSP requirements
dotis at mail-abuse.org
Thu Nov 9 10:11:30 PST 2006
On Nov 9, 2006, at 7:40 AM, Dave Crocker wrote:
> Charles Lindsey wrote:
>> Well at least it is a start to force the phishers into using look-
> As soon as banks start signing their messages and there are
> credible whitelists for their domain names, doesn't this end the
> ability for phishers to use those domain names in the rfc2822.From
Unfortunately, a DKIM signing-domain white-list based upon trust or
reputation is prone to abuse. Someone with access to a domain can
send themselves messages that can be replayed from anywhere. For the
MTA, without some mechanism to identify when it is safe to apply a
white-list, DKIM would not be validated to conserve resources. The
MUA may wish to validate DKIM signatures to confirm the recognized
identity before annotation is applied.
> Therefore, how does SSP have any effect?
> That is, if the message is signed and the whitelist says the signer
> is a Good Actor, the the message is handled with a favorable eye.
> If the message is not signed, it is handled with a suspicious eye.
> Exactly where does SSP fit into the protection scheme?
When attempting to defeat spoofing, message annotation is required.
The annotation should be based upon:
A) Matching with trusted email-address assured valid via signature
semantics or policy assertions.
B) Matching email-address trusted domain where policy asserts the
specific email-address as trustworthy.
The annotation scheme defined in DOSP provides a formidable defense
against phishing or other types of spoofing.
> What use case does it cover?
When a receiver wishes to white-list big-isp.com because a few of
their users run afoul of their block-lists. Once it becomes
understood by the bad actors able to gain access to big-isp.com, then
any white-listing hoping to bypass block-lists will prove
disastrous. DOSP offers a means to associate the SMTP client with
the signing domain. This association allows white-listing to be
safely applied based upon either trust or reputation.
The same association strategy can assure the 2821.MailFrom address
without the problems related to address-path registration.
Autonomous designation of providers:
The same association strategy eliminates an exchange private keys,
delegation of DNS zones, or publishing CNAMEs at specific selector
leafs. This association strategy also allows autonomous management
of a customer's relationship with their providers. (Good for the
customer and good for the provider as they will receive abuse feedback.)
> Exactly which SSP flag/mechanisms is it that provide this
> additional benefit?
<hash:signing-domain>.<email-address-domain> RR "a=signing-domain f=A
>>> Many of them use their own domains, for which they could
>>> trivially publish SSP data.
>> Which is where we need sites on which "reputations" can be queried.
> Exactly. In which case, what is the need for SSP?
When there is a desire to secure private keys and still having
messages receive an authorization signed by the providers domain.
> And, since I happen to think that SSP *can* provide some utility,
> here's the case that makes sense to me:
> For domain names that are in the whitelist, an SSP flag that says
> "I sign everything" gives me the ability to handle unsigned
> messages using that domain name in the rfc2822.From (or
> rfc2822.sender?) field with *extreme* prejudice.
So what? In reality this blocking effort affords little protection.
When the domain also wishes to use mailing lists, extreme prejudice
will significantly reduce the integrity of their email. Different
policies within sub-domains only increases the likely success of
> This seems useful to me.
> Not earth-shakingly great, but at least useful.
Not really. It establishes bad practices and will create problems
for virtually no benefit. DKIM can not be applied with respect to
white-listing except perhaps in a select few cases such as bulk
senders. Attempting qualify email-address originating domains only
when matching with the signing domain creates additional problems.
These problems can be resolved without requiring any additional DNS
transaction as described in DOSP.
More information about the ietf-dkim