On Sep 20, 2006, at 10:34 AM, Dave Crocker wrote:
By way of priming the pump here is my own attempt to remedy this:
Potential DKIM signers wish to assist receive-side message
evaluation systems by publishing information about the messages
that they originate and possibly sign. The primary basis for
determining what practices to specify is a strong indication that
receive-side processors have an interest in using the information.
As always, other major factors include potential performance and
reliability impact upon message handlers, and other system
operators.
Performance concerns are less significant when DKIM validation is
performed by a recipient's email client for messages recognized on
the a basis of originating and listed within a trusted-domain list or
address-book. Unlike IP address schemes where a time-stamp-line may
not offer IP address information, the DKIM message itself offers
requisite validation information. DKIM information is independent of
any receiving MTA added headers. Any single email client may need to
handle messages from several sources, including those that are web-
based.
With respect to policy, there should also be a general understanding
reached that acceptance of a message can not be solely based upon a
DKIM signature domain. The IP address remains a significant
identifier that is still needed for general acceptance. This
situation might change when call-back or revocation schemes have been
added to DKIM, or when there is a way to associate a signing domain
with that of the transmitter. Until then, policy should remain
focused upon ensuring the DKIM signing-domain offers protection for
the transmitter, rather than directly for the message originator when
they differ.
When deciding upon a basis for DKIM policy, redirections that
encompass desired email-address field or parameter domains must be
considered a requisite component. One possible area where DKIM could
prove highly valuable would be means to validate a bounce address
when a DSN is about to be sent. This can be accomplished within a
single lookup as only the domain of the bounce address needs to have
a policy published (assuming the bounce address does not use a
wildcard MX record).
i.e.
<hash1+hash2>.dkim-mf.<mail-from domain>. RR "always" + "strict"
These considerations will change this statement as follows:
Potential DKIM signers wish to assist receive-side message
evaluation systems by publishing information about the messages
that they originate and possibly sign [or have signed]. The
primary basis for determining what practices to specify is a
strong indication that receive-side processors have an interest
in using the information. As always, other major factors
include potential performance and reliability impact upon
message handlers, and other system operators. [Principal
email-addresses where policy references of signing-domains and
their related assurances may impact message handling are
the 2822.From and the 2821.Mail_From.]
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
