[ietf-dkim] SSP requirements
dotis at mail-abuse.org
Sat Aug 5 16:16:50 PDT 2006
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.
More information about the ietf-dkim