On Sep 22, 2006, at 1:56 PM, Michael Thomas wrote:
The intention here is not to validate each point of the positive
and negative commentary, but to bring the issues to the fore so
that the entire scenario and requirements it generates can be
understood in the context of what has gone on with the list. If I
have transcribed the negative commentary incorrectly, I'm open to
fixing that, but striking each point fundamentally misses the point
of why it's in the draft.
This transcribed commentary is one-sided and lacking a basis.
Whether supported by a few on list at the time, it is still wrong and
does not belong in the requirements document.
Being able to associate signing domains with various email-addresses
without involving three different organizations is critical for
allowing DKIM to scale and to offer a greater scope of protection.
Don't suggest delegating one's domain or allowing third parties
access to private keys is without even more significant risks.
The basis of the these negative concerns presume:
A- the designated signing domain is unable to restrict
access against non-validated email-addresses. (How is
the 'i=' syntax be expected to work?)
B- the policy for the designated domain is unable to assert
that an email-address should not be presumed valid.
C- the policy can not scale as needed or is complex.
D- a designated domain may confuse who should be held
accountable. (Hint: whoever signed or IP address)
E- the signing domain should only associate with the
From email-address, not the domain administrating the
client whose IP address _will_ be held accountable. : O
E- only the email-address domain owner benefits from DKIM
abuse reporting.
F- sharing a private keys or domain with a third-party
is well understood and therefore safe.
G- referencing a signing domain within a policy is
fraught with security risks avoided by sharing keys
and domains.
DKIM will not fulfill any provider's dream that they no longer need
to worry about what comes out of their networks. DKIM will provide
them clean and noise-free feedback. For this feedback, _they_ must
be the one's signing with _their_ keys and not that of their
customers. : O
When the provider insists upon using their keys is where policy plays
a vital and valuable role. The policy for an email-address, whether
it is the 2822.From or the 2821.MAIL_FROM, can associate a provider's
signing domain without the provider needing to coordinate several
complex details with the customer and the customer's DNS provider.
Scaling.
The reason for even obtaining a policy records is to determine
whether the email-address is associated with the signing domain. By
allowing comprehensive coverage of a single signing domain, this
policy can allow annotations of retained email-addresses that protect
Eliot's dad. Others may expect that policy only blocks exact-domain
spoofing, but this is likely only wishful thinking. Don't be too
sure that blocking some very small percentage of abuse justifies
searching up label trees after each and every message received.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
