Re: [ietf-dkim] SSP requirements

[Douglas Otis <[e-mail]>]

On Aug 5, 2006, at 1:42 PM, John L wrote:

>> That's a pretty reasonable question, frankly. The set of domains  
>> that would actually benefit from SSP from the consensus I've seen  
>> seems like it's a pretty tiny fraction of the internet at large  
>> and almost certainly could be handled by third party dnsbl-like or  
>> accreditation schemes as well.
>
> Agreed.  That's what I've been thinking all along.

The DKIM From policy is fairly limited to being a possible domain  
delegation alternative, and perhaps a flag that might indicate  
greater care is being exercised due to a phishing problem.


>> But it may be worth it if for no other reason to provide the  
>> transport, discovery, and syntax framework for putting goodies in  
>> for the experiment.
>
> If people want to do experiments, they should do experiments.  The  
> IESG would never go for an SSP spec that was just a container for  
> data yet to be invented.

I would hope this would be true.

An another policy that might be considered would be one for the DKIM  
client, rather than just for the DKIM From domain.  The DKIM client  
policy could simply an indication a client in this domain always  
signs, and that the client can always be authenticated by a DKIM  
convention.  The DKIM client policy could be even implied by the  
presence of the DKIM From policy.  The simplest authentication  
convention would be just an Address RRset transaction for the EHLO  
host-name.  Knowing the name of the client makes further domain name  
association within the message possible, and would be a domain  
examined before any additional resources are expended.

The DKIM authentication convention could be noted at the EHLO by  
having the host-name for the client utilize a "_dkim." prefix.  This  
prefix signals the mode of authentication made possible by the DKIM  
convention claiming this prefix.  This could fall into the same realm  
as the key, and From policy records.  There would be zero additional  
transactions needed to support this form of client authentication,  
assuming an A record lookup would be performed anyway.  The "_dkim."  
prefix can make this authentication more stringent, instead of this  
being allowed to fail as currently defined in RFC2821.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html