[ietf-dkim] New issue: What is the purpose of SSP?

[Douglas Otis]

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