On Nov 1, 2005, at 8:10 PM, Mark Delany wrote:
On Tue, Nov 01, 2005 at 07:11:45PM -0800, Douglas Otis allegedly
wrote:
As I recall, the issue was very specific to the arbitrary insertion of
2822.Sender and the impact that caused on certain UAs that render
Sender. The change in behavior at the recipient end was their sole
concern.
The insertion of Sender was a function of an implementation compromise
for their particular scenario of an ISP that services many vanity
domains, but which didn't want to (or couldn't) put keys into all the
relevant domains. Such a compromise is a non-problem for most domains
- particularly high-value domains, so it's hardly a fundamental or
universal issue.
This was not limited to vanity domains, but any email-address domain
different from that offered by the provider. I see this as a
universal issue. This freedom will be _greatly_ impacted by the SSP
proposal. Any email-address domain owner that "authorize" with SSP
any third-party signer will put at risk their ability to conduct
business. They will be at the mercy of those using the third-party
allowance to spoof their email-address, all unbeknownst to the email-
address domain-owner. As the interception of "bad" email-addresses
will be at a myriad of endpoints, game-over for the email-domain
owner. Not a fair game in my view.
The only marginally safe choice remaining would be to always use the
email-address offered by the provider who also restricts the use of
the local-part, in addition to the email-address domain. Of course,
abuse will be allowed from these large domains, and pollution of the
email-address space will occur where even the local-part of the email-
address must be constrained.
Furthermore, the problem has nothing to do with binding, it has
nothing to do with the underlying technology and perhaps surprisingly,
their concerns are not solved by opaque-identifiers. Rather, it solely
has to do with the UA impact of inserting 2822.Sender. The outcome of
which is to suggest that arbitrary insertion of Sender for
out-of-domain signatures (which I think people are calling 3rd-party
signatures) is not a good choice in the DK spec. Based on their
experience, I'm inclined to agree with that.
I am glad that you agree email-addresses and signing-domains should
not be required to match.
While there are only a limited number of domains using this signing
process, it would be hard to discern the dynamics related to accrual
of negative reputations. The sheer number of users associated with
large domains also offers a fair amount of leeway. If the signature
is established as a basis for acceptance, then the effects of
compromised systems and message replay abuse will negatively impact
this acceptance. This will likely be a greater concern for smaller
domains. This also means accepting messages from a large domain,
without some sort of revocation process, will require these abusive
messages be endured.
What Earthlink were attempting to do was, in effect, implement a
third-party signature and DK does not specify that well, nor does it
offer a policy rich enough to make that clear to verifiers. To my mind
that means that DKIM needs to do a much better job of that, not that
it can't be done.
DKIM offers the possibility for enabling extremely effective methods
at isolating compromised systems within large domains. This remains
problematic today. When there is a problem of this nature, an opaque-
identifier added to the signature would offer an easy means for a
third-party to isolate accounts sending malware and other forms of
abuse from a large domain. This identifier would not require that
the provider restrict their customers to a single email address for
the isolation of problematic sources to occur. Of course, if message
replay abuse does become a problem, there would also be an option
available to assist with that problem without re-engineering the
system to support short lived keys per individual customer. Yuck.
If DKIM is not considered a means to ensure the identification of an
accountable domain for an email message transport system, then
OpenPGP offers a better model as a starting point for implementing a
transparent signature at the email-address. This at least offers a
distributed revocation scheme and would also be independent of the
transport provider.
If SSP is the driving motivation for this working group, then I fear
the outcome.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org