[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html