Comment on RE: [ietf-dkim] 1365 yes/no

[Hallam-Baker, Phillip]

> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Steve Atkins

> It's been out of scope since day one. The argument for 
> keeping it has been "Yeah, it's out of scope, but what the 
> hell, we're throwing stuff that's far less useful into the 
> pile of stuff. At least this one piece has some conceivable 
> real world use, lets keep it."

I agree, but that is the reason that I don't want to open up that discussion now.

I do think that some folk need to stop being so defensive about their original proposal and allow for other people's ideas here. 

What I would like to do is to get a policy framework described that actually works and then have an open discussion on additional policy statements. Otherwise what happens is that we end up with a scheme that only addresses the low hanging fruit that was obvious at the time. I want a more systematic approach.

I do not think that the argument that SSP/SenderID has precedence here is actually very convincing. It might have been convincing if they had adopted a prefix scheme or if thye had managed to get to their work to proposed standard.

As it is I would prefer to work on the basis that DKIM is going to define THE authoritative outbound email policy which might in turn mention the existence of an SPF record. This makes a lot of sense since we have the opportunity to make the discovery scheme work properly. 

So the sorts of thing I would like to see in the outbound email policy record is:

    DKIM
    DKIM-TEST
    NOMAIL
    PHISHING-TARGET
    SPF