On Sep 22, 2006, at 12:06 PM, Hector Santos wrote:
While reasons for a DKIM signature failure will be different, they
will persist just as they have with SPF. If history offers
guidance, it would be to NOT request handling except in exigent
situations.
And what are those "Exigent Situations?"
Many consider phishing an exigent situation. Corporations may
restrict their inputs to authenticated web-forms and abandon email
for commerce. Alerts become an automated phone call. There are some
commerce activities where this method is fairly burdensome. One
response is to individualize each message in a recognizable fashion.
When an existing or trusted email-address can be used in conjunction
with a valid DKIM signature, standardized annotations replace what
might become a confusing array of recognition techniques.
In principle, I disagree with the assertion that we are not
offering new ways to filter mail. I'm a realist. That is exactly
how it is going to be used.
DKIM should improve upon performance and accuracy of message
filtering without reliance upon policy assertions. This filtering,
as always, would be based upon a type of non-standard share reputation.
Whether it is standard SSP, non-standard proprietary REPUTATION
schemes, Heuristics, Classification, Neural Nets methods, etc, its
all about the same thing - Query Dissemination. Its a long
establish science.
Only when policy information is trustworthy would there be any
protection. Many of the bad actors have already adopted various look-
alike attacks to avoid message filtering techniques, where blocking
policy becomes worthless. Standardized trusted-lists and address-
books allow DKIM to establish trust.
While it is true the industry has evolved with legacy operations
for which there is little to do about the exploitations, and for
the most part receivers followed a fail-safe philosophy, with DKIM-
SSP, we would be evolving beyond legacy operations and therefore a
new level of expectations with new protocol attributes that allows
signers and receivers to leverage.
I agree with the sentiment, but we both see different uses for
policy, association versus blocking.
Publishing reputation by name rather address is more comprehensive,
but... Histories supporting reputation must be verifiable. Most
abuse today looks spammy, but so do valid messages. When spammy
messages are sent in bulk to non-receptive recipients, the IP address
is block-listed. With DKIM, there may not be evidence the signing
domain was responsible for the Rcpt To parameter. This weakens a
concept of bulk being applied to DKIM in the same manner as with an
IP addresses.
Hopefully, towards their benefit and not the benefit of the
exploiters.
Of greater importance is to ensure that DKIM is not a detriment to
the implementer.
In short, if you do something that will move you into a new
category, then we are no longer talking about the inadequacies of 20
+ years old legacy operation.
It takes years for infrastructure to change, where legacy equipment
will be in play. A retained email-address annotation approach offers
significantly improved protection compatible with existing systems.
It would be my hope that DKIM abuse reporting and perhaps the
adoption of opaque identifiers make a dent in identifying and
eliminating millions of compromised systems that are responsible for
sending much of the spam.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
