[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen
Farrell
But even if SPF doesn't provide the exact thing that 1365
requests, we still have to address whether or not this
feature is in-scope for DKIM (which is different from wanting
it done somewhere).
I think that as with 'I am a phishing target' and other interesting policy
statements it is outside our current charter.
I don't like the SPF/SenderID use of a naked TXT record for policy signalling
and I would like to see a 'NO-SEND' policy attribute within the record used for
DKIM defined at some time. At this point it is out of discussion scope and out
of charter scope so we can't.
What I would like to do however is to leave open the option of revisiting this
at a later date. This might be through a DKIM draft, an informational RFC or
whatever. The reason I mention informational here is that we might see the
Antiphishing Working Group or MAAWG or whatever define best sending practices.
The significance here is that we might use a different prefix for the policy
record if we are anticipating extensions of this kind. This is only relevant if
we end up changing the policy prefix. What it would mean is:
_outbound._smtp.example.com TXT "DKIM NO-SEND"
vs
_dkim.example.com TXT "DKIM NO-SEND"
Since the only DKIM policies we need are 'I always sign' and 'I always sign
with a key selector *.x' I think that the more general policy prefix is more
appropriate.
This also leads naturally to the use of IANA keyword tags rather than UNIX
style single letter command line flags which are confusing and error prone in
my view.
So drop the requirement by all means but leave in the ability to extend the
policy to include other statements.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html