ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

2007-12-04 12:05:04

On Dec 4, 2007, at 9:49 AM, Michael Thomas wrote:

John Levine wrote:
There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature.

My network gets tons of fake mail from HSBC UK and no real mail from them since none of my North American users have an account there. How would I be able to tell that it should have been signed?

If nobody cares about HSBC UK, why should you?

While clearly not a homogeneous world, a great many our customers care.

In any case, this strikes me as a tempest in a well stirred teapot. The load on DNS is similar to SPF/SIDF and the world has continued its normal rotation.

A single SSP record should have equal, and often significantly less overhead than SPF/SIDF (as typically used). An SSP transaction would be several orders of magnitude less than exploited macro expansions of SPF records. :^(

That said, DKIM itself introduces a significant resource overhead. A well-known domain would be able to vouch for unknown domains when TPA- SSP is used. Conversely, TPA-SSP records also permit a common signing domain to be authorized by thousands of less well-known domains. This ability might be important when DKIM signatures are selectively evaluated, due to just DKIM's base overhead.

Many systems are currently overwhelmed by abuse. Eyes may roll when suggesting addition of a resource intensive DKIM process. It is very likely resources needed for DKIM will be used selectively. There must be a bang for the buck. Those who ferret out phish may not understand every corner of world. The current SSP policy statement can help train how these filters should operate, without being checked when every message is received. Anti-phishing often needs to examine content look and feel, where SSP policy assertion might help prevent some false positives. On its own, even when expressed as Strict, this SSP policy will not prevent phishing. Strict policy can raise the bar, but without TPA-SSP, this Strict policy will likely create an unfortunate proliferation of email-addresses using some sub-domain of the otherwise well-known domain. A profusion of domain names will create more confusion for the average user and likely making them more prone.

-Doug
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>