On Aug 22, 2005, at 11:02 AM, Scott Kitterman wrote:
So to narrow my previous attempt at a summary, you think that
domain-wide assertions cannot be accurately made for mail
addresses, but that it can for HELO/EHLO?
Accuracy is not the issue. While a domain-wide assertion may
accurately issue requirements, the value of the assertion should be
assessed against intended goals. Part of that assessment should
include whether a goal is reasonably achieved, and weighed against
administrative complexity and a potential for inordinate use of DNS.
An assertion that HELO must verify with a CSA record where the same
CSA record makes the assertion, achieves the goal of assured
verification with low administrative complexity and low use of DNS.
If that's right, do you believe it to be true for the domain part
of an address or just out of bounds for the entire address (domain
and localpart)?
Binding a mailbox-address or mailbox-domain to a domain signature is
not a goal, it is a mechanism. What is the intended goal? What is
the selection process? What level of administrative effort will this
entail? What level of DNS interaction is required?
The same type of domain-wide assertion, in the same manner, would
be possible without imposing a requirement that the signature be
bound to a header. A new domain-wide assertion (even perhaps by
a CSA record) could be that any domain's signature is demanded
within this domain. The CSA assertion could also indicate
signatures by the domain itself are demanded within this domain.
OK. I don't understand. Are you saying that you think a domain
might successfully assert that if HELO/EHLO is from within the
domain then all mail must be signed by the domain? If so, such an
approach would seem to provide an assurance exactly when it isn't
needed.
Such a domain-wide assertion could inhibit a zombie system from
purporting to offer valid signatures when signing for other domains.
It could also inhibit a zombie system from sending without a
signature. What has been excluded? A goal of preventing
unauthorized sending of email is accomplished with low administrative
complexity and low use of DNS.
So, would it be fair to say that your position is that there is no
way to reliably bind a DKIM signature to currently displayed mail
addresses
This is not about reliability of the mechanism, but rather the
reliability of intended results. It also concerns the unintended
consequences of inordinate administrative and DNS burdens.
and so DKIM can be used for nothing but filtering and post-facto
reporting until MUAs are upgraded to display the signed
(accountable) domain?
In the same manner many use self-signed keys when accessing servers
using SSH, the same type of local manual binding is possible once
there is a domain signature. Should specific communications be
important to the recipient where they wish to be alerted to
_possible_ spoofing of these individuals or roles, perhaps the MUA
could offer a button to remember the mailbox-address/signing domain/
opaque-identifier bindings. Any other message using that same
mailbox-address that does not include this binding would cause a
warning. While this approach is not iron-clad, it could help
eliminate many of the common exploits. Often the recipient knows by
other means whether this is a valid message to permit such initial
assessments.
I have yet to hear your explanation how abuse can be determined in
advance.
And that it will be up to users to determine the relationship
between the signing domain and the e-mail addresses and evaluate
the legitimacy of the message?
When DKIM becomes widely deployed (which assumes stumbling blocks
were not created), then simple features such as single click
recording of typical mailbox-address/signing-domain/opaque-identifier
bindings would make establishing a strong relationship a rather
painless task. It would also instill confidence without making email
more complex to use or entail a major portion of the Earth's
available ram to support DNS.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org