On Jun 2, 2006, at 11:36 AM, Michael Thomas wrote:
Dan Oetting wrote:
I'm not suggesting that ISPs should be required to filter
addresses. Just that for some ISPs it may be beneficial.
Because a DKIM signatures can provide indelible proof that abuse
originated at a specific ISP, they are going to put added pressure
on ISPs to control the abuse. Even after the ISP boots the abuser
the evidence of the abuse will still exist.
Yeah, but... large providers suffer from the Usenet Death Syndrome
-- that you can threaten a provider, but the likelihood that you're
ever going to pull the trigger on them is really low. Maybe it
works to some degree on the social/shame level, but the technical
level seems pretty remote. What _does_ seem more likely is that
we'll be able to get a better handle on senders who are abusive but
not drawn from large user populations, spammers being one form of
that population. If we can set up a situation where they are faced
with two choices: stay in the ever increasingly toxic sewer of
unauthenticated messages, or authenticate their messages which
allows reputation to accrue, then we'll all be in a much better
position. I guess the same goes for third party signatures too.
A better conclusion would be that only the signing domain will be
evaluated. Self policing without high DNS transactional overhead can
be accomplished with a combination of EHLO/signing-domain correlation
in conjunction with opaque identifier revocation. Hopefully a future
extension.
Cataloging violations based upon individual email-addresses
represents an immense amount of data that will be both costly and
risky to distribute. Identifying culpable entities by email-address
in the case of DKIM is weak and easily risks possible litigation.
Third-party services may report specific messages back to the signing
domain for possible resolution, where the individual email-address
would not likely play a significant role. Although the base draft
claims there will be reliance upon the email-address reputation,
receivers and third-party services are far more likely to focus upon
the signing domain with respect to message acceptance.
In the case of DKIM, making an assurance of an email-address by the
signing domain explicit by including the i=<something> parameter
increases the value of that information. The existence of the i=
parameter allows a presumption that the signing domain verified the
use of the email-address. The current strategy appears to mandate
(or assume) all email-address use is verified. Rather than jumping
to likely a false conclusion an email-address within the signing
domain has been restricted, by limiting this conclusion to the
specific case where the i= parameter offers a localpart, there would
be much less risk of reaching a dangerously invalid conclusion.
Annotation is the only way the results of DKIM become visible. Even
the threat document now places localpart exploits as both high impact
and high probability. Some type of localpart annotation will be
required, where fewer false conclusions about signing domain
assertions improves upon recipient security. There is no need to
become email-address use fanatics. It should be a simple matter to
compare normal domains utilized by friends, family and acquaintances
in DKIM aware MUAs. Only annotate the localpart as verified when
there is an i=localpart assertion (or perhaps a matching prior opaque-
identiifer). Annotation must also use a trusted list of email-
addresses (such as those found within the address book) to prevent
localpart spoofing.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg